同一生成元ポリシーとCORS（クロスオリジンリソースシェアリング）
CORSを理解しようとしていました。私の理解によれば、それはユーザーによって開かれたもの（urlで指定されたもの）以外のドメインへのajaxリクエストを回避するためにブラウザに実装されたsecurityメカニズムです
現在、この制限により、WebサイトがOriginのクロスリクエストを実行できるように多くのCORSが実装されました。しかし、私の理解によると、CORSの実装は「同じオリジンポリシー」のセキュリティ目的に反しています[〜＃〜] sop [〜＃〜]
CORSは、要求サーバーが提供したい要求をさらに制御するためのものです。多分それはスパマーを避けることができます。
Wikipedia から：
クロスオリジンリクエストを開始するには、ブラウザがOrigin HTTPヘッダーを含むリクエストを送信します。このヘッダーの値は、ページを提供したサイトです。たとえば、 http://www.example-social-network.com 上のページがonline-personal-calendar.com内のユーザーのデータにアクセスしようとしたとします。ユーザーのブラウザがCORSを実装している場合、次のリクエストヘッダーが送信されます。
起源： http://www.example-social-network.com
Online-personal-calendar.comが要求を許可する場合、応答でAccess-Control-Allow-Originヘッダーを送信します。ヘッダーの値は、どのOriginサイトが許可されているかを示します。たとえば、前の要求への応答には次のものが含まれます。
Access-Control-Allow-Origin： http://www.example-social-network.com
サーバーがクロスオリジンリクエストを許可しない場合、ブラウザーはonline-personal-calendar.com応答ではなくexample-social-network.comページにエラーを配信します。
すべてのページへのアクセスを許可するために、サーバーは次の応答ヘッダーを送信できます。
Access-Control-Allow-Origin：*
ただし、これはセキュリティが懸念される状況には適さない場合があります。
ここで何が欠けていますか？ CORSがサーバーとクライアントを保護する目的は何ですか。
同一起源ポリシー
それはなんですか？
Same-Originポリシーは、ブラウザ間で標準化されたセキュリティ対策です。 "Origin"は主に "domain"を指します。 Cross Site Request Forgeryなどの攻撃を防ぐために、異なるオリジンが相互に作用するのを防ぎます。
CSRF攻撃はどのように機能しますか？
ブラウザを使用すると、WebサイトはクライアントのコンピュータにCookieの形式で情報を保存できます。これらのCookieには、Cookieの名前、作成時、有効期限、Cookieの設定者など、いくつかの情報が添付されています。Cookieは次のようになります。
_Cookie: cookiename=chocolate; Domain=.bakery.com; Path=/ [// ;otherDdata]_
つまり、これはチョコレートクッキーであり、 http://bakery.com とそのすべてのサブドメインからアクセスできるはずです。
このCookieには、機密データが含まれている可能性があります。この場合、そのデータは... chocolateです。ご覧のとおり、非常に敏感です。
したがって、ブラウザはこのCookieを保存します。そして、ユーザーがこのCookieにアクセスできるドメインにリクエストを出すと、そのドメインのサーバーにCookieが送信されます。幸せなサーバー。
これは良いことです。サーバーがクライアント側に情報を保存したり、クライアント側から情報を取得したりするための非常に優れた方法です。
しかし問題は、これにより http://malicious-site.com がこれらのCookieを http://bakery.com に送信できるようになることですユーザーが知らないうちに！たとえば、次のシナリオを考えます。
_# malicious-site.com/attackpage
var xhr = new XMLHttpRequest();
xhr.open('GET', 'http://bakery.com/order/new?deliveryAddress="address of malicious user"');
xhr.send();
_悪意のあるサイトにアクセスし、上記のコードが実行され、same-Originポリシーがそこにない場合、悪意のあるユーザーがあなたに代わって注文し、彼の場所で注文を取得します... 。
これは、ブラウザが http://bakery.com にチョコレートクッキーを送信したために発生しました http://bakery.com があなたは新しい注文のリクエストをしている、知っている。しかし、そうではありません。
これは、簡単に言えば、CSRF攻撃です。偽造リクエストがサイト間で行われました。 「クロスサイトリクエストフォージェリ」。そして、同じ起源の方針のおかげでそれは機能しません。
Same-Originポリシーはこれをどのように解決しますか？
これにより、malicious-site.comが他のドメインにリクエストを送信することが阻止されます。シンプル。
言い換えると、ブラウザは許可せず、どのサイトからも他のサイトへのリクエストを許可します。 AJAXのようなリクエストを通じて、異なるオリジンが相互にやり取りすることを防ぎます。
ただし、、画像、スクリプト、スタイルシート、iframe、フォーム送信などの他のホストからのリソースの読み込みには、この制限は適用されません。 CSRF Tokens を使用して、悪意のあるサイトからパン屋を保護するために別の壁が必要です。
CSRFトークン
述べたように、悪意のあるサイトは同じ起源のポリシーに違反することなく、このようなことをすることができます：
_<img src='http://bakery.com/order/new?deliveryAddress="address of malicious user"'/>
_そして、ブラウザはそのURLから画像を読み込もうとするため、そのURLへのGETリクエストですべてのCookieが送信されます。これを防ぐには、サーバー側の保護が必要です。
基本的に、適切なエントロピーのランダムな一意のトークンをユーザーのセッションに付加し、サーバーに保存し、フォームと共にクライアントに送信します。フォームが送信されると、クライアントは要求とともにそのトークンを送信し、サーバーはそのトークンが有効かどうかを確認します。
これで、悪意のあるWebサイトが再度要求を送信したので、悪意のあるWebサイトがユーザーのセッションのトークンを知るための適切な方法がないため、常に失敗します。
CORS
クロスサイトリクエストが必要な場合は、必要に応じてポリシーを回避できます。これは[〜＃〜] cors [〜＃〜]として知られています。クロスオリジンリソースシェアリング。
これは、「ドメイン」にブラウザにチルを指示し、そのようなリクエストを許可することで機能します。この「伝える」ことは、ヘッダーを渡すことで実行できます。何かのようなもの：
_Access-Control-Allow-Origin: //comma separated allowed origins list, or just *_つまり、 http://bakery.com がこのヘッダーをブラウザーに渡し、 http://bakery.com へのリクエストを作成するページがOriginリストに存在する場合、ブラウザはCookieとともに要求を許可します。
オリジンの定義に応じたルールがあります1。たとえば、同じドメインの異なるポートは同じオリジンではありません。そのため、ポートが異なる場合、ブラウザーはこの要求を拒否する可能性があります。いつものように、 親愛な Internet Explorerはこれの例外です。 IEはすべてのポートを同じように扱います。これはnon-standardおよびno otherですbrowserはこのように動作しますこれに依存しないでください。
JSONP
JSONとPaddingは、CORSがオプションではない場合に、同じ起源のポリシーを回避するための単なる方法です。これは危険であり、悪い習慣です。これは使用しないでください。
この手法に関係するのは、次のように他のサーバーに要求を出すことです。
_<script src="http://badbakery.com/jsonpurl?callback=cake"></script>_
同じ起源のポリシーはこれを防止しないので2 リクエストの場合、このリクエストのレスポンスがページに読み込まれます。
このURLは、おそらくJSONコンテンツで応答します。しかし、ページにそのJSONコンテンツを含めるだけでは役に立ちません。もちろんエラーになります。したがって、 http://badbakery.com はコールバックパラメータを受け入れ、JSONデータを変更し、コールバックパラメータに渡されたものにラップされて送信します。
戻るのではなく
_{ user: "vuln", acc: "B4D455" }_
これは無効なJavaScriptでエラーをスローし、返されます。
cake({user: "vuln", acc:"B4D455"});
これは有効なJavaScriptであり、実行され、おそらくcake関数に従ってどこかに保存されるため、ページ上の残りのJavaScriptはデータを使用できます。
これは主に、他のドメインにデータを送信するためにAPIによって使用されます。繰り返しますが、これは悪い習慣であり、リスクを伴う可能性があるため、厳密に回避する必要があります。
JSONPが悪いのはなぜですか？
まず第一に、それは非常に制限されています。リクエストが失敗した場合は、エラーを処理できません（少なくとも正気ではありません）。リクエストの再試行などはできません。
また、globalスコープにcake関数が必要ですが、これはあまり適切ではありません。異なるコールバックで複数のJSONPリクエストを実行する必要がある場合、コックがあなたを救うことができます。これは、さまざまなライブラリによる一時的な関数によって解決されますが、ハックなことをするハックな方法です。
最後に、ランダムなJavaScriptコードをDOMに挿入します。リモートサービスが安全なケーキを返すかどうかが100％わからない場合は、これを信頼することはできません。
参考文献
1. https://developer.mozilla.org/en-US/docs/Web/Security/Same-Origin_policy#Definition_of_an_Origin
2. https://www.w3.org/Security/wiki/Same_Origin_Policy#Details
その他の価値のある読み取り
http://scarybeastsecurity.blogspot.dk/2009/12/generic-cross-browser-cross-domain.html
http://tools.ietf.org/html/rfc3986 （申し訳ありません：p）
https://developer.mozilla.org/en-US/docs/Web/Security/Same-Origin_policy
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_（CSRF）
同一生成元ポリシー（SOP）は、クロスサイトスクリプティング（XSS）を介して脆弱性を防止するためにブラウザーが実装するポリシーです。サーバーが認証、Cookie、セッションなどを処理できる場合が多いため、これは主にサーバーを保護するためです。
Cross Origin Resource Sharing（CORS）は、SOPを緩和するための数少ないテクニックの1つです。 SOPはデフォルトで「オン」であるため、サーバー側でCORSを設定すると、リクエストが別のドメインから送信された場合でも、XMLHttpRequestを介してサーバーにリクエストを送信できます。これはサーバーが他のドメインからのリクエストを処理することを目的とした場合（たとえば、APIを提供している場合）は役立ちます。
これにより、SOPとCORSの違いとそれぞれの目的が明らかになることを願っています。