HTTPレスポンス分割は、HTTPヘッダインジェクションの脆弱性を悪用し、一つのHTTPレスポンスを攻撃者が意図した二つ以上のレスポンスに強制的に分割させる攻撃手法だ。 単にヘッダを不正に追加するだけでなく、完全に偽装されたHTTPレスポンスを作り出すことで、より深刻な被害を引き起こす。

攻撃の仕組み

HTTPプロトコルでは、ヘッダ部とボディ部は「空行」、つまり連続した改行コード（CRLFCRLF）によって明確に区切られている。この仕様を悪用する。

攻撃者は、アプリケーションがレスポンスヘッダに埋め込むパラメータに、意図的に連続した改行コード（%0d%0a%0d%0a）を注入する。 これにより、アプリケーションが生成するレスポンスは以下のようになる。

[本来のレスポンスヘッダの一部]
... (攻撃者の入力値) ...
CRLF
CRLF
[攻撃者が作成した偽のHTTPレスポンス]
HTTP/1.1 200 OK
Content-Type: text/html

<script>/* 不正なスクリプト */</script>

このレスポンスを受け取ったプロキシキャッシュサーバやWebブラウザは、これを二つの独立したレスポンスとして解釈してしまう。

1. 本来のレスポンス（途中で分断されている）
2. 攻撃者が完全に制御する偽のレスポンス

この2番目のレスポンスを他のユーザーに送りつけたり、キャッシュさせたりするのが攻撃の狙いだ。

脅威

この攻撃が成功すると、以下のような被害が発生する。

• Webキャッシュ汚染 (Web Cache Poisoning)
  • 攻撃者が生成した偽のレスポンスを、中継しているプロキシキャッシュサーバにキャッシュさせる。その後、同じページにアクセスした別の正規ユーザーに対して、キャッシュされた汚染コンテンツ（例：フィッシングサイトのHTML）が送りつけられてしまう。
• クロスサイト・スクリプティング (XSS)
  • 偽のレスポンスに不正なJavaScriptを埋め込むことで、他のユーザーのブラウザ上で実行させる。これにより、クッキー情報の窃取やセッションハイジャックが可能になる。
• 他ユーザーへのなりすまし・情報窃取
  • 複雑な構成では、分割された2番目のレスポンスが、キューで待機している次のユーザーのリクエストに対する応答として誤って処理されることがある。

対策

根本的な原因はHTTPヘッダインジェクションであるため、対策はそれに準ずる。

1. 入力値からの改行コードの除去
   • レスポンスヘッダに含める可能性のある全ての外部入力から、改行コード（\r, \n）を徹底的にフィルタリングし、除去する。これが最も確実な対策だ。
2. 安全なAPIの使用
   • 現代的なWebアプリケーションフレームワークが提供するヘッダ設定用のAPIを利用する。これらの多くは、改行コードのような危険な文字を自動的に無害化する機能を備えている。

HTTPレスポンス分割は、ヘッダインジェクションという一つの脆弱性から、いかにして広範囲で深刻な攻撃へ発展しうるかを示す典型的な例だ。