CSP違反レポート：ただのログと侮るなかれ、それは「攻撃者の足跡」そのものだ
多くの現場で、Content Security Policy (CSP) は「面倒な制約」として扱われている。開発の最終段階でとりあえず導入し、コンソールに吐き出されるエラーを消すために unsafe-inline を付与して骨抜きにする。そんな光景を何度見てきたことか。
だが、真のセキュリティアーキテクトにとって、CSPは単なるホワイトリストではない。それは「ブラウザというフロントラインに配置した、最も強力な侵入検知センサー」だ。今回は、report-uri および report-to を駆使し、攻撃の予兆をリアルタイムに炙り出すための「泥臭い」運用論を語る。
—
1. なぜ「静的な防御」だけでは不十分なのか
SQLインジェクションやクロスサイトスクリプティング（XSS）の脆弱性は、アプリケーションコードのメモリレイヤでの不整合や、パースロジックの甘さから生まれる。しかし、最新の攻撃者は、単にスクリプトを埋め込むだけではない。彼らは、AIを用いたプロンプトインジェクションでガードレイルを回避し、難読化されたペイロードを動的に生成する。
こうした攻撃に対し、サーバー側のWAFだけでは限界がある。なぜなら、攻撃が「ブラウザのコンテキスト」で実行された瞬間に、その挙動はサーバーから見えなくなるからだ。ここでCSPの違反レポートが効力を発揮する。ブラウザ側で発生した「予期せぬスクリプト実行試行」は、攻撃者がペイロードを試行錯誤しているまさにその瞬間の生データとなる。
2. report-uri から Reporting API (report-to) への過渡期
現在、report-uri は非推奨（Deprecated）の方向にある。今後は Report-To ヘッダーによる Reporting API への移行が必須だ。
実装サンプル：ヘッダー設計の勘所
サーバーサイドで送出するヘッダーは、単に「エラーを飛ばす」のではなく、分析パイプラインへの入り口として設計する。
CSPヘッダーの例
Content-Security-Policy: default-src ‘self’;
script-src ‘self’ https://trusted.cdn.com;
report-to csp-endpoint;
Reporting APIの定義
Report-To: {
“group”: “csp-endpoint”,
“max_age”: 10886400,
“endpoints”: [
{ “url”: “https://security-monitor.example.com/report” }
]
}
ここで重要なのは、max_age の設定と、バックエンドの受け口（エンドポイント）の堅牢性だ。レポート自体を標的とした「レポート爆撃（DoS攻撃）」を避けるため、エンドポイントでは受信したJSONのパース処理において、メモリリークや無制限の再帰呼び出しを防止するガードレイルを設けておく必要がある。
3. レポートから「攻撃の文脈」を抽出する監査ロジック
届いたレポートを「とりあえずDBに突っ込む」のは素人のやることだ。プロは、以下の3つのメタデータに注目する。
blocked-uri: 攻撃者がどのドメインから悪意あるスクリプトを読み込もうとしているか。これが未知のドメインであれば、サプライチェーン攻撃の兆候だ。violated-directive: どの制限を突破しようとしているか。script-srcへの執拗な攻撃は、データ持ち出し（Exfiltration）を狙ったXSSの予兆である可能性が高い。document-uri: どのページが踏み台にされているか。特定の動的ページに集中しているなら、そのページのテンプレートエンジンやサニタイザの脆弱性を即座に疑うべきだ。
現場で使う解析ロジック（擬似コード）
// 受信したレポートの簡易解析スクリプト
function analyzeReport(report) {
const { ‘blocked-uri’: blockedUri, ‘violated-directive’: directive } = report;
// 既知の信頼済みCDN以外からのスクリプト実行試行は、優先度を”Critical”にする
if (directive === ‘script-src’ && !isTrustedDomain(blockedUri)) {
triggerAlert(“潜在的インジェクション試行を検知”, {
source: blockedUri,
severity: “HIGH”,
context: “DOM_EXFILTRATION_RISK”
});
}
}
4. チーフホワイトハッカーとしての提言：未来へ向けて
耐量子暗号（PQC）への移行が議論される中、我々は通信の機密性だけでなく「エンドポイントの整合性」をより強く担保せねばならない。CSPは、ブラウザとサーバー間の信頼の鎖を維持するための、最も基本的かつ強力なツールだ。
もし貴方の組織が、まだCSP違反レポートを「ゴミ箱」へ捨てているのなら、それは侵入者に対する「侵入してください」という招待状を配っているのと同じだ。
今すぐやるべきこと：
1. report-to を導入し、まずは Content-Security-Policy-Report-Only モードで運用を開始する。
2. 発生する違反のうち、99%は設定ミスだ。それを一つずつ潰し、残った1%の「ノイズに見える攻撃の予兆」を特定せよ。
3. レポート解析基盤をSIEM（SplunkやElastic Stackなど）に統合し、相関分析を行え。
セキュリティとは、完璧な防御を築くことではない。「何が起きているのかを、誰よりも早く、正確に理解すること」に尽きる。CSPのレポートは、そのための最も饒舌な証人なのだ。
コメント