同じOriginポリシーがなぜそれほど重要なのですか？
同じオリジンドメインの意味が完全に理解できません。別のドメイン（JSファイルなど）からリソースを取得する場合、リソースを提供するドメインのコンテキスト（Google Analyticsコードなど）から実行されるため、データを変更したり、データを読み取ったりすることはできません。 「リソースを含む」ドメイン。
したがって、ドメインa.comがgoogle.comのjsファイルをソースに埋め込んでいる場合、そのjsは実行されますfromgoogle.comであり、DOM\cookiesにアクセスできません\ a.comのその他の要素-私は正しいですか？
これは私が本当に理解できない同じオリジンポリシーの定義です：
Same-Originポリシーは、ブラウザ内に実装される主要なメカニズムであり、異なる発信元からのコンテンツが互いに干渉しないように設計されています。基本的に、1つのWebサイトから受信したコンテンツは、同じサイトから受信した他のコンテンツの読み取りと変更は許可されますが、他のサイトから受信したコンテンツへのアクセスは許可されません。
それはどういう意味ですか？実例を教えてもらえますか？
もう1つの質問は、Originヘッダーの目的と、クロスドメインリクエストがどのようにまだ存在するのかということです。セキュリティまたは同じOriginポリシーに影響を与えないのはなぜですか？
同じOriginポリシーが重要なのはなぜですか？
Facebookにログインし、別のブラウザタブで悪意のあるWebサイトにアクセスするとします。同じOriginポリシーがないと、そのWebサイトのJavaScriptはFacebookアカウントに対して許可されていることを何でも実行できる可能性があります。たとえば、プライベートメッセージを読んだり、ステータスの更新を投稿したり、フォームを送信する前にパスワードを入力した後のHTML DOMツリーを分析したりします。
しかしもちろん、FacebookはJavaScriptを使用してユーザーエクスペリエンスを強化したいと考えています。したがって、ブラウザがこのJavaScriptがFacebookリソースへのアクセスを信頼できることを検出できることが重要です。そこで、同じOriginポリシーが機能します。facebook.comのHTMLページからJavaScriptが含まれている場合、それはfacebook.comリソースにアクセスする可能性があります。
Facebookをオンラインバンキングのウェブサイトに置き換えます。これが問題であることは明らかです。
起源は何ですか？
同じOriginドメインの意味を完全に理解することはできません。別のドメイン（JSファイルなど）からリソースを取得する場合、リソースを提供するドメインのコンテキスト（Googleアナリティクスコードなど）から実行されるため、データを変更したり、データを読み取ったりすることはできません。 「リソースを含む」ドメイン。
これは不正解です。JavaScriptファイルのオリジンは、それを含むHTMLページのドメインによって定義されています。したがって、<script>タグを使用してGoogle Analyticsコードを含めると、Webサイトに対して何でも実行できますが、Google Webサイトに対する同じOrigin権限がありません。
ドメイン間通信はどのように機能しますか？
同じOriginポリシーがすべてのリクエストに適用されるわけではありません。とりわけ、<script>-および<img>-タグは、任意のドメインからリソースをフェッチします。フォームの投稿や他のドメインへのリンクも可能です。フレームとiframeは他のドメインからの情報を表示しますが、そのコンテンツとの相互作用は制限されています。
安全な方法で他のドメインへのXMLHttpRequest（ajax）呼び出しを許可する方法はいくつかありますが、一般的なブラウザでは十分にサポートされていません。別のドメインとの通信を有効にする一般的な方法は [〜＃〜] jsonp [〜＃〜] です。
<script>タグに基づいています。別のドメインに送信される情報は、パラメーターとしてURLにエンコードされます。返されるJavaScriptは、要求された情報をパラメーターとして持つ関数呼び出しで構成されています。
<script type="text/javascript" src="http://example.com/
?some-variable=some-data&jsonp=parseResponse">
</script>
Example.comから動的に生成されたJavaScriptは次のようになります。
parseResponse({"variable": "value", "variable2": "value2"})
クロスサイトスクリプティングとは何ですか？
クロスサイトスクリプティング は脆弱性で、攻撃者がWebサイトにJavaScriptコードを挿入できるようにして、攻撃から発信されますブラウザの観点からウェブサイト。
これは、ユーザー入力が十分に無害化されていない場合に発生します。たとえば、検索関数は文字列「[userinput]の検索結果」を表示します。 [userinput]がエスケープされていない場合、攻撃者は次のものを検索する可能性があります。
<script>alert(document.cookie)</script>
ブラウザは、このコードがWebサイトの所有者から提供されたものではないことを検出する方法がないため、コードを実行します。現在、クロスサイトスクリプティングが大きな問題となっているため、この脆弱性を防ぐための作業が行われています。最も注目に値するのは コンテンツセキュリティポリシー アプローチです。
それはどういう意味ですか？実例を教えてもらえますか？
攻撃例1：HTMLフォームを使用したクロスサイトリクエストフォージェリ（CSRF）
evil.comのページで、攻撃者は次のように記述しています。
<form method="post" action="http://bank.com/trasfer">
<input type="hidden" name="to" value="ciro">
<input type="hidden" name="ammount" value="100000000">
<input type="submit" value="CLICK TO CLAIM YOUR PRIZE!!!">
</form>
これ以上のセキュリティ対策がなければ、これは：
- リクエストは送信されます。 SOPは、このリクエストの送信を禁止していません。
- ログインする
bank.comからの認証Cookieが含まれています
これはシンクロナイザートークンパターンであり、SOPがなくても、これは機能しません。
シンクロナイザトークンパターン
bank.comのすべてのフォームについて、開発者は非表示パラメーターとして1回限りのランダムシーケンスを生成し、サーバーがパラメーターを取得した場合にのみ要求を受け入れます。
たとえば、RailsのHTMLヘルパーはauthenticity_tokenパラメータをHTMLに自動的に追加するため、正当なフォームは次のようになります。
<form action="http://bank.com/transfer" method="post">
<p><input type="hidden" name="authenticity_token"
value="j/DcoJ2VZvr7vdf8CHKsvjdlDbmiizaOb5B8DMALg6s=" ></p>
<p><input type="hidden" name="to" value="ciro"></p>
<p><input type="hidden" name="ammount" value="100000000"></p>
<p><button type="submit">Send 100000000$ to Ciro.</button></p>
</form>
したがって、evil.comが単一のポスト要求を行う場合、彼はそのトークンを推測することはなく、サーバーはトランザクションを拒否します。
参照： OWASPのシンクロナイザトークンパターン 。
攻撃例2：JavaScript AJAXを使用したクロスサイトリクエストフォージェリ（CSRF）
しかし、正当なブラウザと同じように、evil.comがJavaScriptで2つのリクエストを行うことを妨げているものは何ですか。
- トークンのXHR GET
- XHR POST良いトークンを含む
そのため、evil.comは次のようなものを試します（レイジーなためjQuery）：
$.get('http://bank.com/transfer')
// Parse HTML reply and extract token.
$.post('http://bank.com/transfer', {
to: 'ciro',
ammount: '100000000',
authenticity_token: extracted_token
})
ThisはSOPが関係する場所です。$.getと$.postは実際にはHTMLフォームと同じように認証済みリクエストを送信しますが、リクエストが別のドメインに送信されたため、送信者のブラウザはJavaScriptコードがHTML返信を読み取らないようにします。
Chromium開発者コンソールには、次のタイプのエラーが表示されます。
Origin ' http://evil.com 'から ' http://bank.com 'のXMLHttpRequestへのアクセスがCORSポリシーによってブロックされました：いいえ 'Access-Control -Allow-Origin 'ヘッダーがリクエストされたリソースに存在します。
クロスリクエストCookieを送信しないのはなぜですか？
実装に「リクエストは許可するが、現在のドメインXHRでのみCookieを送信する」のようなルールがある場合はどうなりますか？それはもっと簡単ではないでしょうか？
しかし、それでも別の種類の攻撃が可能になります。認証がCookieではなく、要求のソース（IP）に基づいている場合です。
たとえば、会社のイントラネットにいて、そこから内部サーバーにアクセスできます。内部サーバーは、外部からは見えず、秘密のデータを提供します。
クロスオリジンリクエストはすべて禁止されていますか？
CORSを忘れてもno、私たちは毎日それらを行います！
From [〜＃〜] mdn [〜＃〜] ：
クロスオリジンの書き込みは通常許可されています：リンク、リダイレクト、フォーム送信。
[私のコメント]：たとえば、リンクをクリックすると、Webサイトにログインすることがよくありました。そのためには、新しいページを返す認証されたGETリクエストを行う必要があります。
通常、クロスオリジン埋め込みが許可されています：画像、外部CSSおよびJavascript、iframe。
通常、クロスオリジン読み取りは許可されていません：XHR（上記の例）、
iframe読み取り。ただし、埋め込みによって読み取りアクセスがリークすることがよくあります。たとえば、埋め込み画像の幅と高さ、埋め込みスクリプトのアクション、または 埋め込みリソースの可用性 を読み取ることができます（したがって、特定のユーザーがログインしているかどうか）ドメイン）
特に、認証済みのPOST evil.comへのリクエストを作成するbank.comのフォームを使用することが可能です。これがSOP単独では不十分です。シンクロナイザトークンも必要です。
参照： OSWAPでのCSRF 。
その他の防止策
- 特定のヘッダーが存在するかどうかを確認します。
X-Requested-With： Originヘッダーの値を確認します。 CSRFを防ぐために、Originヘッダーの確認よりもシンクロナイザートークンパターンが推奨される理由- 再認証：ユーザーにもう一度パスワードを要求します。これは、サイトがXSSされた場合に備えて、すべての重要な操作（銀行ログインと送金、ほとんどのWebサイトでのパスワード変更）に対して行う必要があります。欠点は、ユーザーがパスワードを複数回入力する必要があることです。これは面倒で、キーロギング/ショルダーサーフィンの可能性が高くなります。
心配しないで。頭を包むのも難しいです。
理論的には、Google Analyticsは理論的には、ユーザーに対してユーザーがやりたいことをすべて実行できることがわかります。 （<script>タグ 例外を作成 から同じオリジンポリシー制限へ）
これが最大の理由の1つです [〜＃〜] xss [〜＃〜] 攻撃はBad Thing™であり、Mozillaが設計した1つの理由 コンテンツセキュリティポリシー 現在の /途中 になる standardized （WebKitのHTML5 iframe sandbox 属性の実装も役立ちます）
下位互換性を損なうことを回避できなかったため、同じ起源のポリシーは、<iframe>やXMLHttpRequestなどを、「Remember Me」Cookieや横になっているログインダイアログを使用してアカウントにアクセスするなどのトリックを防ぐことを目的としています。 （ X-Frame-Options ヘッダーを使用すると、 Clickjacking 。）
Originヘッダーは、「クロスオリジンリソースシェアリング」という名前のメカニズムによって使用されます。これにより、サイトは同じオリジンポリシーに制限付きの例外を付与して、安全なクロスサイトインタラクションを実現できます。 （OperaとInternet Explorerを除く all current browsers で完全にサポートされ、IE8 +では、Cookieを省略した独自のXDomainRequestオブジェクトを使用して部分的にサポートされます）
基本的に、XMLHttpRequestを別のドメインにしようとすると、ブラウザは 次の2つのことを行います ：
特定の制限を満たす標準の
GETまたはPOSTリクエストの場合（標準の作成者は、 [〜＃〜] csrf [〜＃〜] 攻撃）その後、ブラウザはリクエストをそのまま通過させます。それ以外の場合は、「プリフライトリクエスト」と呼ばれる処理を実行します。最初に代わりに
OPTIONSリクエストを送信し、OPTIONSリクエストのチェックに合格した場合にのみ、リクエストした処理を実行します。
どちらの場合でも、ブラウザはOriginヘッダーを追加して、呼び出しているターゲットサイトを通知します。 （これはRefererヘッダーに似ていますが、適切なセキュリティを確保するために必須であり、より厳密に指定されています）
受信側のサーバー（保護のために同じ元のポリシーに大きく依存しているサーバー）は、Access-Control-Allow-Originまたは_ [リクエストのOriginの値のいずれかを含む*ヘッダーを含めることにより、リクエストを承認できます。ヘッダ。
そうでない場合、ブラウザは単に応答を破棄し、Javascriptコールバックにエラーを返します。 MDNは、両方のシナリオの内部で何が起こっているかについて、次のように詳しく説明します （1）（2） さらに、制御された方法でセキュリティをさらに緩和するためにターゲットシステムが設定できるその他のヘッダー。 （例：設定しているカスタムHTTPヘッダーへのアクセスを許可する）
GETリクエストとPOSTリクエストの許可されたサブセットは、ターゲットWebアプリが適切に保護されていない限り、他のメカニズムを介してCSRF攻撃にすでに使用できます。そのため、 Google Font Library。
実際、この場合、Origin of Google分析スクリプトはa.comです。
JavaScriptからの引用：The Definitive Guide ：
スクリプト自体のオリジンは同一オリジンポリシーには関係がないことを理解することが重要です。重要なのは、スクリプトが埋め込まれているドキュメントのオリジンです。