今日のウェブ開発において、セキュリティは単なる「付加価値」ではなく、ビジネスを継続するための「必須要件」です。特に、動的なウェブサイトでは、ユーザーからの入力を適切に処理しないことで、深刻な脆弱性が生じることがあります。本連載では、セキュアなウェブサイト構築のための技術を解説します。第1回目は、意外と見落とされがちな「HTTPヘッダ・インジェクション」に焦点を当てます。
HTTPヘッダ・インジェクションとは何か
HTTPヘッダ・インジェクションとは、ウェブアプリケーションがHTTPレスポンスヘッダを生成する際に、外部からの入力値（URLパラメータやフォームの入力値など）を適切にサニタイズ（無害化）せずに組み込んでしまうことで発生する脆弱性です。
HTTPレスポンスは、ステータスライン、ヘッダ行、空行、ボディの順で構成されています。ヘッダ行は「名前: 値」の形式で記述されますが、改行コード（CRLF：キャリッジリターンとラインフィード）が含まれると、ウェブサーバやブラウザはそれを「ヘッダの終了」と誤認します。攻撃者はこの仕様を悪用し、意図的に改行コードを挿入することで、本来存在しないヘッダを追加したり、レスポンスボディを捏造したりします。
なぜこの脆弱性が危険なのか
HTTPヘッダ・インジェクションが成功すると、攻撃者は以下のような攻撃を実行可能です。
1. **HTTPレスポンス分割攻撃（HTTP Response Splitting）**:
改行コードを挿入してレスポンスを分割し、2つ目のレスポンスを作成します。これにより、キャッシュサーバを汚染し、他のユーザーに対して悪意のあるコンテンツを表示させることが可能です。
2. **クロスサイトスクリプティング（XSS）の誘発**:
`Set-Cookie`ヘッダを不正に注入してセッションを乗っ取ったり、`Content-Type`ヘッダを書き換えてHTMLとして解釈させ、スクリプトを実行させたりします。
3. **オープンリダイレクト**:
`Location`ヘッダを書き換え、ユーザーをフィッシングサイトへ誘導します。
脆弱性が生じるコードの例
例えば、以下のようなPHPコードを考えてみましょう。
$url = $_GET[‘redirect_url’];
header(“Location: ” . $url);
このコードでは、`$url`変数に`http://example.com\r\nSet-Cookie: session_id=malicious_value`のような値が入力された場合、サーバは以下のようなレスポンスを生成してしまいます。
HTTP/1.1 302 Found
Location: http://example.com
Set-Cookie: session_id=malicious_value
…
ブラウザはこれを受け取り、悪意のあるCookieを保存してしまいます。これがHTTPヘッダ・インジェクションの典型的な発生メカニズムです。
防御策：インジェクションを防ぐための原則
この脆弱性を防ぐための最も根本的な対策は、「ユーザー入力を直接HTTPヘッダに出力しない」ことです。しかし、仕様上どうしても動的な値を出力しなければならない場合は、以下の対策を徹底してください。
1. 改行コードの除去
入力値に含まれるCR（キャリッジリターン：`\r`）およびLF（ラインフィード：`\n`）を厳格に削除してください。多くの言語では、入力値のバリデーションを行う際にこれらの文字が含まれていないかチェックする関数が用意されています。
2. ライブラリの適切な利用
現代のフレームワーク（Laravel, Django, Springなど）の多くは、`header()`関数に直接改行コードが含まれている場合、例外を投げるか、自動的に除去する機構を備えています。可能な限り、個別のヘッダ操作関数を使わず、フレームワークが提供するリダイレクト用メソッドやレスポンスオブジェクトを使用してください。
3. 入力値のホワイトリスト検証
URLパラメータなどでリダイレクト先を指定する場合、直接URLを受け取るのではなく、内部的なIDやキーを渡し、サーバ側でマッピングテーブルを参照するように設計しましょう。これにより、ユーザーが直接ヘッダの内容を操作することを完全に防げます。
モダンなセキュリティヘッダによる防御の補強
HTTPヘッダ・インジェクションそのものの対策とは別に、万が一のインジェクションが発生した際の影響を最小限に抑えるため、以下のセキュリティヘッダを導入することを強く推奨します。
* **Content-Security-Policy (CSP)**:
スクリプトの実行元を制限することで、万が一XSSが誘発されても、外部からの悪意あるスクリプトの読み込みを防ぎます。
* **X-Content-Type-Options: nosniff**:
ブラウザによるMIMEタイプの推測を無効化し、意図しないファイル形式（例えばHTMLとして解釈される画像ファイルなど）の実行を防ぎます。
まとめ：開発者が意識すべきこと
HTTPヘッダ・インジェクションは、一見すると地味な脆弱性ですが、その被害範囲は非常に広く、セッションハイジャックからサイト改ざんまで多岐にわたります。「ウェブサーバやブラウザは、ヘッダの改行コードを境界として扱う」というプロトコルの基本特性を理解していれば、不適切な文字列操作がいかに危険であるかが直感的に理解できるはずです。
安全なウェブサイトを作るための第一歩は、データの「信頼性」を疑うことです。外部からの入力は、たとえそれがURLの一部であっても、常に攻撃のトリガーになり得るという意識を持ってください。
次回は、「SQLインジェクション」について深く掘り下げます。データベースを守るためのプリペアドステートメントの真髄について解説しますので、ぜひご期待ください。
—
**免責事項**: 本記事は教育目的で提供されており、記載された手法を許可なく他者のシステムに対して試行することは法律で禁止されています。必ず自身の管理下にある環境で検証を行ってください。
コメント