なぜ今さら「反射型XSS」を語るのか？――その脆弱性は、君の書いた一行から生まれる
「XSS（クロスサイトスクリプティング）？ 今どきフレームワークが自動でエスケープしてくれるでしょ？」
インシデントレスポンスの現場で、若いエンジニアからこんな言葉を聞くと少し背筋が寒くなる。確かにReactやVue、あるいは現代のPHPテンプレートエンジンは賢い。だが、「便利さは盲目を作る」というセキュリティの鉄則を忘れてはいけない。
反射型XSSは、攻撃の入り口が「URLそのもの」にあるという点で、極めて悪質だ。今回は、ただの教科書的な解説ではなく、攻撃者が何を狙い、どう防ぐべきか、現場の視点で切り込む。
—
1. 攻撃者が「URLパラメータ」を執拗に狙う理由
反射型XSSのメカニズムはシンプルだ。
1. 攻撃者が悪意あるスクリプトを仕込んだURLを作成する。
2. そのURLをSNSやメールで標的に踏ませる。
3. サーバーがパラメータを未検証のままレスポンスに書き戻す。
4. 被害者のブラウザでスクリプトが実行される。
攻撃者が狙うのは、ただ画面を改ざんすることではない。「セッションハイジャック（Cookieの奪取）」だ。document.cookieにアクセスできれば、そのユーザーになりすまして機密情報を操作できる。
攻撃のPoC（概念実証）
例えば、検索結果を表示するだけの無邪気なPHPコードがあったとしよう。
// 脆弱な例: 検索キーワードをそのまま画面に表示している
$keyword = $_GET[‘q’];
echo “
「” . $keyword . “」の検索結果
“;
攻撃者が送るURLはこれだ。
https://example.com/search.php?q=
ブラウザはこれをHTMLとして解釈し、即座に実行する。サーバー側には何のログも残らず、被害者のCookieが攻撃者のサーバーへ送信される。これが反射型XSSの恐ろしさだ。
—
2. 「防御の鉄則」はたった一つ：出力時にエンコードせよ
対策の本質は「データを信頼しないこと」に尽きる。入力値のバリデーションは重要だが、出力する文脈（HTML、JavaScript、CSSなど）によってエスケープすべき文字は変わる。だからこそ、出力の直前でエスケープするのが現場の鉄則だ。
実装サンプル：PHPでのセキュアな出力
PHPで書くなら、htmlspecialcharsを正しく使う。これだけで、< や > などの文字は実体参照（< 等）に変換され、ブラウザはスクリプトとして解釈できなくなる。
「" . $safe_keyword . "」の検索結果
";
?>
実装サンプル：JavaScript（React/Vue）の恩恵
モダンなフレームワーク（Reactなど）を使っている場合、データバインディング機能が自動的にこのエスケープを行ってくれる。しかし、dangerouslySetInnerHTML（React）や v-html（Vue）を不用意に使うと、その瞬間にセキュリティホールが開く。「あえて生のHTMLを注入する」という選択は、特権階級のエンジニアだけが許可された禁じ手だと思ってほしい。
---
3. 多層防御としてのCSP（Content Security Policy）
コードレベルの対策に加え、ブラウザ側でスクリプトの実行を制限する「CSP」は、現代のWeb開発において必須の防具だ。たとえエスケープ漏れがあっても、被害を最小限に抑えることができる。
Nginxの設定ファイルに以下の一行を追加するだけで、インラインスクリプト（）の実行を禁止できる。
Nginx設定ファイルに追加
'unsafe-inline'を許可しないことで、XSSによるスクリプト実行を大幅に制限する
add_header Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none';";
- default-src 'self': コンテンツは自ドメインからのみ読み込む。
- script-src 'self': 外部ドメインからのスクリプト読み込みを禁止し、インラインスクリプトも実行させない。
---
4. 最後に：セキュリティは「仕様」の一部だ
「忙しいから後で直そう」という判断が、数ヶ月後の大規模インシデントを生む。セキュリティ対策は、機能要件と同じ「仕様」だ。
1. 出力の文脈を理解する: HTMLに埋め込むなら htmlspecialchars、JavaScriptの変数に入れるなら別のエスケープが必要になる。
2. CSPを設定する: 開発の初期段階からHTTPレスポンスヘッダにCSPを仕込んでおく。
3. WAFを過信しない: WAFは盾だが、剣（コード）が錆びていては意味がない。
君たちが書くコードは、ユーザーの資産と信頼を守るための防壁そのものだ。今日紹介したエスケープ処理とCSPの設定は、明日からすぐに反映できる。「動けばいい」という考えを捨て、「守れるコード」を書くエンジニアになってほしい。
現場からは以上だ。また何かあればいつでも相談してくれ。
コメント