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

こんにちは、アンペンです！

前回は、XMLの外部実体参照を悪用するXXEを扱いました。

今回は、フロントエンド(CDN・LB・プロキシ)とバックエンドサーバの「リクエスト解釈のズレ」を突くHTTPリクエストスマグリングを見ていきます。境界の解釈ズレを突く攻撃と、その守り方を一緒に見ていきましょう。

リクエストを密輸する、ってどういうこと？

フロントエンドとバックエンドで『1つのリクエストの終わり』をどこと判定するかがズレると、隙間に第2のリクエストを忍ばせられるんだ。後続の利用者のリクエストに紛れて悪用されることもある。

ここから少しだけ歯ごたえのある話になります。HTTPリクエストスマグリング——名前からして難しそうですよね。でも芯にあるのは、とても素朴な問題です。『1通の手紙はどこで終わるか』を、入口の係と奥の係が違う場所で判断してしまう、ただそれだけ。今日は共同郵便受けの“仕切り違い”にたとえて、この“見えない攻撃面”をほどいていきます。

「リクエストの終わり」はどう決まるか

HTTPはひとつのコネクションで複数のリクエストを連続して送る仕組み(Keep-Alive)を持っています。だから、サーバは「ここまでがリクエスト1、ここからはリクエスト2」という境界の判定が必要です。

境界の判定には主に2つのヘッダが使われます。 Content-Length(本文の長さを指定)と、 Transfer-Encoding: chunked(チャンク終端で判定)です。フロントとバックエンドが違う基準で判定すると、解釈にズレが生まれます。

問題は、この“区切り線の引き方”が2通りあることです。一つは「本文はこの長さですよ」と長さで申告する方法（Content-Length）。もう一つは「ここで終わり、という合図を入れますね」と終端マークで知らせる方法（Transfer-Encoding）。どちらも正しい方法なのですが、入口の装置と奥のサーバが“別々の方法”を信じてしまうと、引かれる区切り線の位置がズレる。その一瞬のズレが、攻撃者のつけ入る隙になるんです。

そもそも、なぜ『境界』なんてものが問題になるのでしょう。実は今どきのWeb通信は、効率のために一本の通信路で何通ものリクエストを立て続けに送ります（Keep-Aliveという仕組み）。手紙を一通ずつ封筒に入れて送るのではなく、長い巻物に何通分も続けて書いていくイメージです。だからこそ受け取る側は「ここまでが1通目、ここからが2通目」という“区切り線”を、自分で正しく引く必要があるんです。

図解：境界一致 vs 境界ズレ

境界が一致していれば普通の通信ですが、ズレていると「フロントは1リクエスト」「バックは1.5リクエスト」のように見えて、隙間に攻撃用ペイロードが残ります。

『CL.TE』『TE.CL』なんて記号が並ぶと身構えますが、読み方は単純です。ピリオドの前が“入口（フロント）が信じる方”、後ろが“奥（バック）が信じる方”。たとえばCL.TEなら「フロントは長さ(CL)を信じ、バックは終端マーク(TE)を信じる」という意味です。つまり“誰がどっちを信じてズレるか”の組み合わせを名前にしているだけ。そう分かると、急に親しみやすくなりますよね。

代表的な3つの型

代表的なズレ方は3つ。フロントが長さ派でバックが終端派の『CL.TE』、その逆の『TE.CL』、そして両方とも終端派だけど“崩した書き方”の解釈が違う『TE.TE』。細かい挙動はさておき、「入口と奥で、信じる物差しが食い違っている」という一点だけ押さえれば十分です。

CL.TE / TE.CL / TE.TE

• CL.TE：フロントが Content-Length、バックが Transfer-Encoding を優先するパターン
• TE.CL：フロントが Transfer-Encoding、バックが Content-Length を優先するパターン
• TE.TE：両方とも Transfer-Encoding を見るが、混在/不正な書式に対する解釈が異なるパターン

これらが成立すると、攻撃者は「フロントは正規のリクエストだと判断」「バックは続きに第2のリクエストがある、と判断」という状態を作り、後続の正規ユーザーのリクエストに第2のリクエストを混ぜ込めます。

ここがスマグリングの一番こわいところです。被害に遭うのは、攻撃者自身ではなく“次にそのサーバを使った、まったく無関係な利用者”なんです。攻撃者が仕込んだ「区切り線の先の半端なリクエスト」が通信路に居残り、次にやってきた人の正規リクエストの“頭”にくっついてしまう。結果、その人のリクエストが攻撃者の用意した内容に書き換わったり、応答がすり替わったり。自分は何もしていないのに巻き込まれる——だからこそ、見えにくく、影響が大きい攻撃なんです。

この攻撃は中継装置が絡むので、自分のラボで“環境ごと”再現するのが理解の近道です。ねらいは攻撃の成功ではなく、「入口とサーバ、それぞれのログで、リクエストがいくつに見えているか」を見比べること。本物の中継装置やサービスに細工リクエストを送るのは、業務妨害になりかねないので厳禁です。あくまで自分で建てた練習環境の中で観察しましょう。

CTFでやってみよう：HTTPヘッダ解釈を観察する

守りの方針は、原因を思い出せばまっすぐ見えてきます。原因は“物差しの食い違い”でしたよね。

じゃあ、入口と奥で“同じ物差し”を使えば防げるってこと？

その通り！フロントとバックのHTTPの読み方（パーサ）をそろえて、バージョンも合わせる。これが一番効くんだ。さらに、長さと終端マークの両方が書いてある“欲張りな”リクエストは、入口できっぱり拒否する。最近はフロントから奥までHTTP/2で統一する手も有効だよ。要は『区切り線の引き方を、全員で一致させる』ことなんだ。

守る側なら、「境界をひとつに揃える」を徹底

HTTPスマグリングの守りは、「フロントとバックでHTTP解釈を揃える」「不正なヘッダ組合せを拒否する」が基本です。HTTP/2を末端まで使うのも有効な対策です。

『装置同士の解釈差』っていう、人間からは見えにくい攻撃面なんだね。

そう。だから『フロントとバックの実装・バージョンを揃える』運用が、何より効くんだ。

ここまでをひと言で言うと、スマグリング対策は『関係する全員が、同じ物差しで区切る』こと。コードの中の穴というより、装置と装置の“すきま”に生まれる問題なので、守りも個々のアプリではなく“経路全体の足並み”をそろえる発想になります。装置の実装とバージョンをそろえる、という地味な運用が、ここでは何より効きます。

まとめ：『境界をひとつに』が中継のセキュリティ

今日の持ち帰りは『1通の終わりは、全員で一致させる』です。HTTPリクエストスマグリングは少し上級ですが、根っこは郵便受けの仕切り違いと同じだと分かれば、もう怖くありません。長さと終端マーク、どちらの物差しもズレなく一致させる——その当たり前を経路全体で徹底することが、見えない密輸を防ぐ鍵になります。

次回は、CDNの動作を悪用して別ユーザーに有害コンテンツを配るWebキャッシュ汚染を扱います。CDNを毒で塗る攻撃と守り方を見ていきましょう。

次に読みたい記事

参考資料