mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/pentesting-web/http-connection-request-smuggling.md'] t
This commit is contained in:
Translator
parent
4b9a2c30b4
commit
bcddaa3131
@ -1,34 +1,83 @@
|
||||
# HTTP接続リクエストスムーギング
|
||||
# HTTP Connection Request Smuggling
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
**これは投稿の要約です** [**https://portswigger.net/research/browser-powered-desync-attacks**](https://portswigger.net/research/browser-powered-desync-attacks)
|
||||
**このページは、** [Browser-Powered Desync Attacks](https://portswigger.net/research/browser-powered-desync-attacks) に関するPortSwiggerの画期的な研究を要約し、拡張し、更新したものです。また、HTTP/2接続状態の悪用に関するその後の作業にも焦点を当てています。これは、**TCP/TLS接続ごとに一度だけオリジンが決定される**脆弱性に焦点を当てており、攻撃者がチャネルが確立された後に異なる内部ホストにリクエストを「スムグル」できるようにします。
|
||||
|
||||
## 接続状態攻撃 <a href="#state" id="state"></a>
|
||||
## Connection-State Attacks <a href="#state" id="state"></a>
|
||||
|
||||
### 最初のリクエスト検証
|
||||
### First-request Validation
|
||||
|
||||
リクエストをルーティングする際、リバースプロキシは**Hostヘッダー**に依存して、宛先のバックエンドサーバーを特定することがあり、アクセスが許可されたホストのホワイトリストに依存することがよくあります。しかし、一部のプロキシには、ホワイトリストが接続内の最初のリクエストにのみ適用されるという脆弱性があります。そのため、攻撃者は最初に許可されたホストにリクエストを行い、その後同じ接続を通じて内部サイトをリクエストすることでこれを悪用することができます。
|
||||
```
|
||||
リクエストをルーティングする際、リバースプロキシは**Host**（またはHTTP/2の**:authority**）ヘッダーに依存して、宛先のバックエンドサーバーを決定することがあります。通常、アクセスが許可されているホストのホワイトリストに依存しています。しかし、接続内の最初のリクエストに対してのみホワイトリストが**強制される**という脆弱性が多くのプロキシに存在します。その結果、攻撃者は最初に許可されたリクエストを送信し、その後同じ基盤接続を再利用することで内部の仮想ホストにアクセスできます。
|
||||
```http
|
||||
GET / HTTP/1.1
|
||||
Host: [allowed-external-host]
|
||||
Host: allowed-external-host.example
|
||||
|
||||
GET / HTTP/1.1
|
||||
Host: [internal-host]
|
||||
GET /admin HTTP/1.1
|
||||
Host: internal-only.example
|
||||
```
|
||||
### First-request Routing
|
||||
|
||||
一部の構成では、フロントエンドサーバーが**最初のリクエストのHostヘッダー**を使用して、そのリクエストのバックエンドルーティングを決定し、その後、同じクライアント接続からのすべての後続リクエストを同じバックエンド接続に持続的にルーティングする場合があります。これは次のように示すことができます:
|
||||
```
|
||||
多くのHTTP/1.1リバースプロキシは、**転送する最初のリクエストのみに基づいて**、バックエンドプールへのアウトバウンド接続をマッピングします。その後に同じフロントエンドソケットを通じて送信されるすべてのリクエストは、Hostヘッダーに関係なく静かに再利用されます。これは、パスワードリセットポイズニングや[web cache poisoning](https://portswigger.net/web-security/web-cache-poisoning)などの古典的な[Host header attacks](https://portswigger.net/web-security/host-header)と組み合わせて、他の仮想ホストへのSSRFのようなアクセスを取得することができます。
|
||||
```http
|
||||
GET / HTTP/1.1
|
||||
Host: example.com
|
||||
Host: public.example
|
||||
|
||||
POST /pwreset HTTP/1.1
|
||||
Host: psres.net
|
||||
Host: private.internal
|
||||
```
|
||||
この問題は、他の脆弱性を悪用したり、追加の仮想ホストへの不正アクセスを得るために、[Host header attacks](https://portswigger.net/web-security/host-header)や、パスワードリセットポイズニング、[web cache poisoning](https://portswigger.net/web-security/web-cache-poisoning)と組み合わせることができます。
|
||||
> [!TIP]
|
||||
> Burp Suite Professional ≥2022.10 では、**HTTP Request Smuggler → Connection-state probe** を有効にして、これらの脆弱性を自動的に検出できます。
|
||||
|
||||
> [!NOTE]
|
||||
> これらの脆弱性を特定するために、HTTP Request Smugglerの「connection-state probe」機能を利用できます。
|
||||
---
|
||||
|
||||
## 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)
|
||||
|
||||
| 年 | コンポーネント | CVE | ノート |
|
||||
|------|-------------------------------------|-------------------|----------------------------------------------------------------------|
|
||||
| 2022 | AWS Application Load Balancer | – | ホストヘッダーは最初のリクエストのみ検証; ルールエンジンのパッチで修正 (SecurityLabs によって開示)。 |
|
||||
| 2023 | Apache Traffic Server < 9.2.2 | CVE-2023-39852 | `CONFIG proxy.config.http.parent_proxy_routing_enable` が設定されているときに HTTP/2 接続再利用を介してリクエストスムグリングを許可。 |
|
||||
| 2024 | Envoy Proxy < 1.29.0 | CVE-2024-2470 | 最初のストリーム後の :authority の不適切な検証により、共有メッシュ内でのクロステナントリクエストスムグリングを可能に。 |
|
||||
|
||||
---
|
||||
|
||||
## 検出チートシート
|
||||
|
||||
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 – 不適切な権限検証
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user