【入門編】HTTPヘッダーインジェクションとレスポンス分割攻撃 – アプリケーションセキュリティ & 安全な開発防御ガイド

こんにちは。現場で泥臭いインシデント対応を繰り返していると、「セキュリティは技術以前に、想像力の勝負だな」とつくづく感じます。

今日は、初心者の方が意外と見落としがちな、でも一度食らうと致命的なダメージになりかねない「HTTPヘッダーインジェクション(レスポンス分割攻撃)」についてお話しします。

専門用語の羅列は置いておいて、まずは身近な「泥棒」の話から始めましょう。

—

1. なぜ「ヘッダー」が狙われるのか?(泥棒のトリック)

想像してみてください。あなたは宅配便の荷物を受け取ろうとしています。配送伝票には「届け先住所」や「品名」が書かれていますよね。Webの世界で、この配送伝票の役割を果たすのが「HTTPヘッダー」です。

通常、Webサーバーはブラウザに対して「このページはここにあるよ」「文字コードはUTF-8だよ」といった情報を伝票に書いて渡します。

しかし、もし攻撃者がこの伝票に「改行コード(CRLF)」を忍び込ませたらどうなるでしょう?

攻撃のメカニズム:伝票を真っ二つにする

CRLF(キャリッジリターンとラインフィード)というのは、プログラムの世界で「ここで改行してね」という合図です。

攻撃者は、本来一つであるはずの伝票の中に「改行」を紛れ込ませます。すると、ブラウザや中継地点のプロキシサーバーは、こう勘違いします。

  • 「あれ? ここで伝票が終わって、次の新しい伝票が始まったぞ?」

これが「レスポンス分割攻撃」です。一枚の紙が二枚に裂け、後半部分に攻撃者が自由に書いた「偽の伝票」が紛れ込むことになります。これにより、本来表示されるはずのないWebページを無理やり表示させたり(XSS)、キャッシュサーバーに偽の情報を覚えさせたり(キャッシュ汚染)するわけです。

—

2. どんな時に起きるの?

最も多いケースは、「ユーザーからの入力を、そのままHTTPヘッダーとして出力してしまう」という実装ミスです。

例えば、Webサイトで「リダイレクト(別のページへ転送)」機能を実装しているとしましょう。

// 危険なコードの例(PHP)
$url = $_GET[‘redirect_url’]; // ユーザーが入力したURL
header(“Location: ” . $url); // そのままヘッダーにセット!

もし攻撃者が redirect_url に「http://evil.com\r\nSet-Cookie: session_id=fake_id」のような値を送り込んだらどうなるでしょうか?
サーバーは「Locationヘッダー」の後に「Set-Cookieヘッダー」が続いていると誤認して、被害者のブラウザに偽のセッションIDを植え付けてしまうのです。

—

3. どうやって防ぐ?(最強の防犯対策)

対策はシンプルですが、徹底することが重要です。一歩ずつ学んでいきましょう!

対策①:ユーザー入力をそのままヘッダーに流さない

これが鉄則です。もしヘッダーにユーザーの入力値を反映させる必要があるなら、必ず「ホワイトリスト」で管理してください。

  • 許可されたURLだけを辞書のように定義しておく
  • 「改行コード」が含まれていないかチェックする

対策②:現代のフレームワークを信じる

最近のモダンなフレームワーク(Laravel, Express, Djangoなど)は、内部的にこの手のインジェクションを防ぐ仕組みが備わっています。自分でヘッダーを細かく操作しようとせず、フレームワークが用意したリダイレクト用関数を使いましょう。

対策③:防御ヘッダーを活用する(現代の鎧)

HTTPヘッダーインジェクションを直接防ぐわけではありませんが、被害を最小限に抑えるための「防御ヘッダー」を設定しておくのが現代の常識です。

Nginxの設定例:

クリックジャッキング対策
add_header X-Frame-Options “SAMEORIGIN”;

XSS対策(ブラウザのフィルタを有効化)
add_header X-XSS-Protection “1; mode=block”;

コンテンツセキュリティポリシー(最強の防具)
信頼できるソース以外からのスクリプト実行を禁止します
add_header Content-Security-Policy “default-src ‘self’;”;

—

4. 最後に:セキュリティは「疑う」ことから始まる

「自分が書いたコードは、入力値が必ず正常なものだ」と信じきってしまうのが、セキュリティ事故の入り口です。

  • 「もし、ここに悪意ある文字列が入っていたら?」
  • 「この改行コードは、どこで悪用される可能性がある?」

そうやって一歩立ち止まって考えるだけで、あなたのコードは驚くほど頑丈になります。

セキュリティは、一度設定して終わりではありません。泥棒が新しい手口を考えるように、私たちも常に学び続ける必要があります。でも、安心してください。こうして基本的な仕組みを理解しようとする姿勢があれば、あなたはもう、立派な「守れるエンジニア」の第一歩を踏み出しています。

また次回の記事で、より深い泥臭い現場の話をしましょう!応援しています。

コメント

タイトルとURLをコピーしました