反射型 XSS.

反射型 XSS(非永続型、Type-1)は、Web アプリケーションが HTTP リクエスト中のデータ(多くは URL クエリ文字列やフォーム入力)を取り出し、適切な出力エンコードを行わずレスポンスに含めてしまった場合に発生します。攻撃には被害者が細工されたリンクをクリックする必要があるため、フィッシング、悪性広告、チャットメッセージなどを介して配布されるのが一般的です。成功するとセッション Cookie の窃取、ユーザに代わった操作、最終的な完全なアカウント乗っ取りへと発展する可能性があります。対策には文脈別の HTML エンコード、厳格な Content Security Policy、テンプレートを自動エスケープするフレームワークの活用が含まれます。

反射型 XSS 攻撃の流れ

flowchart LR
  A[攻撃者がパラメータにスクリプトを仕込んだリンクを作成] --> B[フィッシング / 広告 / チャットで配布]
  B --> C[被害者がリンクをクリック]
  C --> D[アプリが入力をエンコードせず反映]
  D --> E[ブラウザがセッション内でスクリプトを実行]
  E --> F[Cookie 窃取 / ユーザとしての操作 / アカウント乗っ取り]

なぜペイロードは文脈に応じてエンコードすべきか

XSS の本質的な難しさは「エンコード」が文脈依存である点にあります。同じ値でも、ある出力先では安全で別の出力先では危険です。HTML テキスト内に置くデータには HTML エンティティエンコード、属性内には属性エンコードと引用符、<script> ブロックやイベントハンドラ内には JavaScript 文字列エンコード、URL 内には URL エンコードが必要です。盲目的に 1 種類のエンコードだけを施すと、同じパラメータが複数の文脈に反映されるケースを取りこぼします。既定で自動エスケープするテンプレートエンジン(React の JSX、Angular、文脈別エスケープを備えたサーバサイドテンプレート)は、dangerouslySetInnerHTML や innerHTML といった抜け穴を避けさえすれば、反射型 XSS の大半を排除できます。

ブラウザ側フィルタはもはや防御になりません。Google は Chrome 78(2019 年 10 月)で XSS Auditor を完全に削除しました。容易にバイパスでき、誤検知が多く、正規スクリプトを選択的に無効化する攻撃に悪用され得たためです。これが参照していた X-XSS-Protection ヘッダも事実上無効化されています。恒久的に有効な対策は、文脈別の出力エンコード、厳格な Content Security Policy(できれば nonce または hash ベース)、盗まれたスクリプトがセッションを読めないようにする HttpOnly Cookie、そして主たる防壁ではなく多層防御としての入力バリデーションです。