コンテンツセキュリティポリシーにはどのような制限がありますか？
私はこの新しいテクニックがnotから私たちを守ってくれるのか疑問に思っています。
私が見ると、インラインスクリプトが無効になっているので（そしてjavascript:リンク）その後、自動実行されるJavaScriptを介して機密データの盗難の問題を解決します。
ただし、予期しない方法で画面上のデータを変更したり、別のWebサイトへのリンクを提供して説得力のあるフィッシング詐欺を作成したりすることは可能です。
これは正確ですか、またはアウトリンクも禁止されていますか？
私がCSPのスコープに精通していないため、外部リソース呼び出しで機密データをキャプチャするためのトリッキーな方法もあるかもしれません。
緊密なCSPが存在する場合のXSSの可能性がある攻撃の範囲は何ですか？
編集：この投稿の目的のために更新された仮定：
- ユーザーはCSP 2対応のブラウザーを使用しています。
- 列をなして
style=は引き続きポリシーで許可されます。style-src ... unsafe-inline - 私たちが制御するドメインからのリソースのロードのみを許可します。 （外部画像なし）
- 私たちは独自のCDNを実行するため、ドメインにはサードパーティのコンテンツがなく、メインドメインと同じセキュリティ標準に適合しています。
ただし、予期しない方法で画面上のデータを変更したり、別のWebサイトへのリンクを提供して説得力のあるフィッシング詐欺を作成したりすることは可能です。
これは正確ですか、またはアウトリンクも禁止されていますか？
はい、1つの注意点があります。サイトのユーザーは最新のブラウザを実行しています。この正確な理由により、私のチームは、実際のコンテンツインジェクションなしのXSS（たとえば、引用符で囲まれていないタグ属性コンテキストにインジェクトする）は、CSPのためにコンテンツインジェクションバグ自体よりも優先度が低いと見なしています。何らかの形のstrong CSPをサポートしていないブラウザには、実質的にユーザーがいないことに恵まれています。
緊密なCSPが存在する場合のXSSの可能性がある攻撃の範囲は何ですか？
これが不快に聞こえる場合は、ここで許してください。しかし、あなたの質問は「タイトなCSP」を定義していません。そのため、多くの見落としがあることについて詳しく説明しましょう。
議論のために、これが提案されたポリシーであるとしましょう（明確にするために改行が追加されていますが、これは有効なヘッダーではありません）。
Content-Security-Policy: default-src 'self'; img-src https: data:; connect-src Paypal.com api.example.com; script-src 'self' ajax.googleapis.com; style-src 'self' 'unsafe-inline'
注：unsafe-inlineをstyle-srcから削除することは、今日では実用的ではありません。
これは明らかな欠陥があり、それほど明白ではないかなり良いポリシーですが、インラインスクリプトは許可されていません。 CSPについては、さらに多くの注意点があります。evalとインラインスクリプトを無効にするだけではありません（javascript:とon*イベントハンドラーが含まれています）。
XSSを実際に制限するためにサードパーティをロックダウンする
- 「CSPバイパス」は物です。 H5SC Minichallenge 3： "Sh * t、it's CSP！" 。 XSSを開くサードパーティのcdnを許可します。
- CSP：反映されたXSSでフォームアクションをバイパスする
form-actionは「フェッチディレクティブ」ではないため、default-src 'self'には含まれません。 - 注入されたコンテンツタグ（例：
img、style、etc）を介したデータ漏えい。ポリシーはより緩和される傾向があります。画像タグを介したexfilを許可しました。
非常に多くの他のベクターがまだ存在しています
GitHubのCSPジャーニー には、特定の攻撃を防ぐためにポリシーを調整する方法に関する多くのポイントが含まれています。
以下のすべては、提案されたポリシーで悪用される可能性があります。
- JSONP経由のXSSを防ぐために
'self'からscript-srcを削除します imgおよびformタグを介したCSRFトークンの漏洩- ホストされているフラッシュファイルを
'self'ではなく別のOriginに移動すると、フラッシュがすべてを台無しにします。 - 動的ポリシーを使用して、特定のページのセットからのみ使用する必要があるAPIの予期しない使用を防止します。
'self'/frame-srcのchild-srcの使用を制限していますbaseタグの悪用。
CSPが適用されない場合もあります。
CSPを完全に回避することは可能です。ページ上のユーザー制御データが実際に混乱する可能性がある例については、 PDF content-type sniffing を参照してください。
CSPの観点から見ると、これについて文字通り何もできません。
そして時々、インターネットはあなたを泣かせます。
敷居に触れずにパイを盗む を参照してください。CSSを使用して、JavaScriptを使用せずにページ上のデータを盗み出して取り出すことができます。
'unsafe-inline'を削除することは現実的ではないため、この攻撃は可能です。ただし、この攻撃は実行が困難です。
タイトなポリシーとは何かを正確に検討する必要があります。 3つのレベルを特定しました。
レベル1-XSSの停止
このレベルでは、厳格なポリシーによってすべてのXSSが停止します。サイトにXSSの欠陥がある場合、これらは悪用されることはありません（ユーザーのブラウザーがCSPをサポートしている場合）。
XSS攻撃者は、独自のサーバー上のリソースを引き続き参照する可能性があり、これにより webビーコン が作成されます。ユーザーのIPアドレスを確認し、悪意のあるコンテンツを配信する可能性があります（画像レンダリングのバグを悪用するなど）。また、フォームをリダイレクトして、非常に現実的なフィッシングフォームを作成する可能性もあります。
レベル2-ビーコンを停止
このレベルでは、すべての埋め込みリソースは信頼できるソースからのみロードできるため、Webビーコンは不可能です。フォームアクションも制限されているため、フォームを直接リダイレクトすることはできません。
XSS攻撃者は引き続きページのコンテンツとレイアウトを変更できます。これには、悪意のあるリンクの埋め込みが含まれます。ただし、これがフィッシングの主要なリスクであるとは私は思いません。知識のあるユーザーは資格情報を入力する前にアドレスバーをチェックし、知識のないユーザーはもっと単純なトリックに陥ります。
レベル3-インラインCSSを停止
これにより、攻撃者がページレイアウトを変更する能力が低下します。ただし、コンテンツを制御し、リンクを挿入することはできます。
CSP監査人
ポリシーの評価に役立つ CSP監査人 ツールを作成しました。これは、ポリシーがレベル1を満たしているかどうかを評価するだけです。CSPを使用する主要なサイトの大部分は、レベル1を満たさないポリシーを持っていることがわかります。レベル2および3は達成がさらに困難になります。監査人をチェックインします（現時点では少なくとも）。
CSPは、多くのスクリプト駆動型攻撃からユーザーを保護します。 「機密データの秘密の盗難の問題を解決する」というあなたの考えは正確ではありません。そのページのスクリプトを介して秘密の脅威の問題を解決する可能性がありますが、たとえば、クロスタブの問題やプロキシ操作は解決しません。
より広い意味で、攻撃の完全なリストはないため、「この新しい手法では何から保護されないのか不思議に思っています」と列挙しようとすると、無限のセットになります。