// シス担のミカタ
Webアプリケーション攻撃

HTTPヘッダインジェクション えいちてぃーてぃーぴーへっだいんじぇくしょん

HTTPレスポンス分割セキュリティ脆弱性クロスサイトスクリプティングセッションハイジャックWebアプリケーション入力値検証
HTTPヘッダインジェクションについて教えて

簡単に言うとこんな感じ！

サーバーからブラウザへの「返事の封筒（HTTPレスポンス）」に、悪意ある改行コードを紛れ込ませて、封筒の中身を書き換えちゃう攻撃だよ！クッキーを盗まれたり、偽のページを見せられたりする危険な脆弱性なんだ！

HTTPヘッダインジェクションとは

HTTPヘッダインジェクションとは、Webアプリケーションがユーザーの入力値をHTTPレスポンスヘッダに組み込む際、改行コード（\r\n）を適切に除去・エスケープしていないことを悪用した攻撃手法です。攻撃者は改行コードを含む文字列を送り込むことで、サーバーが返すレスポンスヘッダを自由に追加・書き換えできてしまいます。

HTTPの仕様では、ヘッダとボディは空行（改行コード2つ）で区切られます。この性質を利用すると、ヘッダ領域に細工した改行コードを挿入するだけで、レスポンスを丸ごと2つに分割する「HTTPレスポンス分割（HTTP Response Splitting）」にまで発展させることもできます。結果として、攻撃者がでっち上げた偽のHTTPレスポンスをブラウザに送りつけることが可能になります。

実務的な被害としては、セッションIDの固定化・ハイジャック、クロスサイトスクリプティング（XSS）の誘発、フィッシング目的の偽ページ表示、キャッシュポイズニングなどが挙げられます。開発者が「リダイレクト先URLをそのままヘッダに埋め込む」といった実装をしがちな箇所で頻繁に発生するため、特に注意が必要な脆弱性です。

攻撃の仕組みと構造

HTTPレスポンスの基本構造

HTTPレスポンスは「ステータス行 → ヘッダ → 空行 → ボディ」という順序で構成されています。

HTTP/1.1 302 Found                ← ステータス行
Location: https://example.com/   ← ヘッダ（1行目）
Set-Cookie: session=abc123        ← ヘッダ（2行目）
                                  ← 空行（ヘッダ終端）
<html>...</html>                  ← ボディ

攻撃が起きる典型的な実装例

リダイレクト先URLをユーザー入力から取得してそのまま Location ヘッダに埋め込む実装が狙われます。

# 危険な実装例（Python/Flask風）
redirect_url = request.args.get("url")
response.headers["Location"] = redirect_url  # ← 改行チェックなし！

攻撃者が次のような値を送り込むとどうなるでしょうか。

https://example.com/%0d%0aSet-Cookie:%20session=attacker_value

%0d%0a はURLエンコードされた \r\n（改行コード）です。サーバーがこれをデコードしてヘッダに埋め込むと：

HTTP/1.1 302 Found
Location: https://example.com/
Set-Cookie: session=attacker_value   ← 攻撃者が挿入した偽ヘッダ！

被害のパターン一覧

攻撃パターン仕組み主な被害
セッション固定攻撃偽の Set-Cookie ヘッダを挿入セッションハイジャック
HTTPレスポンス分割改行2つ連続で挿入しボディを偽装偽ページの表示・XSS
キャッシュポイズニングプロキシに偽レスポンスをキャッシュさせる第三者への影響波及
クロスサイトスクリプティング偽ボディにスクリプトを埋め込む個人情報窃取・操作

覚え方

「改行（\r\n）は封筒の切れ目」

HTTPヘッダは「封筒の宛名書き」、ボディは「手紙の中身」。改行コードは封筒を切る”はさみ”。 攻撃者がはさみを持ち込むと、封筒を好き勝手に切り貼りできてしまう——それがHTTPヘッダインジェクション！

歴史と背景

  • 2000年代初頭 — WebアプリケーションがURL・フォーム入力値をHTTPレスポンスヘッダに動的に組み込む実装が急増。この頃から脆弱性として認識され始める
  • 2004年 — セキュリティ研究者のKlein氏らが「HTTP Response Splitting」として体系的に論文化・公開。業界全体に問題が広く認知される
  • 2005年前後 — OWASP（Webアプリセキュリティの標準化団体）がガイドラインに掲載。主要フレームワークが改行コードの自動除去を実装し始める
  • 2013年 — IPA（情報処理推進機構）が「安全なウェブサイトの作り方」改訂版でHTTPヘッダインジェクションを重点項目として明示
  • 現在 — 多くのWebフレームワーク（Rails、Django、Spring等）は標準でヘッダへの改行コード挿入を禁止・例外スローするよう対策済み。しかし自前実装や古いシステムでは今も発生する

対策と関連する防御技術

攻撃を防ぐポイントは「ヘッダに組み込む前に改行コードを取り除く」という一点に集約されます。

HTTPヘッダインジェクション 攻撃フローと対策ポイント 攻撃者 改行コード混入の リクエスト送信 Webアプリ（脆弱） 入力値を検証せず ヘッダに直接埋め込む 汚染されたレスポンス 偽ヘッダ挿入 / レスポンス分割発生 被害発生 Cookie盗難等 ▼ 対策を入れると... 攻撃者 改行コード混入の リクエスト送信 Webアプリ（対策済） 改行コードを除去 / 例外をスロー 正常なレスポンス 改行なし・安全な ヘッダのみ出力 攻撃失敗 ユーザー安全 主な対策方法 ① 改行コードの除去 \r（CR）と\n（LF）を ヘッダ埋め込み前に サニタイズする ② フレームワーク活用 Rails・Django等の ヘッダセット機能は 自動で改行を禁止 ③ 入力値の許可リスト リダイレクト先URLは 許可済みのものだけ 受け付けるよう制限

具体的な対策コード例

# 安全な実装例：改行コードを除去してからヘッダに設定
import re

def safe_redirect(redirect_url):
    # \r と \n をすべて除去（サニタイズ）
    safe_url = re.sub(r'[\r\n]', '', redirect_url)
    response.headers["Location"] = safe_url

XSSとの違いを整理

比較項目HTTPヘッダインジェクションクロスサイトスクリプティング（XSS）
攻撃対象HTTPレスポンスヘッダHTMLボディ（Webページ本文）
悪用する文字改行コード \r\n<script> タグ等のHTML特殊文字
主な被害Cookie操作・レスポンス分割スクリプト実行・情報窃取
組み合わせヘッダ経由でXSSを引き起こすことも可能別の脆弱性と組み合わせることも

関連する規格・RFC

規格・RFC番号内容
RFC 9110HTTP Semantics — HTTPレスポンスヘッダの正式仕様。改行コードはヘッダ区切りとして定義されている
RFC 9112HTTP/1.1 — ヘッダのフォーマットと \r\n による区切り規則を規定
CWE-113Improper Neutralization of CRLF Sequences in HTTP Headers — CWE（共通脆弱性タイプ一覧）における本脆弱性の識別番号
OWASP Testing GuideHTTPヘッダインジェクションのテスト手法・検出方法を記載（OTG-INPVAL-015）
IPA「安全なウェブサイトの作り方」国内向け開発ガイドライン。HTTPヘッダインジェクションを重点脆弱性として掲載

関連用語