[解決済み】コンテンツセキュリティポリシー（CSP）とはどのようなものですか？

質問

デベロッパーコンソールでエラーが多発するのですが。

文字列の評価を拒否されました

インラインスクリプトの実行は、以下のコンテンツセキュリティポリシーディレクティブに違反するため、拒否されました。

スクリプトの読み込みを拒否されました

スタイルシートの読み込みを拒否された

これはどういうこと？コンテンツセキュリティポリシー（CSP）はどのように機能するのですか？どのように Content-Security-Policy HTTPヘッダーは？

具体的には、どのように...

1. ...複数のソースを許可しますか？
2. ...異なるディレクティブを使用しますか？
3. ...複数のディレクティブを使用しますか？
4. ...ポートを扱うか？
5. ...異なるプロトコルを扱うことができますか？
6. ...できるようにする file:// プロトコル？
7. ...インラインスタイル、スクリプト、タグを使用する <style> と <script> ?
8. ...できる eval() ?

そして最後に。

1. は具体的にどのようなものなのでしょうか？ 'self' の意味は？

どのように解決するのですか？

その Content-Security-Policy メタタグを使用することにより XSS ブラウザがそれ以外の場所からデータを読み込むのを防ぐために、リソースの読み込み元を定義することができるようになり、攻撃を防ぐことができます。これにより、攻撃者が悪意のあるコードをサイトに注入することが難しくなります。

なぜCSPエラーが次々と発生するのか、その原因を突き止めようと頭を抱えたが、その仕組みについて簡潔で明快な説明はないようだ。そこで、私が試みたのは以下のような説明です。 一部 CSPのポイントを簡単に説明し、主に私が難しいと感じた点を中心に説明します。

簡潔さのために、各サンプルにタグの全文を書くことはしません。その代わり content プロパティを使用するため、サンプルでは content="default-src 'self'" は、このような意味です。

<meta http-equiv="Content-Security-Policy" content="default-src 'self'">

1. 複数のソースを許可するにはどうすればよいですか？

ディレクティブの後に、スペースで区切ったソースを列挙するだけでよいのです。

content="default-src 'self' https://example.com/js/"

以外のパラメータは引用符で囲まないことに注意してください。 特別 のようなものです。 'self' . また、コロン( : の後にある ディレクティブ、そしてスペースで区切られたパラメータのリストだけです。

指定されたパラメータ以下はすべて暗黙のうちに許可されます。つまり、上記の例では、これらは有効なソースとなります。

https://example.com/js/file.js
https://example.com/js/subdir/anotherfile.js

しかし、これらは有効ではありません。

http://example.com/js/file.js
^^^^ wrong protocol

https://example.com/file.js
                   ^^ above the specified path

2. ディレクティブはどのように使い分ければよいのですか？それぞれ何をするのですか？

最も一般的なディレクティブは。

• default-src javascript、画像、CSS、フォント、AJAXリクエストなどを読み込むためのデフォルトのポリシーです。
• script-src javascript ファイルの有効なソースを定義します。
• style-src は、CSS ファイルの有効なソースを定義します。
• img-src は画像の有効なソースを定義します。
• connect-src は、XMLHttpRequest (AJAX)、WebSocket、または EventSource に対する有効なターゲットを定義しています。ここで許可されていないホストへの接続が試みられた場合、ブラウザは 400 エラー

他にもありますが、最も必要とされるのはこれらのものです。

3. 複数のディレクティブを使用するにはどうすればよいですか？

すべてのディレクティブは、1つのメタタグの中で、セミコロンで終端して定義します ( ; ):

content="default-src 'self' https://example.com/js/; style-src 'self'"

4. ポートの扱いはどうすればいいですか？

デフォルトのポート以外は、許可されたドメインの後にポート番号またはアスタリスクを追加して、明示的に許可する必要があります。

content="default-src 'self' https://ajax.googleapis.com http://example.com:123/free/stuff/"

上記のような結果になります。

https://ajax.googleapis.com:123
                           ^^^^ Not ok, wrong port

https://ajax.googleapis.com - OK

http://example.com/free/stuff/file.js
                 ^^ Not ok, only the port 123 is allowed

http://example.com:123/free/stuff/file.js - OK

先ほど述べたように、アスタリスクを使用して、すべてのポートを明示的に許可することもできます。

content="default-src example.com:*"

5. 異なるプロトコルを扱うにはどうしたらよいですか？

デフォルトでは、標準的なプロトコルのみが許可されます。例えば、WebSocket を許可するには ws:// は、明示的に許可する必要があります。

content="default-src 'self'; connect-src ws:; style-src 'self'"
                                         ^^^ web Sockets are now allowed on all domains and ports.

6. ファイルプロトコルを許可するには file:// ?

そのように定義しようとすると、うまくいきません。その代わり filesystem パラメータを使用します。

content="default-src filesystem"

7. インラインスクリプトやスタイル定義を使用するにはどうしたらよいですか？

明示的に許可されていない限り、インラインのスタイル定義や、以下のようなコードを使用することはできません。 <script> のようなタグプロパティ、または onclick . このように許可するのです。

content="script-src 'unsafe-inline'; style-src 'unsafe-inline'"

また、インラインでbase64エンコードされた画像を明示的に許可する必要があります。

content="img-src data:"

8. を許可するにはどうすればよいですか？ eval() ?

多くの人は、「evalは悪であり、世界の終わりをもたらす最も可能性の高い原因である」と言うだろう。しかし、それは間違いです。確かにevalを使うとサイトのセキュリティに大きな穴を開けることができますが、完全に有効な使用例もあります。ただ、賢く使うことが必要なのです。このように許可しています。

content="script-src 'unsafe-eval'"

9. 具体的にどのような 'self' の意味は？

を取るかもしれません。 'self' は、localhost、ローカルファイルシステム、または同じホスト上のものという意味です。そのような意味ではありません。コンテンツ・ポリシーが定義されているファイルと同じスキーム（プロトコル）、同じホスト、同じポートを持つソースを意味します。あなたのサイトはHTTPで提供されていますか？明示的に定義しない限り、httpsは使えません。

私はこれまで 'self' を含めることは通常意味があるため、ほとんどの例でこれを使用していますが、決して必須ではありません。必要なければ削除してください。

でも、ちょっと待ってください! を使うことはできないのでしょうか？ content="default-src *" で終わりですか？

いいえ。セキュリティ上の脆弱性があることは明らかですが、期待通りに動作しません。たとえ いくつかのドキュメント は何でも許されると主張していますが、それは真実ではありません。インラインやエバルを許さないので、あなたのサイトを本当に、本当に脆弱にするには、これを使うことになるでしょう。

content="default-src * 'unsafe-inline' 'unsafe-eval'"

... でも、あなたはそうしないと信じています。

さらに読む

http://content-security-policy.com

http://en.wikipedia.org/wiki/Content_Security_Policy