hunt-http-smuggling

17. HTTP リクエストスマグリング

重複率は最低です。$5K～$30K。James Kettle による PortSwigger の調査。

CL.TE（フロント側が Content-Length、バック側が Transfer-Encoding）

POST / HTTP/1.1
Content-Length: 13
Transfer-Encoding: chunked

0

SMUGGLED

検出

1. Burp extension: HTTP Request Smuggler
2. Right-click request → Extensions → HTTP Request Smuggler → Smuggle probe
3. Manual timing: CL.TE probe + ~10s delay = backend waiting for rest of body

影響の連鎖

Poison next request → access admin as victim
Steal credentials → capture victim's session
Cache poisoning → stored XSS at scale

---

ターゲット適合性マトリクス（2026年の現実チェック）

従来の CL.TE / TE.CL ペイロードは、2026年にはどこでも悪用できるわけではありません。最新のプロキシは、デフォルトで RFC 9112 に厳格に準拠しています。時間をかける前に、フロントエンドをフィンガープリントしてください。

フロントエンド	CL.TE	TE.CL	H2.CL	H2.TE	備考
Nginx ≥ 1.21	いいえ	いいえ	一部（H2 ingress）	一部	RFC に厳格に準拠し、CL+TE を HTTP 400 で拒否します。Nginx 1.27 でローカル検証済みです。文書化された9種類すべてのバリアントがフロントエンドで遮断されました（docs/verification/phase2h-smuggling-cachepoison.md）。
Caddy 2.x	いいえ	いいえ	—	—	デフォルトで強化済み
Envoy ≥ 1.20	いいえ	いいえ	一部	一部	ほとんどの経路で強化済み
HAProxy ≤ 2.4	✓	✓	—	—	脆弱です。CVE-2021-40346 を参照してください
AWS ALB + 特定のアップストリーム	一部	一部	✓	✓	2022～2024年に報奨金付きで複数の脆弱性報告あり
Cloudflare → S3 / Lambda のチェーン	—	—	✓	✓	H2 ダウングレード攻撃は依然として有効です
古い F5 BIG-IP（TMM < 16）	✓	—	—	—	ベンダーの勧告を参照
Citrix ADC / NetScaler（古いファームウェア）	✓	✓	—	—	2020～2022年に報告済み
Squid 3.x	✓	—	—	—	古いデプロイ環境
Apache Traffic Server（旧バージョン）	✓	✓	✓	✓	PortSwigger の調査
Apache mod_proxy_ajp → Tomcat	—	—	—	—	プロトコルをまたぐ HTTP→AJP のデシンク（CVE-2022-26377）です。スマグリングされたリクエストは WAF から見えず、外部の認証制御がない内部 AJP 管理／ステータス経路に到達します
カスタム Python / Go プロキシ	✓	✓	—	—	RFC 準拠の確認が抜けているケースがよくあります

オペレーター向けフィンガープリントのクイックチェック

curl -sI https://target/ | grep -i "Server:"

• nginx/1.21+、Caddy、envoy → 従来の CL/TE は通用しません。フロントエンドが HTTP/2 に対応している場合は H2.CL/H2.TE に切り替えるか、アップストリームにレガシープロキシがないか確認してください
• HAProxy、ヘッダーに AWS/CDN の記載あり → ペイロードマトリクスをすべて実行してください
• Server ヘッダーがない → 強化済みと想定しつつ、space-before-colon のプローブを1回だけ手早く試してください。HTTP 400 にならない場合は、さらに調査してください

H2.CL / H2.TE（現在主流のベクトル）

H2 ダウングレード型のスマグリング攻撃は、フロントエンドがクライアントとは HTTP/2 で通信し、オリジンとは HTTP/1.1 で通信していることを利用します。HTTP/2 のフレーム長ヘッダーが変換時に正しく引き継がれないため、このダウングレードによって CL/TE の解釈の不一致が生じます。2024～2026年の CDN とオリジンのチェーンの多くが、まさにこの構成を採用しています。

