現場のエンジニアへ：反射型XSSを「過去の遺物」にするための実戦的防衛論
「XSSなんて今さら？」と思うかもしれない。だが、現場でインシデント対応をしていると、驚くほど古典的な反射型XSSでCookieを奪われ、セッションハイジャックに至るケースが後を絶たない。なぜ防げないのか？ それは「サニタイズ」を「魔法の呪文」だと勘違いし、文脈を理解せずに実装しているからだ。
今日は、教科書には載っていない「攻撃者が狙う盲点」と、明日から現場で使える防御策を叩き込む。
—
1. 反射型XSSの「真の脅威」を理解する
反射型XSSは、サーバー側にデータが保存されない。だからこそ、「ログに残りにくく、気づきにくい」という攻撃者にとって都合の良い特性がある。
攻撃シーケンスのリアル
攻撃者は、?search= のようなURLを生成し、フィッシングメールやSNSで標的に踏ませる。
1. 誘引: 攻撃者が細工したリンクを送信。
2. 反射: サーバーが入力値をそのままHTMLレスポンスに書き出す。
3. 実行: ユーザーのブラウザ上で、悪意あるスクリプトが「サイトの一部」として実行される。
ここで重要なのは、「ブラウザから見れば、そのスクリプトは信頼できるドメイン（君たちの開発したアプリ）から送られてきたもの」と判断される点だ。これが、Same-Origin Policyをすり抜ける最大の理由だ。
—
2. 対策の鉄則：サニタイズとエスケープは「出力時」が絶対
「入力時にサニタイズすればいい」というアドバイスは半分間違いだ。データは保存先によって適切なエンコーディングが変わる。表示する直前に、そのHTMLコンテキストに合わせてエスケープするのが、セキュリティの鉄則だ。
JavaScriptでの安全な実装例（DOM操作）
innerHTML は絶対に使うな。あれは「HTMLとして解釈してくれ」という攻撃者への招待状だ。
// 【NG】 innerHTMLはXSSの温床
// document.getElementById(‘result’).innerHTML = userInput;
// 【OK】 textContentを使えば、ブラウザは確実に「ただの文字列」として処理する
const userInput = new URLSearchParams(window.location.search).get(‘q’);
const resultElement = document.getElementById(‘result’);
if (userInput) {
// ブラウザが自動的にコンテキストを識別し、無害化してくれる
resultElement.textContent = userInput;
}
PHPでの安全な出力例
PHPなら、htmlspecialchars() をコンテキスト（ENT_QUOTES）を指定して使う。
—
3. 防御の「多層化」：WAFとCSPによる最後の砦
コードが完璧でも、ヒューマンエラーは起きる。そのために、インフラ層での防御を固めておくのがプロの仕事だ。
Content Security Policy (CSP) の設定
CSPは、万が一XSSが発動しても「外部への通信」や「インラインスクリプトの実行」をブロックする強力な盾だ。Nginxの設定ファイルに以下のように追記する。
Nginx設定例: CSPヘッダーの追加
信頼できるドメイン以外からのスクリプト実行を禁止する
add_header Content-Security-Policy “default-src ‘self’; script-src ‘self’; object-src ‘none’;”;
default-src 'self'：自分のドメイン以外からのコンテンツ読み込みを原則禁止。script-src 'self'：インラインスクリプト（）の実行を完全にブロック。これで反射型XSSの大部分は無効化される。
WAFの活用
AWS WAFなどを導入しているなら、Generic SQL InjectionやXSSのルールセットを有効にするのは当然として、「過剰な入力制限」を恐れるな。 URLパラメータに不自然な記号（<, >, ', "）が含まれる場合、ビジネスロジックに影響がないならWAFでブロックする設定を検討すべきだ。
---
最後に：セキュリティは「実装」の先にある
技術的な対策を並べたが、結局のところ最も脆弱なのは「開発者の慢心」だ。「ここは大丈夫だろう」という油断が、数百万件の個人情報流出を招く。
- ライブラリを信頼するな: フレームワーク（ReactやVueなど）は自動エスケープ機能を持っているが、
dangerouslySetInnerHTMLのような「危険な穴」も用意されている。 - 動的生成を疑え: URLパラメータを直接HTMLに反映させる設計自体が、現代のWeb開発では「設計負債」になり得る。
もし君がチームのリーダーなら、コードレビューで「この出力、本当にエスケープしているか？」と聞く前に、「なぜこのデータをHTMLに直接埋め込む必要があるのか？」と問いかけてほしい。
セキュリティは足し算ではなく掛け算だ。コード、インフラ、そしてエンジニアの意識。そのどれか一つがゼロになれば、システム全体の安全性はゼロになる。今日から、その意識でコードを書いてくれ。それがプロとしての最低ラインだ。
コメント