Content Security Policy

Content Security Policy（コンテンツセキュリティポリシー、略称: CSP）は、ウェブサイトのセキュリティを強化するための仕組みである。CSPは、ウェブサイトの所有者が、そのサイトが読み込むことを許可するコンテンツの種類や、どこからコンテンツを読み込むかをブラウザに明確に指示するための、セキュリティ標準を定義したものである。これにより、クロスサイトスクリプティング（XSS）、クリックジャッキング、その他のコードインジェクション攻撃などの攻撃からウェブサイトを保護する^[1]。

対象となるコンテンツの種類は、JavaScript、CSS、HTMLフレーム、ウェブワーカー、フォント、画像、Javaアプレット、ActiveX、音声・動画ファイルなどの埋め込み可能オブジェクト、およびその他のHTML5機能である。World Wide Web Consortium（W3C）のウェブアプリケーションセキュリティワーキンググループで勧告され^[2]、現代のウェブブラウザに広くサポートされている^[3]。

概要

この基準は、元々「Content Restrictions」という名前で2004年にRobert Hansenによって提案され^[4]た。最初にFirefox 4で実装され、その後すぐに他のブラウザにも採用された。このバージョン1は、2012年にW3C勧告候補として公開され^[5]、その後すぐに2014年にはさらなるLevel 2が公開された。その後、Level 3の草案が開発中であり、新機能はウェブブラウザに迅速に採用されている^[6]。

ウェブサイトは複数のCSPヘッダを宣言でき、強制モードとレポート専用モードを混在させることもできる。各ヘッダはブラウザによって個別に処理される。CSPはmeta要素を使用してHTMLコード内で配信することもできるが、この場合その有効性は限定的となる^[7]。

多くのウェブアプリケーションフレームワークがCSPをサポートしている。例えば、AngularJS（ネイティブ）^[8]やDjango（ミドルウェア）がある。Ruby on Railsの手順はGitHubによって公開されている。しかし、フレームワークのサポートが必要となるのは、CSPの内容がnonceオリジンの使用など、何らかの形でウェブアプリケーションの状態に依存する場合のみである。そうでなければ、CSPはむしろ静的であり、ロードバランサやウェブサーバなど、アプリケーションより上位のウェブアプリケーション層から配信することができる。

ヘッダ名

CSP実装の一部として、以下のヘッダ名が使用されている^[3]。

• Content-Security-Policy – W3Cの文書で提案された標準ヘッダ。Google Chromeではバージョン25から^[9]、Firefoxではバージョン23からこれをサポートしている^[10]。2013年8月6日にリリース^[11]。WebKitはバージョン528（ナイトリービルド）からこれをサポートしている^[12]。ChromiumベースのMicrosoft EdgeのサポートはChromeと同様である^[13]。
• X-WebKit-CSP – 2011年にGoogle Chrome、Safari、およびその他のWebKitベースのウェブブラウザに導入された。現在では非推奨の実験的ヘッダである^[14]。
• X-Content-Security-Policy – Gecko 2ベースのブラウザ（Firefox 4からFirefox 22、Thunderbird 3.3、SeaMonkey 2.1）に導入された。現在では非推奨の実験的ヘッダ^[15]である。Internet Explorer 10およびInternet Explorer 11もCSPをサポートしているが、実験的なX-Content-Security-Policyヘッダを使用したsandboxディレクティブのみである^[16]。

バイパス

2015年12月^[17]と2016年12月^[18]に、'nonce'によるオリジンの許可リストをバイパスするいくつかの方法が公開された。2016年1月^[19]には、サーバー全体のCSP許可リストを利用して、同じサーバーでホストされている古くて脆弱なバージョンのJavaScriptライブラリ（CDNサーバーでよくあるケース）を悪用する別の方法が公開された。2017年5月^[20]には、ウェブアプリケーションフレームワークのコードを使用してCSPをバイパスするさらに別の方法が公開された。

動作

HTML5とJavaScriptの機能とコンテンツセキュリティポリシーの制御との対応関係

サーバーの応答にContent-Security-Policyヘッダが存在する場合、準拠したクライアントは宣言的な許可リストポリシーを強制する。ポリシーの目標の一例は、特定のクロスサイトスクリプティング攻撃を防ぐために、JavaScriptの実行モードをより厳格にすることである。実際には、これにより多くの機能がデフォルトで無効になる。

• インラインJavaScriptコード^{[注釈 1]}
  • <script>ブロック^{[注釈 2]}
  • HTML属性としてのDOMイベントハンドラ（例: onclick）
  • javascript:リンク
• インラインCSS文
  • <style>ブロック^{[注釈 2]}
  • HTML要素に付けられたstyle属性
