CORSはとにかくクロスサイトフォージェリに反対していますか？
CORSについてここ数日読んでいますが、それはクロスドメインの偽造から世界を助ける「セキュリティ」機能であるため、多くの場所で言及されています。
CORSの利点と理由はまだわかりません。ブラウザーはプリフライトリクエストを行い、サーバーはオリジンを検証します。しかし、攻撃者は任意のヘッダー（元）を使用してHttpRequestのトップボトムを簡単に作成でき、リソースにアクセスできます。
CORSはどのように役立ち、どのような利点がありますか？
多くの人々が Same Origin Policy と誤解している [〜＃〜] cors [〜＃〜] がテーブルにもたらすものを誤解していると言って、私の答えを始めます。
すでにここで投票されている回答の一部は、同一生成元ポリシーがクロスサイト要求を防ぎ、したがって [〜＃〜] csrf [〜＃〜] を防ぐと述べています。これはそうではありません。すべてのSOPは、応答が別のドメイン（別名Origin）によって読み取られるのを防ぎます。これは、CSRF攻撃が成功したかどうかとは無関係です。
SOPがCSRFに関係するのは、トークンが別のドメインに読み取られるのを防ぐためだけです。
すべてのCORSは、SOPがアクティブな場合にリラックスします。セキュリティを向上させるのではなく、単にいくつかの例外が発生することを許可します。一部の 部分的なCORSをサポートするブラウザ 許可クロスサイトXHRリクエスト（例IE 10およびそれ以前）ですが、カスタムヘッダーを追加することはできません。CORSがサポートされているブラウザーでは、Originヘッダーを設定できないため、攻撃者がこれを偽装すること。
私はドメインが異なる起源であると述べました。 AJAXリクエスト（Cookieではそれほどではない））について話すとき、ポートとプロトコルによってオリジンが異なる場合もあります。
最後に、上記のすべては、たとえばcurlのように、攻撃者から直接送信される偽造リクエストとは関係ありません。攻撃者は攻撃のために被害者のブラウザを使用する必要があることを覚えておいてください。 Cookieを自動的に送信するには、ブラウザが必要です。これは、このタイプの攻撃シナリオ（「クライアント側の攻撃」と呼ばれるカテゴリ）で攻撃者を認証するだけなので、直接のカールリクエストでは実現できません。
CORSの利点は、ドメインが別の信頼できるドメインからの読み取りを許可できることです。したがって、http://data.example.org応答ヘッダーを設定してhttp://site.example.com AJAXリクエストを作成し、APIからデータを取得します。
あなたは物事を混同している。 CORSは、巧妙に細工されたhttpリクエストからアプリケーションを保護するためのものではありません、リソースにアクセスできるサイトを確認することにより、ユーザーのCookieまたはアクセストークンを「盗む」特定の種類の攻撃からユーザーを保護するためのものです。
これは主に、サーバー/アプリケーションをクロスサイトリクエストフォージェリから保護するために使用されます。悪意のあるサイトは、ユーザーに代わってリクエストを実行します。悪意のあるインテント（認証情報の変更、送金など）を使用して、ブラウザは、ログインおよびセッションCookieを送信し、サイトで有効かつ有効です。
CORSが正しく構成されている場合、攻撃者のサイトのajaxリクエストは拒否されます。デフォルトでは、同じサイトからのリクエストのみを受け入れるためです。
これは、入力をサニタイズしてはならないという意味ではありません、そして特定のタイプのCSFR攻撃からのみ保護します。攻撃者がユーザーのCookie /アクセストークンを取得した場合でも、とにかくアクセスが許可されます。そのため、追加の保護レイヤーとしてほとんどの認証プロセスでSSLを使用する必要がありますです。
PS：これは、ユーザーが使用しているブラウザーが最新であり、欠陥がなく、同じOriginポリシーに従っていることを前提としています。
編集：プリフライトリクエストに関しては、これはサイトにアクセスが許可されていることを確認するための追加の手段であり、すべてのクロスオリジンリクエストに対して行われるわけではありません
これらすべてを次のように要約することには意味がありますか？
SOP（Single Origin Policy）攻撃者がPOSTする必要があるため、CSRF攻撃が最新のブラウザから行われないようにしますwithin最新のブラウザ別のドメインから。
CSRF（Cross-Site Request Forgery）トークンは、危険なPOSTリクエストが実行されないようにしますoutside ofブラウザ（ここでSOPは適用されません（例：
curl）を使用）。共有ブラウザーエクスペリエンス以外では、ユーザーCookieの認証データにアクセスできないためです。CORS（Cross-Origin Resource Sharing）は、ブラウザに対するSOPの制限を緩和するために使用できますが、リソースサーバーがCORSヘッダーを介して許可する場合のみです。したがって、誤って使用すると、実際にセキュリティが低下する可能性があります。
CORSについてここ数日読んでいますが、クロスドメインの偽造から世界を助ける「セキュリティ」機能であるため、多くの場所で言及されています。
CORSの利点を誤解しているか、またはamateurを心配している開発者が作成したブログそれを機能させる方法安全にする方法（私が何を意味するか理解している場合）、なぜならCORSはWebアプリケーションをそのような攻撃に対して脆弱にするからです（ [〜＃〜] csrf [〜＃〜] ）次のヘッダーを持つCORSを使用して、攻撃者のオリジンからのクロスオリジンリクエストを開く場合：Access-Control-Allow-Origin: *
CORSはどのように役立ち、どのような利点がありますか？
CORSは、 [〜＃〜] sop [〜＃〜] の制限を緩和するために生まれましたtrustedリクエストのみ。しかし、問題はまさにtrustから始まります。攻撃者は、GETおよびPOSTメソッドなどを通じて悪意のあるリクエストを偽造することにより、 origins を通じて危害を加える可能性があり、さらに DNS再バインド
この部分は、
ブラウザーはプリフライト要求を行います/サーバーはオリジンを検証します。しかし、攻撃者は任意のヘッダー（元）を使用してHttpRequestのトップボトムを簡単に作成でき、リソースにアクセスできます。
https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS から
さらに、ユーザーデータに副作用を引き起こす可能性があるHTTPリクエストメソッド（特に、GET以外のHTTPメソッド、またはPOST特定のMIMEタイプでの使用）の場合、仕様ではブラウザにHTTP OPTIONSリクエストメソッドを使用してサーバーからサポートされているメソッドを要求し、サーバーから「承認」されると、実際のリクエストを実際のHTTPリクエストメソッドで送信します。サーバーは、クライアントに「資格情報」を通知することもできます。 （CookieとHTTP認証データを含む）はリクエストとともに送信する必要があります。
私が知っている限り、POST 'の代わりに--- [HTTPメソッド' PUT 'を使用すると、指定されたメソッドとして' PUT 'を使用してクロスドメインリクエストを行うと、常に前にオリジンが許可されているかどうかを確認する飛行前のリクエストチェックにより、特定の状況での攻撃を防ぐことができます。これは、攻撃者がOriginを最新のブラウザとして偽装することができないためです許可しない Javascriptなどのクライアント側スクリプト言語'Origin'またはカスタムヘッダーを設定する =クロスドメイン、攻撃は失敗します。
お役に立てば幸いです。
はい、それは助けになっていますが、実際には仕様ではありません。
CORSはCross-Origin Resource-Sharingの略です。これは実際にはセキュリティを目的としたものではありません。 CORSは fetch API に組み込まれているため、JavaScriptでのみ役立ちます（詳細は後で説明します）。デフォルトでは、単一オリジンポリシー（SOP）のため、fetch()は同じオリジンにないものを取得できません。 CORSは、どのotherオリジンがリソースへのアクセスを許可されているかを示すことで、それを緩和します。また、XMLHttpRequestも同じように動作します。
したがって、はいresourceが別のOriginからアクセスされるため、クロスサイトスクリプティング（XSS）をブロックするのに役立ちます。そして技術的には、サーバーはリクエストをブロックしていません。 Access-Control-Allow-Originヘッダーを尊重してリクエストを通過させないのはブラウザです。
しかし、それはJavaScriptの場合のみです。ブラウザは Simple Requests にCORSを使用しません。
つまり、単純なGETリクエスト（偽の画像など）はCORSによって停止されません。また、JavaScript（つまり、フォーム）で実行されないPOSTリクエストは、CORSをトリガーしません。あなたはまだそれに対する保護が必要です。セキュリティは最も弱いリンクと同じぐらい強力であり、いったん開始すると、CSRFをサーバーレベルでから防止できますシンプルリクエスト、あなたのCORSは本当に必要ではない追加のレイヤーであることに気付くでしょうが、それでもいいです。