XSSの「検知」という幻影：WAFとSIEMを繋ぐ泥臭いリアリズム
多くのセキュリティエンジニアが勘違いしていることがある。WAF（Web Application Firewall）を導入し、「XSS防御を有効にしました」と報告書に書いた瞬間、彼らは安心感という名の麻薬に浸かる。しかし、現場の最前線にいる諸君なら知っているはずだ。シグネチャベースのWAFは、攻撃者がペイロードを少し難読化するだけで、いとも簡単に骨抜きにされることを。
XSS（クロスサイトスクリプティング）は、もはや古典的な「alert(1)」の時代ではない。今日の攻撃者は、JavaScriptの非同期処理やDOM操作の深淵を突き、HTTPレスポンスのヘッダー解析の隙間を縫ってセッションを奪取する。この記事では、WAFの検知ログを単なる「アラートの山」から「インテリジェントな脅威インテリジェンス」へと昇華させるための、SIEM連携の真髄を語ろう。
—
1. ログの「質」がインシデントハンドリングの生死を分ける
WAFが出力するログが、ただの「403 Forbidden」の羅列であるなら、それはゴミと同じだ。攻撃者がどのプロパティを狙っているのか、どの入力ベクトル（GETパラメータか、JSONボディか、あるいはHTTP HeaderのUser-Agentか）を悪用しているのか。ここを解像度高く記録しなければ、事後分析は不可能だ。
推奨されるログフォーマット（JSON形式）
SIEM側で相関分析を行うためには、正規化されたログが必須だ。以下のような構造をWAFからエクスポートせよ。
{
“timestamp”: “2023-10-27T10:00:00Z”,
“source_ip”: “192.168.1.100”,
“attack_vector”: “POST_BODY_JSON”,
“rule_id”: “XSS-941100”, // OWASP ModSecurity Core Rule Set ID
“payload_snippet”: “eval(atob(‘Z2V0Q29va2llKCk=’))”, // 難読化されたペイロードを抽出
“target_uri”: “/api/v1/user/profile”,
“http_headers”: {
“X-Forwarded-For”: “…”,
“Referer”: “https://attacker.com/”
},
“anomaly_score”: 5 // SIEM側で閾値判定を行うためのスコア
}
—
2. SIEMでの相関分析：ノイズの海から真の攻撃を抽出する
WAFのログをSIEM（Splunk, Sentinel, ELK等）に流し込んだ後、諸君がすべきは「ルールのチューニング」ではない。「行動分析」だ。
攻撃者プロファイリングのロジック
単発のXSS試行は、脆弱性スキャナの誤検知である可能性が高い。真に警戒すべきは、「偵察（Reconnaissance）」と「エクスプロイト（Exploitation）」の連結だ。
- 相関ロジック例（Splunk SPL）:
index=waf_logs rule_id=”XSS-”
| stats count by source_ip, target_uri
| join type=left source_ip [
search index=app_logs status=200
| stats count as success_count by source_ip
]
| where count > 10 AND success_count > 0
| eval risk_level=”CRITICAL”
| table source_ip, risk_level, target_uri
/
解説: 特定のIPからXSSシグネチャが10回以上検知され、
かつ同一IPが正常レスポンスを受け取っている場合、
攻撃が成功したか、脆弱性調査が完了した可能性が高い。
/
—
3. 次世代の防衛：プロンプトインジェクションとXSSの交差点
最近、生成AIを利用したアプリケーションにおいて、LLMのプロンプトインジェクションがXSSのベクトルとして悪用されるケースが急増している。LLMが生成した出力結果（HTMLやJS）が、サニタイズなしでブラウザへ描画される際、そこには「格納型XSS」の脆弱性が生まれる。
この領域では、従来のWAFシグネチャは通用しない。ガードレイル（Guardrails）のアーキテクチャを構築する必要がある。
1. Content Security Policy (CSP) の厳格化: script-src 'self' をベースにし、nonce（使い捨てトークン）を生成AIのレスポンスに動的に付与する。
2. 出力サニタイズの二重化: アプリケーション層でDOMをレンダリングする直前に、DOMPurify 等のライブラリを用いて、AIの生成物を強制的に無害化する。
3. SIEMでの異常検知: AIからの生成物に含まれるトークン数や、特異なエスケープシーケンスをSIEMで監視し、プロンプトインジェクションの兆候を捉える。
—
結びに代えて：セキュリティは「完了」しない
諸君がアーキテクトとして目指すべきは、完璧な防御ではない。「攻撃の成功を即座に検知し、被害を最小化するレジリエンス」だ。
WAFとSIEMを連携させることは、現代のサイバー戦におけるレーダーと管制塔を構築することに等しい。ログを眺めるだけで満足してはならない。そのログの向こう側にいる、キーボードを叩く「人間」の意図を読み解け。攻撃者が次にどのパケットを飛ばしてくるか、その予測こそが、我々ホワイトハッカーが持つ最大の武器だ。
技術は常に進化する。だが、攻撃者の心理と脆弱性の本質は、驚くほど変わらない。泥臭く、しかし冷徹に、システムを守り抜こう。諸君の健闘を祈る。
コメント