CSPの「防波堤」を突破する攻撃者の心理と、nonce/hashによる完全防御への道筋
インジェクション攻撃の歴史は、そのままWebセキュリティの進化の歴史だ。SQLiが全盛を極めた時代から、今日のようにフロントエンドの複雑性が増した時代まで、攻撃者は常に「信頼された境界」の隙間を突いてきた。
多くのエンジニアがContent-Security-Policy (CSP)を単なる「ブラウザの警告回避リスト」だと誤解しているが、それは大きな過ちだ。CSPは、現代のフロントエンドにおける最後の防衛線であり、適切に実装すればXSS（クロスサイトスクリプティング）を設計段階で無効化できる。しかし、'unsafe-inline'を安易に許可するような「緩い」設定は、攻撃者から見れば「どうぞ、ここから侵入してください」という招待状に等しい。
なぜ script-src 'unsafe-inline' が地獄への入り口なのか
攻撃者は、インジェクションの脆弱性を突く際、ターゲットのメモリ空間やDOMツリーを自らのコードで汚染する。もしサーバーのCSP設定が 'unsafe-inline' を許可していれば、彼らは悪意のある
ここで重要なのは、'strict-dynamic' を組み合わせることだ。これにより、nonceが付与された信頼済みスクリプトが、外部からライブラリ（CDN上のSDKなど）を動的にロードする際も、自動的に許可される。現代のフロントエンド開発において、これなしでの運用は現実的ではない。
2. インラインスクリプトを排除できない場合のハッシュ運用
特定のコードを頻繁に利用する場合、毎回nonceを生成するのが負荷になるケースもある。その場合は、スクリプトの内容をSHA-256などでハッシュ化し、ポリシーに埋め込む手法が有効だ。
CSPヘッダーの例
Content-Security-Policy: script-src 'sha256-n6t3qgM1qG0J/4v3Kj7+q5v4g2q9B4u1O5r8O6c1w2Y='
攻撃者がスクリプトを1バイトでも書き換えればハッシュ値は一致せず、ブラウザは即座に実行をブロックする。これは、静的なインラインスクリプトに対する最強の「改ざん検知機能」として機能する。
生成AI時代に求められる「ガードレイル」としてのCSP
最近の脅威トレンドとして、生成AIが生成したコードをそのままアプリケーションに埋め込むケースが増えている。しかし、そのコードに「プロンプトインジェクション」の結果として混入した悪意あるペイロードが含まれていた場合、どうなるか。
ここでCSPが真価を発揮する。コードがAIによって生成されようが、人間が書こうが、「実行権限のホワイトリスト」という物理的なルールさえ守られていれば、インジェクションは失敗する。
私たちが意識すべき「防御のアーキテクチャ」
1. レポート機能の活用: report-to または report-uri を必ず設定せよ。CSP違反は、攻撃の試行そのものを検知できる最良のログソースだ。
2. 依存関係のサンドボックス化: strict-dynamic を使用する際は、信頼できるCDNやスクリプトソースを明確に分離すること。
3. 耐量子暗号への視座: 将来的に、ハッシュアルゴリズム（SHA-256等）が量子コンピュータによって衝突攻撃を受ける可能性も考慮に入れ、アルゴリズムの更新が容易なポリシー管理体制を構築しておくべきだ。
結び：セキュリティは「設定」ではなく「規律」
CSPの実装は、単なるWebのチューニングではない。開発プロセス全体に「信頼できないコードを一切実行させない」という強い規律を浸透させるためのツールだ。
もしあなたがテックリードであるなら、チームに対して「CSPでエラーが出ているから緩める」という選択肢を奪ってほしい。エラーが出るということは、そこに「制御不能なコード」が存在しているという警鐘に他ならない。そのコードを特定し、リファクタリングし、安全な設計へと昇華させる。そのプロセスこそが、インジェクション攻撃を根本から無効化する唯一の道である。
攻撃者は今日も、あなたのサーバーのわずかな隙間を探している。だが、強固なCSPという城壁を築き上げた者には、その攻撃手法さえもただの「ノイズ」に過ぎないのだ。
コメント