HTTP Connection Request Smuggling

ゼロからヒーローまでAWSハッキングを学ぶ htARTE（HackTricks AWS Red Team Expert）！

• サイバーセキュリティ企業で働いていますか？ HackTricksで会社を宣伝してみたいですか？または、PEASSの最新バージョンにアクセスしたり、HackTricksをPDFでダウンロードしたいですか？SUBSCRIPTION PLANSをチェックしてください！

• The PEASS Familyを発見し、独占的なNFTsコレクションをご覧ください

• 公式PEASS＆HackTricksスワッグを手に入れましょう

• 💬 DiscordグループまたはTelegramグループに参加するか、Twitterで私をフォローしてください 🐦@carlospolopm。

• ハッキングトリックを共有するには、hacktricksリポジトリ および hacktricks-cloudリポジトリ にPRを提出してください。

この投稿の要約です https://portswigger.net/research/browser-powered-desync-attacks

接続状態攻撃

最初のリクエスト検証

リクエストをルーティングする際、リバースプロキシは通常、許可されたホストのホワイトリストに依存して、Hostヘッダーを使用してバックエンドサーバーの宛先を決定します。ただし、一部のプロキシには、ホワイトリストが接続の最初のリクエストでのみ強制されるという脆弱性が存在します。そのため、攻撃者は許可されたホストに最初にリクエストを行い、その後同じ接続を介して内部サイトにリクエストすることでこれを悪用できます。

GET / HTTP/1.1
Host: [allowed-external-host]

GET / HTTP/1.1
Host: [internal-host]

最初のリクエストのルーティング

いくつかの構成では、フロントエンドサーバーは最初のリクエストのHostヘッダーを使用して、そのリクエストのためのバックエンドルーティングを決定し、その後、同じクライアント接続からのすべての後続リクエストを同じバックエンド接続に永続的にルーティングします。これは次のように示すことができます：

GET / HTTP/1.1
Host: example.com

POST /pwreset HTTP/1.1
Host: psres.net

この問題は、Hostヘッダー攻撃（パスワードリセットポイズニングやwebキャッシュポイズニングなど）と組み合わせることで、他の脆弱性を悪用したり、追加の仮想ホストへの不正アクセスを得る可能性があります。

これらの脆弱性を特定するために、HTTPリクエストスマグラーの 'connection-state probe' 機能を利用できます。

AWSハッキングをゼロからヒーローまで学ぶ htARTE（HackTricks AWS Red Team Expert）！

• サイバーセキュリティ企業で働いていますか？ HackTricksで会社を宣伝したいですか？または、PEASSの最新バージョンにアクセスしたいですか？または、HackTricksをPDFでダウンロードしたいですか？SUBSCRIPTION PLANSをチェックしてください！

• The PEASS Familyを発見し、独占的なNFTsコレクションを見つけます

• 公式PEASS＆HackTricks swagを手に入れます

• 💬 Discordグループに参加またはtelegramグループに参加またはTwitterでフォローしてください 🐦@carlospolopm.**

• ハッキングトリックを共有するために、hacktricksリポジトリ とhacktricks-cloudリポジトリ にPRを提出してください。