Eyes, JAPAN Blog > Content Security Policyのポリシー設定の基本

Content Security Policyのポリシー設定の基本

Takeyuki Sato

この記事は1年以上前に書かれたもので、内容が古い可能性がありますのでご注意ください。

CSP(Content Security Policyとは)

CSPとは提供するコンテンツを制限し、XSSなどの脆弱性を利用した攻撃を検知するシステムです。
XSSなどの脆弱性に対して非常に有効なセキュリティ機構であると言われております。
設定はサーバーサイドで設定し、サーバーの設定ファイル、cgiスクリプト内、またはhtmlのmetaタグで指定することができます。
現在、最新のブラウザーではCSPが実装されています。しかし、CSPは後方互換性のある設計になっていまして付けていても対応していないブラウザでは無視されます。
適用方法は簡単ですが、ポリシーの設計は少し考えなければなりません。

CSPのポリシー設定で気をつけること

Content-Security-Policy: script-src takeyuki.com

このポリシーは初心者の方などやってしまいそうですが、スクリプトソースのオリジンをtakeyuki.comにしています。
問題なさそうです。確かにこの設定だとインラインスクリプトは使えませんし、外部からスクリプトを取って来ることもできませんが例えばフラッシュコンテンツを読み込みそのオブジェクトからスクリプトを実行できてしまいます。
このように、攻撃者が利用可能な攻撃メソッドは山ほどあります。
どのようにしたら防げるでしょうか。
ファイヤーウォールのポリシーを設計するとき最初に全てのポートを閉じます。
それと同じように、CSPでも全てのコンテンツを基本的にどこから提供するかを設定する必要があります。

Content-Security-Policy: default-src ‘self'; script-src takeyuki.com

default-srcは、スクリプトをはじめ画像、オーディオなどの全てのコンテンツをどこからダウンロードできるかを設定できます。
今回、selfとしたのは保護しているドキュメントと同一オリジンからのコンテンツ配布を許可しています。
または、noneを使って以下のようにhtmlドキュメント以外も禁止してもいいと思います。

Content-Security-Policy: default-src ‘none'; script-src takeyuki.com

当たり前のことですが一旦全ての穴を防ぎそこから穴を開けていくこと。
CSPにはレポート機能がありスクリプトが実行されると報告することができます。ポリシー適用のテストするときはrefuseをせずレポートオンリーモードにして報告されるレポートを見ながらテストするのがいいと思います。

まとめ

大切なのは利用してみること。
お粗末なポリシー設計しても結局XSSの脆弱性なければ攻撃できないのでアドバンテージと考えれば気が進めのではないでしょうか。
もちろんセキュアなコーディングは忘れずに

  • このエントリーをはてなブックマークに追加

Comments are closed.