HTTPヘッダインジェクション
外部入力をHTTPで返すヘッダーへ組み込む処理の不備を突き、改行などを通じて意図しないヘッダーフィールドや本文を出力させる攻撃。入力値が応答の構造として解釈されることが原因となる。
イマシルちゃんの解説
注文票の「名前」の欄に書かれた文字が、別の指示欄にまで続いてしまったら困るよね。
名前として受け取ったはずなのに、新しい指示として扱われてしまうんだ。
欄の中に入れてよい文字を確かめ、決められた欄だけに書き込む必要があるよ。
届いた紙を封筒に入れ直すだけでは、欄の区切り方の問題は直らないんだ。
より深い解説
入力が構文として扱われる
HTTP/1.1では、ヘッダーフィールドの行や、ヘッダーと本文の区切りが定められている。利用者の入力をそのまま応答へ連結すると、値に含まれた制御文字が応答の構造へ影響する場合がある。
転送先を示すLocationや、Cookieを設定するSet-Cookieなどを外部入力から動的に作る実装では、文字列の扱いを確認する必要がある。
| 本来の用途 | 問題になる扱い |
|---|---|
| ヘッダーの値として受け取る | 改行を次のフィールドの開始として扱う |
| 一つの応答を生成する | 区切りを注入され、本文や応答が追加される |
HTTPSで暗号化されていても、サーバが生成した内容そのものが不正であれば、この問題は解決しない。
起こり得る影響
| 影響 | 例 |
|---|---|
| ヘッダーの追加・変更 | 意図しないCookieの設定など |
| 本文の注入 | 偽の表示やスクリプトを含む内容を返す |
| 応答の分割 | 一つの要求に対応する出力を、複数の応答として解釈させる |
| 中継機器への波及 | 不正な内容をキャッシュへ残す |
複数の応答を作り出す手法をHTTPレスポンス分割という。影響が成立するかは、Webアプリケーションだけでなく、サーバやプロキシが不正な構文をどう扱うかにも依存する。
根本的な対策
応答全体を文字列として手作業で組み立てず、言語やフレームワークが提供するヘッダー設定機能を使う。その機能が不正な制御文字を拒否するかも確認する。
外部入力から値を作る必要がある場合は、用途に合う値だけを許可する。不要なCRやLFを受け入れず、入力が仕様に合わなければ処理を中止する。HTML用のエスケープを行うだけでは、HTTPヘッダー用の対策にはならない。
他の攻撃との区別
| 攻撃 | 意図しない解釈・操作が生じる対象 |
|---|---|
| HTTPヘッダインジェクション | HTTPの応答ヘッダーなど |
| OSコマンドインジェクション | サーバ上で実行するOSコマンド |
| クロスサイトスクリプティング | ブラウザで実行するスクリプト |
| CSRF | ログイン済み利用者の権限を使った意図しない要求 |
セッションハイジャックは、他人のセッション識別情報などを悪用して接続を乗っ取る攻撃である。攻撃の結果が関連する場合でも、入力がどの処理へ渡され、何として解釈されるかを見れば、原因を区別できる。