安全でないインラインを許可する場合、CSPは何を保護しますか
現在、以下のようにコンテンツセキュリティポリシー（CSP）を定義しています。
Header set Content-Security-Policy: "default-src 'self' data:; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data:;"
上記のCSP定義を考慮すると、インラインJavaScriptはいつでも上書きされる可能性があるため、インラインJavaScriptに挑戦しています。
実質的に保護されない場合、unsafe-inlineの使用は何ですか？
unsafe-inlineオプションは、現在のサイトでインラインコードを移動または書き換えるのが即時のオプションではないが、CSPを使用して他の側面（object-srcなど、サードパーティのインジェクションを防止する）を制御する場合に使用しますjsなど）。 unsafe-inlineは、安全ではないページ内スクリプトおよびイベントハンドラーの実行を許可するため、あまりセキュリティを提供しません。
Googleの CSP Evaluator は、ポリシーが強力かどうかを判断するための気の利いたツールです。
unsafe-inlineオプションが使用されるユースケースは、Googleの コンテンツセキュリティポリシーに関するWeb開発者向けドキュメント にあります。
結婚指輪のディスカッションフォーラム管理者は、すべてのリソースが安全なチャネルを介してのみロードされるようにしたいと考えていますが、実際には多くのコードを記述しません。インラインスクリプトとスタイルでいっぱいになっているサードパーティのフォーラムソフトウェアの大部分を書き換えることは、彼の能力を超えています。次のポリシーが有効になります。
Content-Security-Policy: default-src https:; script-src https: 'unsafe-inline'; style-src https: 'unsafe-inline'
https:がdefault-srcで指定されていても、スクリプトとスタイルのディレクティブはそのソースを自動的に継承しません。各ディレクティブは、その特定のタイプのリソースのデフォルトを完全に上書きします。
私はそれが多くから保護されないことに同意しますが、XSSの古典的な悪用はブラウザエクスプロイトフレームワークであり、インターネット上にサーバーがあり、XSSの穴が開いたら「http://bad.example.com」にドロップします/hook.js ">これで、そのサーバーから被害者のブラウザを制御できます。アクセスを持続させるために隠しウィンドウを開くように指示すると、ブラウザへの双方向通信ができます。
「unsafe-inline」を使用するCSPでは、潜在的にすべて同じ悪用が可能になります（悪用が注入可能なスペースに収まると仮定します）。
つまり、洗練された十分なクライアント部分をWebページに挿入できれば、他のチャネルを介してほとんどの同じ攻撃を行うことはまだ可能だと思います。
「自己安全でないインライン」に対する私の攻撃者の帽子は、CSPがまったくないよりも悪用が困難です。攻撃ツールが弱いCSPに適応することを期待していますが、多くの一般的なエクスプロイトがすぐにカードから外れるか、より困難になることを意味します。