同一生成元ポリシー-XHR応答
Same Origin Policy（SOP）は、あるOriginから別のOriginからのread応答へのページ/スクリプトを防止しますが、ページ/ XMLHttpRequest（XHR）リクエストを別のオリジンに送信するスクリプト。 Mozillaの開発者サイト から：
- 通常、クロスオリジン書き込みが許可されています。例は、リンク、リダイレクト、フォーム送信です。ほとんど使用されない特定のHTTPリクエストには、プリフライトが必要です。
- 通常、クロスオリジン読み取りは許可されていませんが、埋め込みにより読み取りアクセスが漏洩することがよくあります。たとえば、埋め込み画像の幅と高さ、埋め込みスクリプトのアクション、または埋め込みリソースの可用性を読み取ることができます。
私の質問：それがページ/スクリプトが別のOriginからの応答を読み取るのを防ぐだけの場合、ブラウザに到達する前に応答をキャプチャするためにBurpのようなプロキシリスナーまたはWiresharkのようなスニファを使用することはできません（SOPが実装されています）？サーバーが別のオリジンからのそのようなリクエストに応答するのはなぜですか？クロスオリジンリソースシェアリング（CORS）が有効になっている場合にのみサーバーが応答する必要はありませんか？
ページ/スクリプトが別のOriginからの応答を読み取るのを防ぐだけの場合、Burpなどのプロキシリスナーや、wiresharkなどのスニファーを使用して、ブラウザーに到達する前に応答をキャプチャすることはできません（ここでSOPが実装されています）？
これらは2つの異なるタイプの攻撃です。別のオリジンからの読み取りを防ぐことで、ユーザーがアクセスした攻撃者のサイト（evil.example.com）が、ユーザーがログインしているサイト（webmail.example.com）にXHRリクエストを行い、データを取得するのを防ぎます。この場合、他のWebサイトがユーザーの電子メールメッセージを読み取ることができなくなります。
代行受信プロキシを使用するようにユーザーのマシンを構成できる場合、またはユーザーのネットワークで無差別モードで待機するWiresharkを配置できる場合は、攻撃者としてクロスドメインXHRリクエストは必要ない可能性があります。トラフィック。これの例外は [〜＃〜] poodle [〜＃〜] などの攻撃の場合です。たとえば、ネットワークを介してトラフィックをリッスンできるが、ユーザーの接続がSSLを使用してWebサイトに行われている場合、POODLE攻撃ベクトルを介して一度に1バイトを復号化するために、XTMトラフィックをMITMとして挿入する必要がある場合があります。
同一生成元ポリシーはここでは役に立ちませんが、存在しない場合は、MITM攻撃もPOODLEベクトルも必要ありません。同一生成元ポリシーは、他の方法では可能であるいくつかのWebベースの攻撃を防御します。
なぜサーバーが別のオリジンからのそのようなリクエストに応答するのですか？クロスオリジンリソースシェアリング（CORS）が有効になっている場合にのみ応答しませんか？
はい、サーバーが自身のオリジンからのリクエストにのみ応答する場合は、はるかに安全になります。ただし、新しいWebサーバーのリリースで標準として実装された場合、これはインターネットの大部分を壊します。 Origin間のリクエストを行わないブラウザを作成することも可能です。多くのサイトでは動作しないため、誰も使用しません。
実際、ほとんどのブラウザでサードパーティのCookieを無効にすることができます。これにより、Cookieが送信されなくなるため、実質的にOrigin AJAXリクエストが匿名で要求されます。確かにChromeは、Cookieの設定または読み取りを妨げ、他のブラウザはそのようなCookieの設定を制限します。もちろん、基本的なHTTP認証などの別の認証方法が使用されている場合は、ここでは役に立ちません。しかし、試してみると、ほとんどの場合、どの機能が壊れているかを確認できます。 。
なぜサーバーが別のオリジンからのそのようなリクエストに応答するのですか？
Originブラウザーのヘッダーは、ヘッダーが解析されるまで読み取られず、その時点でブラウザーはすでにCookieを送信しています-クロスOriginに対する制限は、Webサーバーがそれより前にリクエストをブロックできないため、ブラウザーレベルでより適切に実装されます。送信されます。
Origin間のリクエストを許可することは、これまでの方法で機能してきた方法であり、セキュリティは互換性とバランスを取る必要があります。 CORSは、サーバーがCORSにオプトインしない場合のセキュリティレベルがCORS以前のブラウザーを使用する場合と同じになるように設計されています。 CORS以前は、サイトがスクリプトを介して他のドメインにリクエストを行うことが可能でしたが、現在は同じです。サーバーの観点から考えると、XHR GETリクエストは、<img />タグを使用して別のドメインの画像を含めるのと同じです。 XHR POSTリクエストは、別のドメインに送信するフォームを作成するのと同じです。
あなたがこれらの要求をブロックするようにサーバーを構成し（たとえば、Originヘッダーを使用して）、これは 実際にはCSRF攻撃を防ぐ有効な方法 です。ただし、これはケースバイケースで行う必要があり、このヘッダーの存在はブラウザーとバージョン間で異なる可能性があることに注意してください（たとえば、古いブラウザーのサポートはありません）。
ほとんどの場合、MITMは単にOriginを偽装するだけなので、この例では役に立たないことに注意してください。
クロスオリジンリソースシェアリング（CORS）が有効になっている場合にのみ応答しませんか？
クロスオリジンリクエストに関するすべての問題は、すべて同じオリジンポリシーに従うブラウザーや、CSRFを防ぐためにトークンを使用するWebサイトなど、何らかの方法で解決されています。これはウェブです-デフォルトでは安全ではありません。セキュリティを考慮してWebサイトを開発すれば、これらの問題を解決できます。
なぜサーバーが別のオリジンからのそのようなリクエストに応答するのですか？クロスオリジンリソースシェアリング（CORS）が有効になっている場合にのみ応答しませんか？
サーバーの場合、CORS XHRと、リソースを含めることでトリガーされるクロスサイトリクエスト（つまり、<img src=、<script src=）またはリンク（<a href=）すべてが類似しており、確実に区別できません。これは、Webの既存のアーキテクチャによるものであり、一部のWebアプリケーションがCORS XHRを使用したいという理由だけで、すべてのサーバーが動作を変更することは期待できません。
この方法でリソースにアクセスできる場合も、通常は問題になりません。唯一の実際の問題は、ユーザーとそのブラウザーをだまして、このサイトにログインしているときにXHRでサイトにアクセスできるようにする（つまり、ブラウザーがセッションCookieを送信する）場合です。XHRを使用して機密情報を抽出し、それらをアタッカー。したがって、問題が発生した場所に保護が追加されます。ブラウザは、すべてのリクエストでセッションCookieを外部サイトに送信するため、外部サイトが明示的に指定されている場合にのみ、ブラウザは同一生成元ポリシーを弱める（つまり、外部サイトから読み取る）ことができるようにする必要があります。つまり、このリクエストはクロスオリジンであり、このオリジンをチェックして許可したことを承知しています。
CORS XHRルールは、ブラウザーのユーザーを潜在的な攻撃者と見なしません。このユーザーはとにかくリソースにアクセスできるためです。代わりに、ユーザーがログインしているサイトから情報を抽出しようとする外部の攻撃者を問題と見なします。これはCSRFと同様の方法ですが、CSRFはアクションをトリガーするためだけであり、結果を読み取るためのものではありません。したがって、ユーザーがトラフィックを監視するためにMITMソリューションをインストールしたかどうかは問題ではありません。攻撃者がそのようなものをインストールできる場合、それは確かに危険ですが、クラシックインクルード（<img src= etc）は、リソースへのアクセスをトリガーするのにすでに十分です。したがって、この攻撃ベクトルはCORS XHRのために特別に考慮する必要はありません。
burpのようなプロキシリスナーや、wiresharkのようなスニファを使用して、ブラウザに到達する前に応答をキャプチャすることはできませんか？
まず、クロスサイトリクエストフォージェリ（CSRF）攻撃は、攻撃者がネットワーク接続を傍受（MITM）できることを想定または暗示していません。犠牲者を中間者（MITM）にできる場合、認証データ（セッションCookieなど）を観察して自分でログインできるため、CSRF攻撃はほぼ冗長です。彼らがあなたのターゲットサイトを訪問するのを待つ必要なく彼らの認証データを公開するためただし、一般に、被害者をMITMする機能がある場合は、通常のCSRFよりも効果的な攻撃ベクトルを利用できます。
第2に、被害者をMITMでき、SOPによって妨げられるリクエストの応答を観察することが有用であったとしても、最も価値のあるターゲットはSSL/TLSを使用します。これにより、応答を観察できなくなり、SSL/TLSを危険にさらすことができる場合（悪意のあるCA証明書をマシンにインストールすることなどにより）、おそらくより優れた攻撃経路も利用できます。
なぜサーバーが別のオリジンからのそのようなリクエストに応答するのですか？
SOPを強制するのはWebサーバーの責任ではなく、Webブラウザーのコンテキストでのみ意味があります。Webブラウザーは、どのページがどの要求を行っているかを確認できますが、サーバーにはどのページがリファラーヘッダー以外のリクエストを行っているかを考えます。そのデータの整合性は保証されません。
ブラウザーがリクエストを最初に許可する理由については、ブラウザーがレスポンスを受信するまでAccess-Control-Allow-Originを評価できないためだと思います。