【テクニカル・上級編】反射型XSS（Reflected XSS）の攻撃メカニズムとHTTPリクエストの検証 – アプリケーションセキュリティ & 安全な開発防御ガイド

反射型XSSの深淵：ブラウザの「信頼」をハックするプロトコルの盲点

反射型XSS（Reflected XSS）を単なる「URLにスクリプトを埋め込んでアラートを出す遊び」と捉えているなら、あなたの設計するアプリケーションは既に敗北している。これは単なる入力値の不備ではない。クライアントとサーバー間の「信頼の境界線」を巡る、HTTPプロトコルそのものの設計思想を突いたアーキテクチャの欠陥だ。

今回は、反射型XSSのメカニズムを、プロトコル層の挙動と、現代のブラウザが強制するセキュリティコンテキストの観点から解剖する。

—

1. HTTPリクエストの流転：なぜ「反射」は防げないのか

反射型XSSの根本は、HTTPリクエスト（主にGETパラメータ）の内容が、適切にエスケープされずにHTTPレスポンスのHTMLコンテキストへ「エコー」されることにある。攻撃者は、ユーザーを罠のURLへ誘導し、被害者のブラウザ上で攻撃者のスクリプトをコンテキストの一部として実行させる。

ここで技術者が陥る最大の罠が、「サーバーサイドでの検証の甘さ」だ。

GET /search?q= HTTP/1.1
Host: secure-bank.example.com

サーバーは q パラメータをそのままHTMLの


検索結果: [q]

に埋め込む。ここでブラウザは、レスポンスの Content-Type: text/html を見て、そのスクリプトを「信頼されたコンテンツの一部」としてパースする。ブラウザは「誰がそのスクリプトを生成したか」ではなく「どのドメインのレスポンスに含まれているか」で実行可否を判断するという仕様の盲点を突いているのだ。

2. 「入力値検証」という幻想：ホワイトリストの再定義

多くの現場では、ブラックリスト形式のサニタイズ（