HTTP接続リクエストスムーギング

Reading time: 4 minutes

tip

AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する：HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする

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

接続状態攻撃

最初のリクエスト検証

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

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

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

First-request Routing

一部の構成では、フロントエンドサーバーが最初のリクエストのHostヘッダーを使用して、そのリクエストのバックエンドルーティングを決定し、その後、同じクライアント接続からのすべての後続リクエストを同じバックエンド接続に持続的にルーティングする場合があります。これは次のように示すことができます:

GET / HTTP/1.1
Host: example.com

POST /pwreset HTTP/1.1
Host: psres.net

この問題は、他の脆弱性を悪用したり、追加の仮想ホストへの不正アクセスを得るために、Host header attacksや、パスワードリセットポイズニング、web cache poisoningと組み合わせることができます。

note

これらの脆弱性を特定するために、HTTP Request Smugglerの「connection-state probe」機能を利用できます。

tip

AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する：HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする