XSSの「教科書」を捨てろ：現場が教えるブラウザ検知回避と、防御の鉄則
「XSS対策？ htmlspecialchars を使えばいいんでしょ？」
もし君がそう思っているなら、明日の朝には君のシステムが踏み台にされているかもしれない。
セキュリティ診断の現場に立つとよく分かるが、攻撃者は「教科書通りのXSS」なんて狙っていない。彼らが狙うのは、開発者が「安全だと思い込んでいる盲点」だ。今日は、ブラウザのセキュリティ機構をいなすペイロードの考え方と、それを根底から無力化する実装の勘所を叩き込む。
—
1. 攻撃者が「ブラウザの検知機能」をどう欺くか
かつてChromeに搭載されていたXSS Auditorや、現在のブラウザが持つ反射型XSS防御は、ある意味「パターンマッチングの塊」だ。攻撃者は、リクエストに含まれる文字列がレスポンスにそのまま現れるパターンを嗅ぎつけてブロックする。
攻撃者が行う「回避」の基本は、ブラウザのパーサーに「これはコードではない」と錯覚させることだ。
代表的な回避手法のPoC（診断用）
例えば、単純な は即座に弾かれるが、以下のようなペイロードは、文脈（コンテキスト）次第でブラウザのフィルタをすり抜けることがある。
- DOMベースを狙うペイロード例
atob（Base64デコード）を使うことで、検知ロジックが「alert」という危険な文字列を直接特定できないようにする手法だ。
- HTML属性を悪用する例
2. なぜ「エスケープ」だけでは足りないのか
多くのエンジニアが陥る罠は、「出力時のサニタイズ」のみに頼ることだ。だが、今のWebアプリは複雑だ。JavaScriptで動的にDOMを生成し、JSONをパースし、SPAで画面遷移する。
「どこで入力され、どこで実行されるか」というコンテキストを意識しなければ、いくらエスケープしても脆弱性は残る。
—
3. 実践：コピペで動く「堅牢な実装」の正解
防御の基本は「多層防御」だ。PHPでの出力制御と、HTTPヘッダーによるブラウザの制御、この2軸を組み合わせる。
PHPによるセキュアな出力処理（基本）
単純なエスケープではなく、コンテキストに合わせたエンコードを行う。
/
function h($str) {
// ENT_QUOTES: シングルクォートとダブルクォートの両方を変換
// UTF-8: 文字化けによる回避を防止
return htmlspecialchars($str, ENT_QUOTES | ENT_HTML5, ‘UTF-8’);
}
// テンプレート側での使用例
// 攻撃者が入力した
コメント