HTTP Connection Request Smuggling

Reading time: 8 minutes

このページは、 Browser-Powered Desync Attacks に関するPortSwiggerの画期的な研究を要約し、拡張し、更新したものです。また、HTTP/2接続状態の悪用に関するその後の作業にも焦点を当てています。これは、TCP/TLS接続ごとに一度だけオリジンが決定される脆弱性に焦点を当てており、攻撃者がチャネルが確立された後に異なる内部ホストにリクエストを「スムグル」できるようにします。

Connection-State Attacks

First-request Validation

リクエストをルーティングする際、リバースプロキシはHost（またはHTTP/2の**:authority**）ヘッダーに依存して、宛先のバックエンドサーバーを決定することがあります。通常、アクセスが許可されているホストのホワイトリストに依存しています。しかし、接続内の最初のリクエストに対してのみホワイトリストが強制されるという脆弱性が多くのプロキシに存在します。その結果、攻撃者は最初に許可されたリクエストを送信し、その後同じ基盤接続を再利用することで内部の仮想ホストにアクセスできます。

GET / HTTP/1.1
Host: allowed-external-host.example

GET /admin HTTP/1.1
Host: internal-only.example

First-request Routing

多くのHTTP/1.1リバースプロキシは、転送する最初のリクエストのみに基づいて、バックエンドプールへのアウトバウンド接続をマッピングします。その後に同じフロントエンドソケットを通じて送信されるすべてのリクエストは、Hostヘッダーに関係なく静かに再利用されます。これは、パスワードリセットポイズニングやweb cache poisoningなどの古典的なHost header attacksと組み合わせて、他の仮想ホストへのSSRFのようなアクセスを取得することができます。

GET / HTTP/1.1
Host: public.example

POST /pwreset HTTP/1.1
Host: private.internal

2023-2025 の新機能 – HTTP/2/3 接続のコアレッシング悪用

最新のブラウザは、証明書、ALPN プロトコル、IP アドレスが一致する場合、HTTP/2 および HTTP/3 リクエストを単一の TLS 接続にコアレッスします。フロントエンドが最初のリクエストのみを承認する場合、以降のすべてのコアレッスされたリクエストはその承認を継承します – ホスト/:authority が変更されても。

悪用シナリオ

1. 攻撃者は evil.com を制御しており、これはターゲットの internal.company と同じ CDN エッジノードに解決されます。
2. 被害者のブラウザはすでに evil.com への HTTP/2 接続を開いています。
3. 攻撃者は自分のページに隠れた <img src="https://internal.company/…"> を埋め込みます。
4. 接続パラメータが一致するため、ブラウザは既存の TLS 接続を再利用し、internal.company へのリクエストを多重化します。
5. CDN/ルーターが最初のリクエストのみを検証した場合、内部ホストが露出します。

Chrome/Edge/Firefox 用の PoC は、James Kettle の講演 “HTTP/2: The Sequel is Always Worse” (Black Hat USA 2023) で入手可能です。

ツール

• Burp Suite 2023.12 では、コアレッシングおよび TE/CL テクニックを自動的に試みる実験的な HTTP/2 Smuggler 挿入ポイントが導入されました。
• smuggleFuzz (https://github.com/microsoft/smugglefuzz) – 2024 年にリリースされた Python フレームワークで、HTTP/2 および HTTP/3 におけるフロントエンド/バックエンドのデシンクベクターをブルートフォースします。

緩和策

• 接続の作成時だけでなく、すべてのリクエストで Host/:authority を再検証してください。
• CDN/ロードバランサー層での オリジンコアレッシング を無効にするか、厳密にスコープを設定してください (例: NGINX で http2_origin_cn をオフ)。
• ブラウザが合法的にコアレッスできないように、内部および外部ホスト名に対して別々の証明書または IP アドレスを展開してください。
• 実用的な場合は、各リクエストの後に connection: close または proxy_next_upstream を優先してください。

実世界のケース (2022-2025)

検出チートシート

1. 異なる Host または :authority ヘッダーを持つ 同じ TCP/TLS 接続で 2 つのリクエストを送信します。
2. 2 番目のレスポンスが最初のホスト (安全) から発信されるか、2 番目のホスト (脆弱) から発信されるかを観察します。
3. Burp で: Repeat → keep-alive → Send → Follow。
4. HTTP/2 をテストする際は、無害なホスト用に 専用 ストリーム (ID 1) を開き、次に内部ホストへの 2 番目のストリーム (ID 3) を多重化し、返信を探します。

参考文献

• PortSwigger Research – HTTP/2: The Sequel is Always Worse (Black Hat USA 2023)
• Envoy Security Advisory CVE-2024-2470 – 不適切な権限検証