HTTP/2 の生フレームを送信できるツール（Burp Pro の HTTP Request Smuggler 拡張機能、h2csmuggler、smuggler.py）は、CDN を前段に置くターゲットに対する適切な出発点です。H2 をフロントエンドに置くターゲットに対して、HTTP/1.1 専用のテストクライアント（curl、raw sockets）を使うのは避けてください。まったく異なるプロトコルを送信してしまいます。

大量の認証情報を収集する「コレクターガジェット」

最も影響の大きいスマグリングの結果を得るために、被害者ごとの操作は必要ありません。キューを無差別にポイズニングする代わりに、リクエスト全体をそのまま返すバックエンドハンドラーを狙ったリクエストをスマグリングしてください。たとえば、ヘッダーを反映する検索エンドポイントや、リクエスト行をそのまま返すリダイレクトです。次の被害者のヘッダー（Cookie、Authorization、X-Access-Token）が、あなたのスマグリングしたリクエストに関連付けられ、反射するハンドラーがそれらをあなたが読めるレスポンスで返します。通信量の多い keep-alive ソケットでこれを繰り返すと、任意のユーザーの有効な認証情報を大規模に収集できます。CDN（Akamai/Cloudflare）経由でも、CDN とオリジン間のホップでデシンクが起きれば機能します。hunt-ato につながります。

---

関連するスキルとチェーン

• hunt-cache-poison — スマグリングとキャッシュを組み合わせる方法は、典型的なクリティカルチェーンです。スマグリングしたリクエストが、その後のすべての被害者に返されるキャッシュレスポンスになります。チェーンの基本要素：レスポンスボディに攻撃者の HTML／JS を含むリクエストを CL.TE でスマグリングする → フロントエンドキャッシュがそれを人気の URL（/、/login）に保存する → デシンクによるポイズニングが発生し、スマグリングしたリクエストが後続の N 人の被害者に対するキャッシュレスポンスになり、キャッシュ TTL の間持続します。
• hunt-auth-bypass — スマグリングにより、フロントエンドの WAF／認証プロキシがフィルタリングする内部専用ルートに到達します。チェーンの基本要素：外部からの /admin/* をブロックするフロントエンド ACL をすり抜けるよう、GET /admin/users HTTP/1.1 をスマグリングする → バックエンドが、信頼された内部ソースからのリクエストであるかのようにスマグリングしたリクエストを処理する → 内部ルーティングされたリクエストをスマグリングしてフロントエンド認証を回避する → レスポンスキューに管理者データが入ります。
• hunt-idor — スマグリングにより、次のユーザーのセッション Cookie が攻撃者の制御するリクエストパスに付与されます。チェーンの基本要素：Cookie を付けずに GET /api/me HTTP/1.1 をスマグリングする → バックエンドが次に到着する正規ユーザーの接続 Cookie と組み合わせる → 被害者のセッション Cookie が攻撃者のスマグリングしたリクエストに付与される → 攻撃者が被害者の PII／トークンを含むレスポンスを読み取ります。
• hunt-xss — スマグリングにより、URL パラメーターに一度も現れることなく、次の被害者のレスポンスストリームに XSS ペイロードを注入します。チェーンの基本要素：スマグリングしたリクエストボディに含まれるリフレクトペイロードが、バックエンドによってキュー内の次のレスポンスにレンダリングされる → / への次の訪問者に攻撃者の HTML がインラインで返される → 訪問者にもログにも URL パラメーターが見えないまま、すべての訪問者にリフレクト XSS が発生します。
• security-arsenal — 手動での 16 進編集を行う前に、スマグリングペイロードバンク（CL.TE／TE.CL／TE.TE の難読化、H2.CL ダウングレードプローブ、h2csmuggler のワンライナー、Burp HTTP Request Smuggler 拡張機能の設定）と時間差確認テンプレートを活用してください。
• triage-validation — クリティカルと判定する前に、Pre-Severity Gate を実行してください。スマグリングしたリクエストの影響は、必ず別のクライアント／セッションから送信されたリクエストに及ぶ必要があり、自分自身の後続リクエストに及ぶだけでは不十分です。自分のブラウザーで確認した時間差だけでは、パーサーの不一致を示すにすぎず、悪用可能なスマグリングとは言えません。