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

何が起きるか

HTTPリクエストスマグリングは、前段のプロキシと後段のアプリサーバーが、同じ通信データの区切りを違って解釈する問題です。前段が一つのリクエストの本文として検査・転送した部分を、後段が別のリクエストとして処理する場合があります。

説明用に、本文の長さを示すContent-Lengthと、区切りごとに長さを付けるTransfer-Encodingの解釈が前後で異なる接続を考えます。攻撃者が二通りに区切れるデータを送ると、前段は管理用URLの文字列を本文の一部として通し、後段はその位置から次のHTTPリクエストが始まると読むことがあります。たとえば本文40バイトの中で、chunkedの終了を示す0と空行が先頭5バイトにあり、その後に別のHTTPリクエストとして読める35バイトがある例です。前段がContent-Lengthの40バイトを全て本文と読み、後段がTransfer-Encodingの終了位置を採用すると、後段は残る35バイトを次のリクエストとして読みます。両方の指定を受け付ける不備のある構成を仮定しており、正常な受信処理の動作ではありません。

前段はその管理用URLを独立した操作として検査していません。管理操作の制限を前段にしか置かず、後段が届いた操作をそのまま実行する構成なら、攻撃者が本来拒否される管理操作を呼べます。実際の結果は解析差だけで決まらず、接続の再利用や後段の認証・認可に依存します。

正常ならどう動くか

前段のプロキシが後段へHTTPリクエストを転送するとき、両者は本文の終わりと次のリクエストの開始を同じ位置と判断する必要があります。Content-Lengthは本文のバイト数を、Transfer-Encoding: chunkedは分割した本文の各部分の長さと終了の印を使います。

長さ情報が曖昧な入力を拒否し、HTTPバージョンを変換する場合も一つのリクエストを後段の一つの操作へ対応付けます。同じ後段接続を次の利用者へ再利用するときに前の本文を残さず、レスポンスも対応するリクエストへ返すことが必要です。ここで再利用するのは、利用者のブラウザから前段への接続とは別の、前段から後段への接続です。前段は複数利用者の要求をこの接続へ順に送る場合があるため、後段がまだ次の要求として読んでいない攻撃者のデータが残ると、次の利用者のデータにも影響します。

不備と攻撃が成立する流れ

攻撃者が曖昧な長さ情報を含むHTTPリクエストを前段へ送ります。前段が一つの本文として後段へ転送したデータの途中を、後段が次のリクエストの開始と判断すると、その部分が別の操作として実行されます。前段はその操作を独立したリクエストとして検査していません。

後段の共有接続に攻撃者のデータが読み残されると、後から来る別利用者のHTTPリクエストと結び付く場合があります。HTTP/2からHTTP/1.1への変換で、元のリクエストにはなかった曖昧な区切りが生まれる場合もあります。解析差だけでなく、接続の再利用と後段の処理を確認します。たとえば後段が攻撃者のデータを「次のPOSTの先頭」として読み残していると、前段が次の利用者のリクエストを送った際、それが攻撃者のPOST本文へ取り込まれる構成があります。実際にどこが先頭や本文になるかは、前後の解析差と残されたバイト列で決まります。

起こり得る被害と条件

アクセス制御迂回の例では、前段が本文として通したデータを、後段が管理用パスへの独立したHTTPリクエストとして処理します。前段だけにあった制限を通過し、後段にも独立した認可がなければ、攻撃者が管理操作を呼べるおそれがあります。

取り違えの例では、接続上のリクエストとレスポンスの順序がずれ、被害者の情報を含むレスポンスが攻撃者のリクエストへの応答として返る場合があります。攻撃者は自分の接続で他人向けの内容を受け取ります。この結果には、解析差に加えて、そのような応答の対応付けが起きる構成が必要です。順番で対応付ける説明用の構成では、前段が一件Aを送ったつもりでも、後段がAと隠れたBを処理して応答RA・RBを返します。前段がRAをAへ返した後、次の被害者要求Vの応答として残るRBを返すと、後段がVへ作ったRVはさらに残ります。その次に攻撃者が要求Cを送ったとき、前段がRVをCへの応答として返せば、攻撃者に被害者の内容が届きます。

キャッシュ汚染の例では、前段が後段から受け取った別のレスポンスを通常のURLの応答と誤認し、共有キャッシュへ保存します。後から正規URLを開いた利用者にも不正なページが返り、攻撃者サイトへの誘導などにつながる場合があります。その応答がキャッシュの保存ルールを満たし、攻撃時と被害者アクセス時のキーが一致する必要があります。キーは再利用する応答を選ぶ識別情報で、たとえばURLがキーなら同じURLへの要求に保存済み応答が返ります。

防ぎ方と、防げる理由

不正・曖昧なHTTPリクエストを拒否し、更新済みのプロキシとサーバーを使って解析をそろえます。HTTPバージョン変換後も長さや区切りを一意に扱い、前段が検査した一つの操作と後段が実行する一つの操作を一致させます。管理機能の認可は後段でも行い、前段の検査だけに依存しません。

よくある誤解

前段のWAFが検査しても、後段が別の区切りで読めば見逃す場合があります。前段との通信にHTTP/2を使っていても、後段でHTTP/1.1へ変換する構成では安全性を別途確認する必要があります。

実装の確認点

CDN、ロードバランサー、プロキシ、アプリのHTTPバージョンと変換箇所を整理します。長さ情報の処理と接続の再利用を確認し、他人の要求へ影響する実験は共有の本番環境で行いません。 CDNは配信の前段で応答を保存・再利用し、ロードバランサーは複数サーバーへ接続を振り分けます。これらを含む通信の各段階で、HTTPの解析・変換と後段接続の再利用が行われる場所を調べます。

出典・確認範囲

[1] Web Security Academy: HTTPリクエストスマグリングPortSwigger / 確認日 2026-10-29