HTTPヘッダーインジェクションの深層：プロトコル解釈の「隙間」を突く攻撃とアーキテクチャ防衛
HTTPというプロトコルは、驚くほど「性善説」に基づいている。RFC 7230において、ヘッダーフィールドはCRLF（\r\n）で区切られると定義されているが、多くのプログラミング言語やミドルウェアは、この制御文字を信頼しすぎるあまり、アプリケーション層からの入力を検証なしにヘッダーへ流し込むという致命的な過ちを犯してきた。
今回は、単なる「脆弱性リスト」の解説ではない。HTTPレスポンス分割（Response Splitting）が、現代のインフラ環境においてどのようにキャッシュ汚染やXSSへと昇華されるのか、その低レイヤのメカニズムと、アーキテクトが打つべき防衛の「急所」について語る。
—
1. プロトコル層の亀裂：CRLFインジェクションの論理
攻撃者が狙うのは、HTTPレスポンスの「境界」だ。例えば、ユーザー入力をそのままLocationヘッダーに含めるアプリケーションがあったとしよう。
脆弱なコード例（Python/Flask）
攻撃者が URL パラメータに “\r\nSet-Cookie: session=evil; HttpOnly=false\r\n\r\n” を送り込むと…
@app.route(‘/redirect’)
def redirect_user():
target = request.args.get(‘url’)
response = make_response(redirect(target))
return response
サーバーサイドのライブラリが、この\r\nをエスケープせずにソケットへ書き出すと、TCPストリーム上でレスポンスが二つに分断される。クライアント（ブラウザ）やプロキシサーバーは、最初のヘッダーが終了したと錯覚し、二つ目のレスポンスとして攻撃者が注入した「偽のコンテンツ」を解析し始める。
これがHTTPレスポンス分割の正体だ。現代ではブラウザの防御機構が進化したとはいえ、キャッシュサーバー（CDN）やリバースプロキシを介したキャッシュ汚染の脅威は消えていない。
2. キャッシュ汚染：インフラを武器に変える手法
HTTPレスポンス分割は、単体でXSSを狙うよりも、CDNやロードバランサーの「解釈の揺らぎ」を突く攻撃として真価を発揮する。
特に、Content-LengthヘッダーとTransfer-Encodingの不整合を突く攻撃と組み合わせると、キャッシュサーバーが誤ったリクエストに対して攻撃者のペイロードをキャッシュしてしまう。一度汚染が成立すれば、その後の数千、数万人の正規ユーザーが、攻撃者が仕込んだスクリプトを読み込むことになる。
監査と防御の要諦
コードレビューや静的解析（SAST）だけでこの脆弱性を防ぐのは困難だ。以下のアーキテクチャ・ガードレイルを導入せよ。
- ヘッダーの正規化とバリデーション:
アプリケーション層でヘッダーを構築する際、制御文字（0x0D, 0x0A）が含まれていないか厳密にチェックする。
- WAFによるプロトコル・アノマリ検知:
リクエストおよびレスポンスのHTTPヘッダーに%0D, %0Aなどのエンコードされた制御文字が含まれている場合、即時遮断するポリシーを設定する。
- 構造化されたヘッダー構築:
言語標準のヘッダー追加関数を使用し、個別の文字列連結は絶対に許容しない。
// 安全なヘッダー構築の例（Go言語）
func SecureRedirect(w http.ResponseWriter, url string) {
// URLのバリデーション：スキームのホワイトリスト化
if !isValidUrl(url) {
http.Error(w, “Invalid URL”, http.StatusBadRequest)
return
}
// SetHeaderは制御文字を自動的にサニタイズ、あるいは拒否する実装を持つライブラリを利用する
w.Header().Set(“Location”, url)
w.WriteHeader(http.StatusFound)
}
3. 生成AI時代の新たな「インジェクション」リスク
今、我々アーキテクトが最も警戒すべきは、LLM（大規模言語モデル）のAPI連携におけるヘッダーインジェクションだ。
生成AIが生成したテキストを、そのままバックエンドのHTTPレスポンスに反映させるアーキテクチャが急増している。AIが攻撃者のプロンプトによって「ヘッダーを含んだレスポンスを生成」するように誘導されれば、それはアプリケーション層の脆弱性をAIが自動的に引き起こすことを意味する。
次世代の防衛アーキテクチャ：ガードレイルの設計
プロンプトエンジニアリングでの対策には限界がある。セキュリティ設計者として以下の二重構造を実装せよ。
1. AI出力に対する構造化バリデーション層: AIが生成したテキストを直接HTTPヘッダーに流すのではなく、一度シリアライザを通し、許可されたヘッダーキーと値のみを抽出する中間APIを挟む。
2. ゼロトラスト・ネットワーク監視: サーバーから外へ出るレスポンスヘッダーのパターンをAI監視し、異常なヘッダー出現（例：Set-Cookieが不自然なタイミングで挿入される等）をリアルタイムで検知・遮断する。
最後に：防御は「疑うこと」から始まる
HTTPヘッダーインジェクションは、プロトコルの仕様と実装の「隙間」を突く、極めて古典的かつ狡猾な攻撃だ。しかし、この脆弱性が今なお絶滅しないのは、開発者がHTTPを「単なる文字列の集合」としか見ていないからである。
HTTPは、クライアントとサーバーの間の「合意」の上に成り立つ繊細なプロトコルだ。その境界線（デリミタ）が侵害された瞬間、アプリケーションの信頼性は崩壊する。
常に、「入力されるデータは全て敵である」という原則に立ち返り、システムアーキテクチャの端々を疑うこと。それこそが、最高峰のホワイトハッカーとして唯一信頼できる防御の土台である。
—
本稿を読んだエンジニア諸君へ。明日、貴方のシステムのCI/CDパイプラインに、ヘッダーに制御文字を混入させるようなテストケースを追加してほしい。それが、セキュリティの「現場」を劇的に変える第一歩になるはずだ。
コメント