悪意のあるコードがCORSを悪用するために「Origin」ヘッダーを偽装するのを防ぐにはどうすればよいですか？

私が理解している方法では、foo.comのページで実行されているクライアント側のスクリプトがbar.comのデータをリクエストする場合、リクエストでヘッダーを指定し、Origin: http://foo.comバーがで応答する必要がありますAccess-Control-Allow-Origin: http://foo.com。

サイトroh.comからの悪意のあるコードがヘッダーOrigin: http://foo.comを偽装してバーからページを要求するのを防ぐ方法は何ですか？

ブラウザはOriginヘッダーの設定を制御しており、ユーザーはこの値を上書きできません。そのOriginため、ブラウザから偽装されたヘッダーは表示されません。悪意のあるユーザーがOriginヘッダーを手動で設定するcurlリクエストを作成する可能性がありますが、このリクエストはブラウザーの外部から送信され、ブラウザー固有の情報（Cookieなど）を持たない可能性があります。

注意：CORSはセキュリティではありません。CORSに依存してサイトを保護しないでください。保護されたデータを提供する場合は、Cookie、OAuthトークン、またはOriginヘッダー以外のものを使用して、そのデータを保護します。Access-Control-Allow-OriginCORS のヘッダーは、どのオリジンがクロスオリジンリクエストを作成できるようにするかを指示するだけです。それ以上これに依存しないでください。

TLDR：悪意のあるコードがオリジンを偽装するのを妨げるものは何もありません。それが発生すると、サーバーはそれを知ることはなく、リクエストに応じて動作します。時々それらの要求は高価です。したがって、セキュリティの種類の代わりにCORSを使用しないでください。

最近CORSをいじってみましたが、私も同じ質問をしました。私が見つけたのは、ブラウザーはスプーフィングされたCORS要求を認識するのに十分なほどスマートである可能性があることですが、サーバーはそれほどスマートではありません。

最初に見つけたのは、Originヘッダーがプログラムで変更できないHTTP 禁止ヘッダー名であることです。つまり、Google Chromeのヘッダーの変更を使用すると、約8秒で変更できます。

これをテストするために、2つのクライアントドメインと1つのサーバードメインを設定しました。サーバーにCORSホワイトリストを含めました。これにより、クライアント1からのCORSリクエストは許可されましたが、クライアント2からのCORSリクエストは許可されませんでした。両方のクライアントをテストしました。実際、クライアント2が失敗してもクライアント1のCORSリクエストは成功しました。

次に、Originクライアント1と一致するようにクライアント2のヘッダーを偽装しました。サーバーはスプーフィングされたOriginヘッダーを受信し、ホワイトリストチェックに合格しました（または、半分が空の人の場合は失敗しました）。その後、サーバーは、サーバーが消費するように設計されたすべてのリソース（データベース呼び出し、高価な電子メールの送信、さらに高価なSMSメッセージの送信など）を消費することにより、忠実に機能しました。これが完了すると、サーバーはスプーフィングされたAccess-Control-Allow-Originヘッダーをブラウザーに送信しました。

私が読んだドキュメントでは、Access-Control-Allow-Origin受け取ったOrigin値はリクエストで送信された値と正確に一致する必要があると述べています。それらは一致したので、Chromeで次のメッセージを見て驚いた：

XMLHttpRequestを読み込めませんhttp://server.dev/test。'Access-Control-Allow-Origin'ヘッダーの値http://client1.dev が、指定された起点と等しくありません。http://client2.dev したがって、Origin はアクセスを許可されません。

私が読んだドキュメントは正確ではないようです。Chromeのネットワークタブには、リクエストヘッダーとレスポンスヘッダーの両方が明確に表示されhttp://client1.devますが、エラーでChromeが実際の発信元が何であるかを認識しておりhttp://client2.dev、応答を正しく拒否していることがわかります。サーバーはすでにスプーフィングされたリクエストを受け入れており、私のお金を費やしていたので、現時点ではどちらでもかまいません。

控えめにまとめます。

Q：同一生成元ポリシー（SOP）はブラウザーによってのみ強制されますか？
A：はい。ブラウザ内で行うすべての呼び出しについて、SOPは確実にブラウザによって適用されます。サーバーは、要求の発信元をチェックする場合としない場合があります。

Q：リクエストがSOPに準拠していない場合、ブラウザーはそれをブロックしますか？
A：いいえ、ブラウザの権限を超えています。ブラウザは、クロスオリジンリクエストを送信し、その応答がAccess-Control-*ヘッダーを介してサーバーによって正当な信号であるかどうかを確認するまで待機します。サーバーがAccess-Control-Allow-Originヘッダーを返さない、呼び出し元の起点をエコーバックしない、または*ヘッダーを返さない場合、ブラウザーが行うすべてのことは、呼び出し元への応答の提供を控えることです。

Q：なりすましできないということOriginですか？
A：ブラウザでスクリプトを使用Originすると、ブラウザの制御下にあるため、オーバーライドできません。ただし、自分でハッキングしたい場合は、ブラウザ拡張機能やマシンにインストールしたその他のツールを使用して、ブラウザからの呼び出しを改ざんできます。また、発行することができますHTTP使用して呼び出しをcurl、Python、C#、などと変更Originトリックサーバーにヘッダーを。

Q：を変更Originしてサーバーをだますことができる場合、それCORSは安全ではないということですか？
A： CORSセキュリティ自体については、それ自体は黙っています。つまり、リクエストの認証と承認です。リクエストを検査し、Cookieやヘッダーなどのメカニズムを使用して認証/承認するのはサーバー次第です。そうは言っても、XSSのような攻撃が発生した場合には、もう少し保護することができます。

例： Webサイトにログインしていて、悪意のあるスクリプトが銀行のWebサイトに残高を照会するリクエストを送信しようとしているとしましょう：反射XSS攻撃。銀行のWebサイトは、Webサイトから（ここでは）提供される資格情報を信頼するため、リクエストが認証さHTTPれ、悪意のあるコードを狙った応答が発行されます。銀行のウェブサイトが他のオリジンとのエンドポイントの共有を気にしない場合、それは含まれていませんAccess-Control-Allow-Origin応答のヘッダー。これで、リクエストが到着すると、ブラウザーはリクエストがCross Originsリクエストであることを認識しますが、サーバーがリソース（ここではバランスクエリエンドポイント）をWebサイトと共有できたことを応答は示していません。そのため、フローが中断されるため、返される結果が悪意のあるコードに到達することはありません。