XSS防御の終着点：CSP strict-dynamic がもたらす「信頼の連鎖」と現実的な妥協
「XSS対策？ CSPを入れておけば安泰だろう」
もしあなたが今、そう考えているなら、それは危険な慢心だ。ホワイトハッカーの視点から言わせれば、CSP（Content Security Policy）の初期仕様は、現実の複雑なWebアプリケーションの運用に全く適していなかった。ホワイトリスト形式のドメイン制限は、開発者が「とりあえず unsafe-inline を許可する」という敗北宣言をせざるを得ない状況を生み出し、結果としてXSS攻撃の入り口を広く開放してきた。
今回は、現代のフロントエンド開発において「現実的な解」となる strict-dynamic に焦点を当て、攻撃者が好む「信頼の盲点」をどう塞ぐかを解説する。
—
1. なぜ従来のCSPは「死に体」だったのか
従来のCSP（Level 2まで）では、スクリプトの実行を制御するためにドメイン（script-src 'self' https://trusted.cdn.com など）をホワイトリスト化していた。しかし、この手法には致命的な欠陥がある。
1. CDNの脆弱性: 広く使われているCDN（例: AngularJSがホストされていた古いサーバー）が攻撃者に乗っ取られれば、そこを起点に悪意のあるスクリプトを注入できる。
2. インラインスクリプトの誘惑: 現代のSPA（Single Page Application）は、動的にDOMを操作し、スクリプトを生成する。この挙動を制限するとアプリが壊れるため、結局 'unsafe-inline' を許可し、CSPの防御壁を自ら取り壊す羽目になる。
ここで登場するのが、CSP Level 3の strict-dynamic である。これは「信頼されたスクリプトが読み込んだ外部スクリプトも、同様に信頼する」という、信頼の連鎖（Trust Chain）を導入する革命的な仕組みだ。
—
2. strict-dynamic の本質：信頼の委譲
strict-dynamic を使用すると、ブラウザは「ホワイトリストにあるドメイン」よりも「暗号論的な証明」を優先する。
具体的には、サーバーが生成したランダムな nonce（ナンバー・オンス）を、信頼できるスクリプトタグに付与する。そのタグが実行された瞬間、そのスクリプトが動的に生成・実行する他のスクリプト（子スクリプト）は、自動的に許可される。
実装例：セキュアなCSPヘッダー
nonceはリクエストごとに生成し、決して使い回さないこと。
攻撃者が推測不可能な高エントロピーの値を生成するのが鉄則だ。
Content-Security-Policy: script-src ‘nonce-R4nd0mB4s64Str1ng’ ‘strict-dynamic’; object-src ‘none’; base-uri ‘none’;
この設定の肝は、'unsafe-inline' を無効化できる点にある。もし攻撃者が外部からスクリプトを注入しようとしても、nonce を知らなければスクリプトタグはブロックされる。そして、あなたのアプリケーションが正当に生成したスクリプトのみが、その後の連鎖を許される。
—
3. 後方互換性と「壊さない」ための現実解
「古いブラウザやレガシーな環境はどうする？」という問いは、現場のエンジニアにとって最も頭の痛い問題だ。strict-dynamic をサポートしていない古いブラウザは、このキーワードを無視し、ホワイトリストのドメイン制限にフォールバックする。
ここで、防御レベルを維持しつつ互換性を保つための「賢い書き方」を紹介する。
現代的なブラウザは strict-dynamic を解釈し、古いブラウザはドメイン制限で防御する
Content-Security-Policy: script-src ‘nonce-R4nd0mB4s64Str1ng’ ‘strict-dynamic’ ‘unsafe-inline’ https: http:;
'unsafe-inline'を残す理由: 古いブラウザ向けに、あえてフォールバックとして設定する。- 注意点: モダンブラウザは
'strict-dynamic'が存在する場合、'unsafe-inline'やドメイン指定を「無効」とみなす仕様になっている。つまり、モダンブラウザでは厳格に保護され、古いブラウザでは従来のホワイトリストベースの保護が適用されるという二段構えが実現できる。
—
4. アーキテクトとして見据える「次の戦場」
strict-dynamic はXSSに対する強力な防波堤だが、これが万能ではないことも理解しておく必要がある。
- プロンプトインジェクションとの連動: 現在、生成AIの回答をそのままDOMにレンダリングするアプリケーションが増えている。XSS対策が万全でも、AIが生成した「悪意のあるHTML構造」が、アプリ側のロジックをバイパスして意図しないJavaScriptを実行するケースがある。
- 防御の階層化: CSPはあくまで「実行を止める」最終防衛ラインだ。入力値のサニタイズ（DOMPurify等の活用）と、出力時のエスケープ、そしてCSPという多層防御（Defense in Depth）を貫徹せよ。
我々セキュリティアーキテクトに求められるのは、完璧なシステムを作ることではなく、「攻撃者がコストを支払わなければ侵入できない環境」を維持し続けることである。
strict-dynamic を導入することは、単なる設定変更ではない。それは、アプリケーションのライフサイクル全体における「信頼の定義」を再構築する作業だ。今夜、あなたのプロダクション環境のCSPヘッダーを確認してほしい。そこに 'unsafe-inline' という甘美で危険な文字列が踊っていないだろうか？ もしそうなら、今すぐリファクタリングの計画を立てるべきだ。
技術は常に進化する。だが、脆弱性を突こうとする攻撃者の論理は、いつだってシンプルだ。「信じすぎた場所」を狙う。その隙を、我々が埋めるのだ。
コメント