XSSの「自動化」と「泥臭い手動検証」の境界線：現場のセキュリティチーフが教える実戦的防御術
やあ、現場の最前線でコードと格闘しているエンジニア諸君。
XSS（クロスサイトスクリプティング）と聞いて、「今さら何を」と思ったなら少し注意が必要だ。確かにモダンなフレームワーク（ReactやVue.jsなど）はデフォルトでエスケープを噛ませてくれる。だが、レガシーな管理画面、動的なJS生成、あるいは「ちょっとした便利機能」のために書いた数行のコードが、いとも簡単に攻撃者の踏み台にされる現場を、私は数え切れないほど見てきた。
今日は、自動化ツールに頼り切りになって「穴」を空けないための、プロフェッショナルなXSS診断と防御の極意を伝授しよう。
—
1. DASTと手動検証の「役割分担」を見誤るな
多くのエンジニアは、DAST（動的アプリケーションセキュリティテスト）ツールを走らせれば「診断完了」だと思っている。だが、それは大きな間違いだ。
- DAST（Burp Suite Pro, OWASP ZAP等）の役割:
網羅的な「取りこぼし防止」。パラメータのファジング、隠れたパスの探索、盲目的な反射型の発見には最強だ。しかし、これらは「コンテキスト」を理解しない。
- 手動検証の役割:
「ロジックの隙間」を見つけること。例えば、JSONデータがページ内のJS変数に埋め込まれる箇所や、DOM型のXSSは、ツールが検知し損ねることが多い。
教訓： 自動化で8割を潰し、残りの2割を泥臭い手動検証で「刺す」。これが、インシデントを防ぐプロの作法だ。
—
2. 実践：危険なコンテキストを特定し、無力化する
XSSの真の脅威は、入力値が「どこで」「どう解釈されるか」というコンテキストにある。
ケースA：HTMLタグの内側に挿入されるケース（反射型）
一番ありがちなパターンだが、甘く見ると痛い目を見る。
脆弱なコード (PHP):
防御の鉄則： 常に適切なエスケープ（htmlspecialchars）を行う。
—
ケースB：JavaScript変数に埋め込まれるケース（DOM型・複雑な反射型）
ここがツールの盲点になりやすい。「"をエスケープすれば大丈夫」と思っているなら危険だ。攻撃者は '; alert(1); // のように、変数のスコープを脱出してコードを実行する。
防御の鉄則： JavaScriptへの埋め込みは避け、データ属性を利用せよ。
—
3. インフラレイヤーでの「最後の砦」：CSP（Content Security Policy）
コードレベルでの修正が追いつかないレガシーシステムや、万が一の脆弱性混入に備え、CSPを導入するのは現代の常識だ。これを設定しないのは、玄関に鍵をかけずに家を出るようなものだ。
NginxでのCSPヘッダー設定例:
全てのインラインスクリプトを禁止し、信頼されたドメインのみ許可
add_header Content-Security-Policy “default-src ‘self’; script-src ‘self’ https://trusted.cdn.com; object-src ‘none’;”;
default-src 'self': 基本的に同一ドメインのみを許可。script-src 'self' ...: インラインスクリプト（）を一切許さない。これにより、たとえXSS脆弱性があっても攻撃コードは実行されない。
—
4. 現場のチーフからのアドバイス
診断を行う際、Burp Suiteの「Repeater」や「Intruder」を使って、以下の入力を試してみてほしい。
1. :
コメント