CORSは、クロスドメインAJAXリクエストを行う安全な方法ですか？
CORS（Cross-Origin Resource Sharing）について読んだ後、セキュリティがどのように改善されるかわかりません。クロスドメインAJAX正しいOriginヘッダーが送信された場合、通信が許可されます。
サーバーは、このドメインがホワイトリストに含まれているかどうかを確認し、含まれている場合はヘッダーを確認します。
Access-Control-Allow-Origin：[ここでURLを受け取りました]
応答とともに返送されます（これは単純なケースです。事前にファイトされたリクエストもありますが、質問は同じです）。
これは本当に安全ですか？誰かが情報を受け取りたい場合、Originヘッダーを偽造することは本当に簡単なタスクのように思えます。また、標準ではブラウザでポリシーが適用され、Access-Control-Allow-Originが正しくない場合は応答がブロックされるとされています。明らかに、誰かがその情報を取得しようとしている場合、彼は標準のブラウザを使用してそれをブロックしません。
ユーザーがデータを取得するのを止めるようには設計されていません。人々がそれを入手せずに公開することはできません。
次のように設計されています。
- Alice、Ajax経由でアクセスするように設計されたAPIを提供する人
- ボブ、ウェブブラウザを持っている人
- チャーリー、独自のウェブサイトを運営する第三者
BobがCharlieのWebサイトにアクセスすると、CharlieはJSをBobのブラウザーに送信できず、AliceのWebサイトからデータをフェッチしてCharlieに送信します。
上記の状況は、ボブがアリスのウェブサイトにコメントを投稿したり、データを削除したりすることができるユーザーアカウントを持っている場合、より重要になります。
許可されていない人がデータを見るのを防ぎたい場合は、パスワード、SSLクライアント証明書、またはIDベースの認証/許可のその他の手段で保護する必要があります。
目的はこれを防ぐことです-
- ウェブサイトXにアクセスします
- WebサイトXの作成者は、ブラウザに送信される悪質なスクリプトを作成しました
- ブラウザで実行されているスクリプトは銀行のWebサイトにログオンし、悪事を行います。ブラウザでas yoが実行されているため、許可があります。
考えは、銀行のWebサイトは、WebサイトXのスクリプトが銀行のページにアクセスするために信頼されるべきかどうかをブラウザに伝える何らかの方法を必要とするということです。
@jcoderの答えに追加するために、Originヘッダーの要点は、サーバーで要求されたリソースを保護することではありません。そのタスクは、攻撃者が実際、適切なツールを使用してこのヘッダーを偽装することができます。
Originヘッダーのポイントは、ユーザーを保護することです。シナリオは次のとおりです。
攻撃者が悪意のあるWebサイトMを作成する
ユーザーAliceは、実際にCORSをサポートするサーバーBでCORSを介していくつかのアクションを実行しようとするスクリプトを含むMに接続するようにだまされます
Bはおそらく
Access-Control-Allow-OriginヘッダーにMを持たないでしょう。なぜそうなるのでしょうか？重要な点は、Mが
Originヘッダーをスプーフィングまたは上書きする手段がないため、リクエストがAliceのブラウザーによって開始されることです。そのため、彼女のブラウザは（正しい）OriginをMに設定しますが、これはBのAccess-Control-Allow-Originにないため、リクエストは失敗します。
今、アリスはOriginヘッダーを自分で変更できますが、なぜ彼女は自分に危害を加えているのでしょうか？
TL; DR：Originヘッダーは、無実のユーザーを保護します。リソースを保護しません。攻撃者は自分のマシンでなりすましが可能ですが、自分の制御下にないマシンではなりすましはできません。
一致するOriginヘッダーは許可されたアクセスを意味しないため、サーバーは引き続きリソースを保護する必要があります。ただし、一致しないOriginヘッダーは、不正アクセスを意味します。
同じOriginポリシーの目的は、一般にWebサイトのコンテンツへのアクセスを阻止することではありません。誰かがそれをしたいなら、ブラウザさえ必要としません。ポイントは、必要なアクセス権なしで別のドメインのコンテンツへのアクセスを停止クライアントスクリプトすることです。 Same Origin Policy のウィキペディアのエントリを参照してください。
CORSについて読んだ後、どのようにセキュリティが改善されるのかわかりません。
CORSはセキュリティを改善しません。 CORSは、外部ドメインがブラウザにアクセスする方法をサーバーに伝えるメカニズムをサーバーに提供し、CORS以前に存在していたブラウザーのセキュリティモデルと一致する方法でアクセスを試みます（つまり、 同じオリジンポリシー ）。
ただし、同一生成元ポリシーとCORSの範囲は限られています。具体的には、 CORS仕様 自体にはリクエストを拒否するメカニズムがありません。ヘッダーを使用して、外部ドメインのページが応答を読み取らないようにブラウザーに指示できます。また、プリフライトリクエストの場合、外部ドメインから特定のリクエストを送信しないようブラウザに要求できます。ただし、CORSは、サーバーが実際の要求を拒否する（つまり、実行しない）手段を指定していません。
例を見てみましょう。ユーザーはCookieを介してサイトAにログインしています。ユーザーが悪意のあるサイトMをロードし、POSTをAに送信するフォームを送信しようとします。何が起こるか？ CORSの有無にかかわらず、Mが許可ドメインであるかどうかにかかわらず、ブラウザはユーザーの認証Cookieを使用してAにリクエストを送信し、サーバーは悪意のあるPOSTユーザーが開始したかのように。
この攻撃は Cross-Site Request Forgery と呼ばれ、CORS自体はそれを軽減するために何もしません。そのため、ユーザーに代わってデータの変更要求を許可する場合、CSRF保護は非常に重要です。
現在、Originヘッダーの使用はCSRF保護の重要な部分になります。実際、それをチェックすることは 多面的なCSRF防御の現在の推奨事項 の一部です。ただし、Originヘッダーの使用はCORS仕様の範囲外です。
要するに、CORSは既存の同一生成元ポリシーセキュリティモデルを他の承認済みドメインに拡張するための便利な仕様です。セキュリティを追加するものではなく、サイトにはCORS以前と同じ種類の防御メカニズムが必要です。
私は答えるのが遅れていますが、ここの投稿が本当に求められている答えを提供しているとは思いません。最大のポイントは、ブラウザーがOriginヘッダー値を書き込むエージェントであることです。邪悪なスクリプトは、Originヘッダー値を書き込むことができません。サーバーがAccess-Control-Allow-Originヘッダーで応答すると、ブラウザーはこのヘッダーに以前に送信されたOrigin値が含まれていることを確認しようとします。そうでない場合、エラーをトリガーし、要求元のスクリプトに値を返しません。この質問に対する他の回答は、悪のスクリプトへの回答を拒否したい場合の良いシナリオを示しています。
@daniel fは質問に対する良い答えも提供します