• 動的なJavaScriptコード評価^{[注釈 3]}
  • eval()
  • setTimeoutおよびsetInterval関数への文字列引数
  • new Function()コンストラクタ
• 動的なCSS文
  • CSSStyleSheet.insertRule()メソッド

新しいアプリケーションでCSPを使用するのは、特にCSP互換のJavaScriptフレームワークを使えば非常に簡単かもしれないが^{[注釈 4]}、既存のアプリケーションでは何らかのリファクタリング、あるいはポリシーの緩和が必要になる場合がある。CSP互換のウェブアプリケーションに推奨されるコーディングプラクティスは、外部ソースファイルからコードをロードし（<script src>）、JSONを評価するのではなくパースし、EventTarget.addEventListener()を使用してイベントハンドラを設定することである^[21]。

レポート

リクエストされたリソースやスクリプトの実行がポリシーに違反するたびに、ブラウザはreport-uri^[22]またはreport-to^[23]で指定された値に、違反の詳細を含むPOSTリクエストを送信する。

CSPレポートは標準的なJSON構造であり、アプリケーション独自のAPI^[24]または公開されているCSPレポート受信サービスによって捕捉できる。

2018年、セキュリティ研究者らは、report-uriで指定された受信者に誤検知レポートを送信する方法を示した。これにより、潜在的な攻撃者が任意にこれらのアラームをトリガーすることが可能になり、実際の攻撃が発生した場合にその有用性を低下させる可能性がある^[25]。この動作は意図されたものであり、ブラウザ（クライアント）がレポートを送信するため修正することはできない。

ブラウザアドオンと拡張機能との相性

当初のCSP（1.0）処理モデル（2012年～2013年）^[26]によると、CSPはユーザーがインストールしたブラウザのアドオンや拡張機能の動作を妨げるべきではないとされていた。CSPのこの機能は、事実上、アドオン、拡張機能、またはブックマークレットが、そのスクリプトのオリジンに関係なくウェブサイトにスクリプトを注入することを許可し、したがってCSPポリシーから免除されることを意味していた。

しかし、このポリシーはその後（CSP 1.1^[27]の時点で）次のような文言に修正された。以前の絶対的な「should (not)」という表現の代わりに、「may」という単語が使用されていることに注意されたい。

注：ユーザーエージェントは、ユーザー設定、ブックマークレット、ユーザーエージェントへのサードパーティ製の追加機能、およびその他の同様のメカニズムを通じて、ユーザーがポリシーの強制を変更またはバイパスすることを許可してもよい（may）。

この絶対的な「should」という文言は、ブラウザのユーザーがポリシーの遵守を要求・要望し、人気のあるブラウザ（Firefox、Chrome、Safari）にそれをサポートするための変更をインストールさせるために使われていた。これは、TwitterやGitHubのようなサイトが強力なCSPポリシーを使用し始め、ブックマークレットの使用を「破壊」したときに特に議論を呼んだ^[28]。

W3Cのウェブアプリケーションセキュリティワーキンググループは、このようなスクリプトをブラウザによって実装されたTrusted Computing Baseの一部であると考えている。しかし、この免除は、悪意のあるアドオンや拡張機能によって悪用される可能性のあるセキュリティホールであると、Cox Communicationsの代表者によってワーキンググループによって主張されている^[29][30]。

補完的な対策

W3Cによって多くの新しいブラウザセキュリティ基準が提案されており、そのほとんどはCSPを補完するものである^[31]。

• Subresource Integrity（SRI）：CDNなどのサードパーティのサーバーから、既知で信頼されたリソースファイル（通常はJavaScript、CSS）のみが読み込まれるようにするためのもの。
• 混合コンテンツ（Mixed Content）：HTTPS経由で読み込まれ、平文のHTTP経由のコンテンツにリンクしているページに対する、意図されたブラウザのポリシーを明確にするためのもの。
• Upgrade Insecure Requests：HTTPSに移行したページ上のレガシーリンクをどのように処理するかをブラウザに示唆するためのもの。
• Credential Management：複雑なログインスキームを容易にするために、ユーザーの資格情報にアクセスするための統一されたJavaScriptのAPI。
• Referrer Policy：リファラヘッダの生成についてブラウザに示唆するためのCSP拡張^[31]。

関連項目

• NoScript – 対XSS保護およびApplication Boundaries Enforcer (ABE)機能を備えたFirefox向け拡張機能^[32][33]
• HTTP Switchboard – ユーザー定義のCSPルールを設定できるGoogle ChromeおよびOpera^[34]向け拡張機能
• HTTP Strict Transport Security