Cookieがあるため、Webの同じOriginポリシーは役に立ちますか？

Question

ブラウザに同じOriginポリシーがあり、それを保証します。悪いサイトはFacebookからあなたのデータを読みません。しかし、解決しようとしている唯一の問題は、ユーザーを認証する要求とともにCookieが自動的に送信されることです（+おそらく基本認証や証明書などの他の認証スキーム）。

だから私の質問は：ブラウザがこのリクエストですべてのhttp認証詳細とCookieを自動的に送信しない場合、本当にこのポリシーが必要なのでしょうか？

多分最善の方法は、デフォルトでクロスオリジンを許可することですが、この情報（cookie、http auth）が転送されないことを確認してください。いずれの場合も、トークンベースのAPIを生成できます。クロスサイトリクエストが必要な場合など。また、3Dパーティの呼び出し元は、CORSが不要になるように同じ方法でトークンを取得する必要があります。

SilverlightFox · Accepted Answer

いいえ、同一生成元ポリシーは以下に対しても保護します。

DOMでのクロスドメイン操作（IFrameにロードされた別のOriginからの別のページを操作するページなど）。
AJAXリクエストからの応答は、オリジンが一致しない場合に読み取られます。
他のオリジンからロードされた画像は、HTML5キャンバスに読み込まれません。

だから私の質問は：ブラウザがこのリクエストですべてのhttp認証詳細とCookieを自動的に送信しない場合、本当にこのポリシーが必要なのでしょうか？

はい、上記の理由で必要です。

couldはそのように機能しますが、下位互換性の理由から現在は機能していません。それは、世界のウェブのほとんどが基づいている標準を突然変える多くのことを壊します。

いずれにしても、ウィンドウ全体がリダイレクトされた場合はどうなりますか？例えばGETメソッドを使用して [〜＃〜] csrf [〜＃〜] を介して悪用される可能性のある機密機能がある場合、攻撃者はページ全体をhttps://example.com/delete_users攻撃を実行するため。

ブラウザーは、そのような状況でCookieを送信しないことをどのように知っていますか？あなたが達成する唯一のことはルールをより複雑にすることであるように見えます、そして複雑さはセキュリティの敵です。

sleske · Answer

SilverlightFoxの優れた答えに追加するには：

ifブラウザーがクロスドメインリクエストでHTTP AuthヘッダーとCookieを送信しなかったとしても（これに依存するページが多すぎるため、実用的ではありません）、クロスドメインリクエストは依然として危険です、リクエストは認証ヘッダーなしでもプライベート情報を返す可能性があるため。

基本的に、問題は、クライアントブラウザが他の認証メカニズムを使用してプライベートリソースにアクセスできることです。例えば：

ブラウザーがファイアウォールの背後にあるプライベートネットワーク内にある場合、プライベートネットワークからは自由にアクセスできるが、外部からはアクセスできないプライベートリソースがある可能性があります。
リソースがクライアントのIPアドレスまたはMACアドレスに基づいてアクセスを承認した場合、ブラウザが実行されているクライアントコンピュータが原因で、ブラウザがアクセスできる可能性があります。

このような状況では、特定のHTTPヘッダーを削除するだけでは不十分です。

余談ですが、特定のリクエストに対して意図的にCookieを送信しないという考えは、 SameSite cookies で実装されています。 SameSite Cookieはクロスドメインリクエストでは送信されません。

前述の下位互換性の問題を回避するために、SameSite Cookieは「オプトイン」です。SameSiteCookieを作成するには、サーバーはCookieを設定するときにSameSiteを指定する必要があります。この属性なしで設定されたCookieは引き続きクロスドメインリクエストに送信されるため、Same-Originポリシーは引き続き重要です。