CSPヘッダー導入で実現するWebサイトの多層防御：今すぐ試せる設定例と運用知見

2025/07/24 開催の NIKKEI TECH TALK #35 で発表したスライドです。 #nikkei_tech_talk
https://nikkei.connpass.com/event/357482/

Transcript

1. 2025/7/24 日本経済新聞社　CDIO室 飯沼翼 CSPヘッダー導入で実現するWebサイトの多層防御 ― 今すぐ試せる設定例と運用知見 ― NIKKEI TECH TALK #35
2. ハッシュタグ #nikkei_tech_talk 自己紹介 2 飯沼 翼 (Tsubasa Iinuma) • 所属： 株式会社日本経済新聞社 CDIO室 セキュリティチーム セキュリティエンジニア • 普段の業務： プロダクトセキュリティの専任者として、 主にアプリケーションセキュリティ領域を担当 • 好きなこと： セキュリティについて語り合いながらお酒を飲む🍷
3. ハッシュタグ #nikkei_tech_talk • Content Security Policy (CSP)の概要 • 多層防御の必要性とCSPの位置付け • CSP導入の段階的アプローチ • CSP導入の3ステップ紹介 • Tips: CSPバイパス • まとめ きょうの流れ 3
4. ハッシュタグ #nikkei_tech_talk • Webサイトがブラウザに対し、読み込みを許可するリソースを伝え るためのHTTPヘッダー • 主なディレクティブ ◦ script-src: JavaScriptの読み込みと実行を保護 ◦ style-src: CSSの読み込みと実行を保護 ◦ img-src: 画像の読み込みを保護 • 仕様のバージョンは「Level」で表され、現時点の最新はLevel 3 • クロスサイト・スクリプティング（XSS）攻撃のリスクを軽減 Content Security Policy (CSP)の概要 4
5. ハッシュタグ #nikkei_tech_talk • Webサイトに悪意のあるスクリプトを埋め込まれる脆弱性 • 悪用された場合、Webサイトの改ざん、個人情報の漏えい、 Cookie情報の窃取などの被害に遭うおそれ ◦ 近年では、マルウェア配布サイトへの誘導手段としても利用 • 2025年現在でも、最も発見されている脆弱性の1つ クロスサイト・スクリプティング（XSS）とは 5
6. ハッシュタグ #nikkei_tech_talk なぜ多層防御が必要か？ • 対策は破られる可能性がある • 単一の防御だけでは、未知の脆弱性や実装ミスで突破されるリス クが残る • 近年のVibe Codingの普及により、脆弱性のあるコードが混入し やすくなっている 多層防御の必要性とCSPの位置付け 6
7. ハッシュタグ #nikkei_tech_talk Webセキュリティにおける多層防御のイメージ • 第1層: WAF ◦ アプリケーションの手前で不正なリクエストをブロック • 第2層: 入口対策（バリデーション） ◦ 不正なデータを受け付けない • 第3層: 出口対策（エスケープ処理） ◦ データの出力や処理時にコンテキストに応じたエスケープ 多層防御の必要性とCSPの位置付け 7
8. ハッシュタグ #nikkei_tech_talk Webセキュリティにおける多層防御のイメージ • 第1層: WAF ◦ アプリケーションの手前で不正なリクエストをブロック • 第2層: 入口対策（バリデーション） ◦ 不正なデータを受け付けない • 第3層: 出口対策（エスケープ処理） ◦ データの出力や処理時にコンテキストに応じたエスケープ →これらの対策をすり抜けられたら…？ 多層防御の必要性とCSPの位置付け 8
9. ハッシュタグ #nikkei_tech_talk CSPの位置付け • クロスサイト・スクリプティング（XSS）への最後の砦 • ユーザーのブラウザ上で不正なスクリプトの実行を阻止 ◦ 被害を水際で防ぐことができる • 今回はCSP Level 3を使った例を紹介 多層防御の必要性とCSPの位置付け 9
10. ハッシュタグ #nikkei_tech_talk CSP導入の段階的アプローチ 10 現状把握とポリシー設計 ポリシー 案の決定 現状分析と ポリシー案の策定 レポート収集とポリシー改善 Report-Only モードで導入 違反レポートの 収集と分析 ポリシーの修正 ポリシーに 見落としや 不備は？ 本番適用と継続的監視 Enforceモードで 導入 継続的な監視と メンテナンス いいえ はい
11. ハッシュタグ #nikkei_tech_talk CSP導入の段階的アプローチ 11 現状把握とポリシー設計 ポリシー 案の決定 現状分析と ポリシー案の策定 レポート収集とポリシー改善 Report-Only モードで導入 違反レポートの 収集と分析 ポリシーの修正 ポリシーに 見落としや 不備は？ 本番適用と継続的監視 Enforceモードで 導入 継続的な監視と メンテナンス いいえ はい Step 1 Step 2 Step 3
12. ハッシュタグ #nikkei_tech_talk • 事前にチームごとの役割分担をしておくと進めやすい （日経の場合） • 開発チーム： ◦ 対象範囲決定、ポリシー策定、メンテナンスなど • セキュリティチーム： ◦ 質疑応答（技術支援）、ポリシーレビュー Step 0: 事前準備 12
13. ハッシュタグ #nikkei_tech_talk 1. 現状分析 • 導入予定のプロダクトのリソース使用状況を把握する ◦ インラインスクリプトが多い、公開CDNを利用しているなど • ブラウザの開発者ツールなどを用いて、サイトで読み込まれている リソースのドメインを収集 ◦ 厳しいポリシー（default-src: 'none'）をReport-Onlyモー ドで導入し、レポートを収集して洗い出すのも効率的 ◦ report-toディレクティブを使用すると、Reporting API経 由で送信されるので開発者ツールで確認しやすい Step 1: 現状把握とポリシー設計 13
14. ハッシュタグ #nikkei_tech_talk 2. ポリシー方針の決定 Step 1: 現状把握とポリシー設計 14 方式 推奨度 メリット デメリット おすすめ Strict CSP (nonce/hash) ★★★ 最も安全 導入コストが高い 新規プロダクト 許可リスト ★★☆ バランスが良い バイパスリスクあり （後ほど説明） 新規プロダクト 既存プロダクト unsafe-inline ★☆☆ 導入が一番楽 XSS対策効果が激減 非推奨 （最終手段）
15. ハッシュタグ #nikkei_tech_talk 3. ポリシー案の策定 • 許可リストを選んだ場合： ◦ 洗い出したドメインをscript-srcなどに設定 • Strict CSPを選んだ場合： ◦ サーバーサイドでリクエストごとにユニークな文字列（nonce） を生成し、CSPヘッダーとHTML内の要素のnonce属性にそ れぞれ設定 ◦ どこでnonceを生成するかなども併せて決定 Step 1: 現状把握とポリシー設計 15
16. ハッシュタグ #nikkei_tech_talk 1. Report-Onlyモードで導入 • 読み込みや実行は制限はされないので、本番環境でも利用可 • 違反があった場合にはレポートだけを送信 Step 2: レポート収集とポリシー改善 16 Content-Security-Policy-Report-Only: <policy-directive>; …; <policy-directive>; report-uri <uri>
17. ハッシュタグ #nikkei_tech_talk 2. レポートの送信先 • SentryやDatadogなどのエラー監視SaaSがCSPに対応して いて設定も簡単なので良い ◦ アクセスが多いサイトはDatadogのほうが安いのでおすすめ • Firefoxはreport-toに未対応なので、幅広いブラウザをカバー するためにreport-uriの併記か単体使用を推奨 report-toディレクティブのブラウザ別の対応状況： https://caniuse.com/mdn-http_headers_content-security-policy_report-to Step 2: レポート収集とポリシー改善 17
18. ハッシュタグ #nikkei_tech_talk 1. Enforceモードで導入 • Report-Onlyで違反レポートを潰したら、いよいよ本番適用 • ヘッダー名を以下のように変更することで、ポリシー違反のリソー スはブロックされるように Step 3: 本番適用と継続的監視 18 Content-Security-Policy-Report-Only: ↓ Content-Security-Policy:
19. ハッシュタグ #nikkei_tech_talk 2. 継続的なメンテナンス • 新しい機能の追加や外部サービスの変更で、CSPは陳腐化する • 定期的にレポートを監視し、サイトの更新に合わせてアップデート をしていく ◦ フレームワークやCI/CDによる自動化も検討 Step 3: 本番適用と継続的監視 19
20. ハッシュタグ #nikkei_tech_talk • 許可リストには、バイパスのリスクが常に付きまとう • 以下のポリシーは見た目は安全そうだが… Tips: CSPバイパス 20 Content-Security-Policy: default-src 'self'; script-src 'self' https://www.google.com
21. ハッシュタグ #nikkei_tech_talk • 許可リストには、バイパスのリスクが常に付きまとう • 以下のポリシーは見た目は安全そうだが… →実はCSPバイパスが可能 Tips: CSPバイパス 21 Content-Security-Policy: default-src 'self'; script-src 'self' https://www.google.com
22. ハッシュタグ #nikkei_tech_talk 以下のような方法でCSPをバイパスすることが可能 • 許可したドメイン配下に脆弱なスクリプトが存在 ◦ reCAPTCHA関連の古いスクリプト（通常は使われない） ◦ 既知の脆弱性が存在するAngularJSが内包 • 緩和策： ◦ 公開CDNを使用しない、ドメイン単位→パス単位で許可など Tips: CSPバイパス 22 <script src="https://www.google.com/recaptcha/about/js/main.min.js"></script> <img src=x ng-on-error="$event.target.ownerDocument.defaultView.alert(1)">
23. ハッシュタグ #nikkei_tech_talk • あらかじめ各Stepで具体的な導入期間を設定すること ◦ EnforceまでのStepは長引きがちなので、期間を決めて集中 して取り組む ◦ unsafe-inlineの排除などは別途期間を設けると良い • 積極的に開発チームをサポートする ◦ CSPは複雑なので、そこがネックで取り組みが遅くなることも ◦ 有識者がSlackやMTGで積極的にコミュニケーション • プロダクトごとに現実的なポリシーの設計を ◦ 非現実的なポリシー設計をすると導入はなかなか進まない 日経でCSPを導入・検討してみて感じたこと 23
24. ハッシュタグ #nikkei_tech_talk • CSP導入はXSSに対する多層防御の最後の砦 • CSPは段階的に導入できる まとめ 24
25. ハッシュタグ #nikkei_tech_talk • CSP未導入の方： ◦ Report-Onlyの導入を社内PoCで実施 • CSP導入済みの方： ◦ 現状のCSPヘッダーを見直し、より堅牢なポリシーへの移行を 検討（unsafe-inline→許可リスト、許可リスト→nonce） 次の一歩 25
26. 付録 26
27. ハッシュタグ #nikkei_tech_talk • CSP Evaluator ◦ https://csp-evaluator.withgoogle.com/ ◦ Google公式のポリシーチェッカー ◦ CSPバイパスも検出してくれる 便利系ツール 27
28. ハッシュタグ #nikkei_tech_talk • コンテンツセキュリティポリシー (CSP) - HTTP | MDN ◦ https://developer.mozilla.org/ja/docs/Web/HTTP/Guides/CSP ◦ CSPの概要を手っ取り早く知りたいときにおすすめ • Content Security Policy Level 3 ◦ https://www.w3.org/TR/CSP3/ ◦ MDNよりも詳しい情報が得られる • w3c/webappsec-csp | GitHub ◦ https://github.com/w3c/webappsec-csp/issues ◦ 新しいディレクティブや今後のアップデートを最速で キャッチアップ系 28
29. ハッシュタグ #nikkei_tech_talk • 厳格なコンテンツ セキュリティ ポリシー（CSP）を使用してクロスサイト スクリプ ティング（XSS）を軽減する | Articles | web.dev ◦ https://web.dev/articles/strict-csp?hl=ja ◦ Strict CSPについて解説する記事 • nonce - HTML | MDN ◦ https://developer.mozilla.org/ja/docs/Web/HTML/Reference/Global_attributes/ nonce ◦ nonce属性について解説する記事 Strict CSP系 29
30. ハッシュタグ #nikkei_tech_talk Content-Security-Policy: default-src 'self'; upgrade-insecure-requests; base-uri 'none'; connect-src 'self' https://api.example.com; form-action 'self'; frame-ancestors 'none'; img-src 'self' data: https://image-assets.example.com; object-src 'none'; script-src 'self' https://script-assets.example.com; style-src 'self' 'unsafe-inline' https://style-assets.example.com; report-uri <uri> 許可リストの設定例（緩め） 30
31. ハッシュタグ #nikkei_tech_talk Content-Security-Policy: default-src 'none'; upgrade-insecure-requests ; base-uri 'none'; connect-src 'self' https://www.example.com; font-src https://font-assets.example.com; form-action 'self'; frame-ancestors 'none'; frame-src https://frame.example.com; img-src 'self' data: https://media-assets.example.com; manifest-src 'self'; script-src https://script-assets.example.com; style-src https://style-assets.example.com; report-uri <uri> 許可リストの設定例（厳しめ） 31
32. 32 ご清聴ありがとうございました！