XSSは「終わった脆弱性」ではない。WAFの裏をかく攻撃者と戦うための実践的防衛論
「XSS対策? htmlspecialchars() を通せば終わりでしょ?」
もし君が現場でそう言っているなら、一度立ち止まってほしい。僕がこれまで見てきた数々のインシデントにおいて、攻撃者は教科書通りのXSSを仕掛けてはこない。彼らは、開発者が「まさかここは安全だろう」と油断している、あるいはWAFの正規表現が検知できない「盲点」を突いてくる。
今日は、WAFのシグネチャをすり抜ける巧妙なペイロードの正体と、SIEMで異常を炙り出すための「泥臭いログ分析」の現場話をしよう。
—
1. 攻撃者が狙う「盲点」:WAFのシグネチャをバイパスする技術
WAF(Web Application Firewall)は万能ではない。一般的なWAFは「」や「alert()」といった既知のキーワードをブラックリスト形式で弾く。しかし、攻撃者はエンコーディングやDOMの特性を悪用し、このガードを無力化する。
WAFを突破する攻撃ペイロードの例
例えば、以下のようなペイロードは、単純なフィルタリングを容易に潜り抜ける。
- URLエンコードの二重化:
%253cscript%253e(WAFが一度しかデコードしない場合、後段のアプリで実行される) - 非推奨タグの活用:
や
(scriptタグを含まないため、多くの初歩的な検知ルールを回避する) - JavaScriptプロトコル経由:
Click(属性値内の注入は、静的なHTML解析だけでは見落とされやすい)
これらを防ぐには、単なる「NGワード登録」ではなく、文脈に応じた出力エスケープ(Context-Aware Encoding)が必須だ。
---
2. セキュアな実装:コピペで動く防御の鉄則
「何を表示するか」ではなく、「どこに表示するか」によってエスケープ手法は変わる。
PHPでの安全な出力サンプル
PHPでHTML内に変数を埋め込む際は、必ず ENT_QUOTES | ENT_HTML5 を指定すること。これがないと、シングルクォートによる属性値の脱獄を許す。
こんにちは、" . h($user_name) . "さん
コメント