2026.05.01 2026.05.02

【HTTPリクエストスマグリング編】境界の解釈ズレを突く攻撃と守り方｜CTF思考フレームワーク #18

安全に生きたい編集部

📖 この記事はシリーズの一部です

「CTF思考フレームワーク」　Web脆弱性編　#18 / 公開中 10記事　→　シリーズ一覧を見る →

HTTPリクエストスマグリングは、フロントエンド（CDN・ロードバランサ）とバックエンド（アプリサーバ）が「リクエストの境界」を別の解釈をする隙間を突く攻撃。James Kettle氏の研究で2019年以降一気に注目された分野で、HTTP/2絡みの新ベクトルも続々登場しています📦

プロキシとアプリで「ここまでが1リクエスト」の解釈がズレると、攻撃者のリクエストが他人のリクエストに「密輸」されます。怖いやつです。

難易度：★★★（上級）

フロントとバックエンドの解釈差を突く高度な攻撃。設定ミスで認証もキャッシュも飛びます🚂

スマグリングはフロント(CDN/LB)とバック(アプリサーバ)で1リクエストの境界が違うことを突く攻撃だよ🔌

Contents

👀 観察フェーズ：まず何を見る？
🤔 仮説フェーズ：攻撃者は何を考える？
🔬 検証フェーズ：どうやって確かめる？
⚔️ 攻撃フェーズ：実際の手口
🛡️ 防御フェーズ：どう守る？
🛡️ 今日からできる対策ツール
⚠️ よくある落とし穴
🧰 ツール早見表
🎓 本気で学びたい人へ
📚 もっと深く学びたい人へ
📚 次に読みたい
🧪 自分で検証してみる
⚖️ 大事なお約束
📖 次に読みたい

👀 観察フェーズ：まず何を見る？

まずContent-LengthとTransfer-Encodingの両方を持つリクエストでフロント/バックの挙動差を観察🔍

スマグリングは「フロントとバックの組み合わせ」が9割。同じバックエンドでもフロントが変わると挙動が変わります。

CL.TE / TE.CL / TE.TEの3パターンが基本。HTTP/2ダウングレード経路も最近のホットスポットです👀

リバースプロキシって便利な反面、解釈ズレが生まれやすいんだね…💧

🤔 仮説フェーズ：攻撃者は何を考える？

スマグリングの典型は4パターン。

攻撃者の仮説。

🔢 仮説①：CL.TE

フロントがContent-Length、バックがTransfer-Encodingを尊重→後続リクエストの先頭にペイロードが混入。

🔁 仮説②：TE.CL

逆パターン。フロントがchunkedを解釈してバックがContent-Lengthに従い、境界がズレて密輸成立。

🤝 仮説③：TE.TE(難読化)

両方Transfer-Encodingを見ても、片方だけTransfer-Encoding: xchunked等で無視させる難読化テクで境界をずらす。

🌐 仮説④：HTTP/2ダウングレード

クライアント↔フロントはH2で、フロント↔バックはH1に変換される時、擬似ヘッダ→生ヘッダ変換のズレを狙う。

スマグリングは攻撃の起点。それ自体より「他攻撃と組み合わせた連鎖」が本領発揮です。

攻撃が刺さると他人のリクエストを乗っ取れるから実害がエグいんだね😨

🔬 検証フェーズ：どうやって確かめる？

BurpのHTTP Request Smuggler拡張で自動診断！手動ならContent-Length: 0とTransfer-Encoding: chunkedを併記して時間応答を観察🧪

検証ステップ。

Time-based diff技法でサイレントなズレも検出できるんだね⏱️

⚔️ 攻撃フェーズ：実際の手口

スマグリングの実害はこの3つ。

実戦シナリオ。

① セッション窃取

次に来た他人のリクエストを自分のレスポンスとして取得。Cookie・Authorizationヘッダが丸ごと盗める。

② キャッシュ汚染

密輸したリクエストでサーバを騙し、人気ページに悪意レスポンスをキャッシュさせて全ユーザに配布。

③ WAF/認証バイパス

フロントのWAFや認証チェックを回避して、内部APIに直接アクセス。

CTF{front_and_back_must_agree_on_request_boundary}

スマグリングは「プロトコル仕様の解釈差」を突く高度な攻撃。対策は単純に「両者で解釈を揃える」ことです。

🛡️ 防御フェーズ：どう守る？

スマグリング対策の3点セット！🛡️

防御の3点。

🌐 HTTP/2エンドツーエンドに統一

フロントもバックもHTTP/2で統一。ダウングレードがなくなれば境界解釈差も生まれない。

🚫 曖昧ヘッダを厳格拒否

Content-LengthとTransfer-Encodingが同時に存在するリクエストを即400。これだけで大半が死ぬ。

🔄 接続プールの再利用ポリシー

リバースプロキシ→バックエンドのkeepalive接続を制限。1リクエストごとに切れば後続リクエスト混入が起きない。

「ヘッダの解釈を1つに揃える」のがスマグリングの本質的対策だね💪

🛡️ 今日からできる対策ツール

パスワードの使い回しや手動管理はどんなに気をつけても限界があります。🔑 パスワード管理ツール「ワンパス」なら、複雑なパスワードを安全に保管して「1つのマスターパスワード」だけ覚えられるので、今日から始める防御策としてしっくりきます。

※ 上記は他社サービスへのリンクです。購入は各自でご判断ください。

⚠️ よくある落とし穴

よくあるミス。

CDNを入れた時にバックエンドのHTTPサーバ設定を見直さない。
HTTP/2を導入しても、バックエンドが古いHTTP/1.1のままでダウングレード経路が残る。
Transfer-Encodingを実装する全ノードで「同じ仕様解釈」になっていない。
WAFを「フロント側」だけに置き、密輸後のリクエストを見逃す。
スマグリング検出ツール（Smuggler、HTTP Request Smuggler）でテストしていない。
James Kettleのリサーチに沿った定期テストを実施していない。

🧰 ツール早見表

使う道具。

ツール	用途	ひと言
HTTP Request Smuggler (Burp拡張)	自動検出	主要パターンを網羅
Smuggler.py (defparam)	CLI検出ツール	Pythonベース、軽量
h2csmuggler	H2C Smuggling専用	WebSocketアップグレード経路の密輸
PortSwigger Research	最新ベクトル	James Kettle氏の論文・PoC公開