ここからの抜粋 :
Cross-Originリソースが新しいOriginの別のリソースにリダイレクトする場合、ブラウザーはリダイレクト後にOriginヘッダーの値をnullに設定します。これにより、混乱する代理攻撃を防ぐことができますが、CORS以外のリソースの場合と同様に、3xxステータスコードを持つドメイン間で(Cookieベースの)資格情報と単純な要求をサポートするCORSリソースを透過的に移動することが難しくなります。ブラウザはそのようなリクエストにCORSアルゴリズムを透過的に適用し、最初のホップのOriginヘッダーを含めるため、同じ起源のリソースをクロス起源の場所(シングルホップのみ)にリダイレクトできます。
リダイレクトされたリクエストのOriginヘッダーを維持すると、混乱した代理攻撃をどのように許可できますか?
その段落は簡潔に書かれており、最初の文での「新しいOriginの別のリソースへのリダイレクト」の使用は完全に正しくありません。
これは簡単な不自然な例です。あなたが悪意を持っており、CORSを介して特権APIのサービスを使用するWebアプリケーションがあり、WebアプリケーションのOriginが特権APIによって信頼されているとします。そして、その特権APIの背後にあるデータにアクセスしたいとしますが、もちろん、Originは信頼されていません。
CORSを介して提供するシンプルで便利なサービスを作成し、信頼できるOriginの下の任意のページのページにサービスを含めるWebアプリケーションを取得します。そのページは特権APIにアクセスする必要はありません。
(もちろん、被害者のページにアクセスしたら、何でも好きなことができますが、私と一緒に耐えてください。)
CORSサービスを変更して、200をいくつかのデータとともに発行し、3xxを特権APIに発行し、リソースドメインを通過すると、信頼の問題が発生します。
実際のOrigin-リソースを埋め込んだページ-は、特権APIによって信頼されます。ただし、リクエストは発行されなかったため、この特定の時点で特権APIと通信したくない場合があります。
代わりに、リダイレクトを発行し、Originによって部分的に信頼されている一方で、特権APIによって信頼されていません。ブラウザが3xxに従ってOriginに沿って送信すると、特権APIによってOriginに与えられた信頼を違法に乗っ取ります。
ブラウザーは何をしますか?合理的な答えは3xxにまったく従わないことですが、これは信頼が関係しないユースケースを許可しません。 「null」オリジンを使用してリクエストを発行すると、これらの使用例は許可されますが、元のオリジンヘッダーに沿って送信することで許可される信頼の悪用は防止されます。
CSRF防御の観点からOriginヘッダーを見てください。
a.comホストとしましょう...
Originがクロスオリジンリダイレクト後に保持された場合、次のCSRF攻撃が可能です。
Origin: https://a.com
を使用してb.comへのCORSリクエストを行うページにアクセスします。Origin: https://a.com
を使用してURLをリクエストします。a.comサーバーは、要求がa.comから発信されたと信じているため、要求を処理します。 。
a.comがCORSリクエストをb.comに送信するという事実は、を信頼することを意味しませんb.com完全に。
これについては、関連するChromeバグ: https://bugs.chromium.org/p/chromium/issues/detail?id=465517 で説明されています。
Originヘッダーにリダイレクトチェーンのすべての送信元のリストが含まれている場合、Originリダイレクトを安全に許可するアプリケーションを構築できる可能性があります。残念ながら、ブラウザベンダーはそれを実装していません。同じ CORS for Developersドキュメント から引用:
CORS仕様では、Access-Control-Allow-Originヘッダーに複数のオリジンをリストできることを示していますが、実際には、すべての最新のブラウザーで許可されている値は1つだけです。複数値構文は、RFC6454で許可されているように、リダイレクトチェーンのすべてのオリジンをリストできるようにすることを目的としていましたが、これは実装されていませんでした。