web-dev-qa-db-ja.com

なぜAccess-Control-Allow-Originヘッダーが必要なのですか？

Access-Control-Allow-Credentialsヘッダーの目的 は理解していますが、Access-Control-Allow-Originヘッダーで解決される問題を確認できません。

より正確には、クロスドメインAJAXリクエストクレデンシャルを伴うリクエストがデフォルトで許可されている場合、またはサーバーが吐き出していた場合、すべてのリクエストでAccess-Control-Allow-Credentialsヘッダーを使用すると、他の方法では実行できないCSRF攻撃が可能になります。このシナリオの攻撃方法は単純です。

  1. 疑いを持たないユーザーを悪意のあるページに誘導します。
  2. 悪意のあるページのJavaScriptがAJAXリクエスト-withcookie-をターゲットサイトのいくつかのページに送信します。
  3. 悪意のあるページのJavaScriptがAJAX要求への応答を解析し、そこからCSRFトークンを抽出します。
  4. 悪意のあるページのJavaScriptは任意の手段を使用します-AJAXまたは形式POSTのようなCSRFリクエスト用の従来の容器-ユーザーのCookieと盗まれたCSRFトークン。

ただし、私が見ることができないことは、uncredentialedクロスドメインを許可しないことによって提供される目的がどのような目的であるかAJAX Access-Control-Allow-Originヘッダーなしのリクエストです。これまでに受信したすべてのHTTP応答に含まれているように動作するブラウザを作成するとします

Access-Control-Allow-Origin: *

ただし、クロスドメインAJAXリクエストでCookieを送信する前に、適切なAccess-Control-Allow-Credentialsヘッダーが必要でした。

CSRFトークンは個々のユーザー（つまり、個々のセッションCookie）に関連付ける必要があるため、uncredentialedAJAXリクエストへの応答では、 CSRFトークン。では、上記の架空のブラウザがユーザーをさらす攻撃方法は（もしあれば）どうでしょうか。

httpcsrfsame-origin-policycors
50
Mark Amery

私があなたを正しく理解しているとしたら、クッキーが関与していない場合に、ブラウザがインターネット経由で自由に取得できるリソースへのアクセスをブロックしているのはなぜですか？このシナリオをよく検討してください。

_www.evil.com_-CSRFの脆弱性を悪用しようとする悪意のあるスクリプトコードが含まれています。

_www.privatesite.com_-これは外部サイトですが、資格情報を使用してロックダウンする代わりに、Cookieを使用せず、ホームルーターの静的IPからのアクセスのみを許可するように設定しました。

mynas (192.168.1.1)-これはホームサーバーであり、ホームwifiネットワークでのみアクセスできます。あなたがあなたの家のwifiネットワークへの接続を許可するのはあなただけなので、このサーバーは資格情報によって保護されておらず、匿名のCookieなしのアクセスを許可します。

_www.privatesite.com_とmynasはどちらも、CSRFから保護するために非表示のフォームフィールドにトークンを生成します。ただし、認証を無効にしているため、これらのトークンはユーザーセッションに関連付けられていません。

誤って_www.evil.com_にアクセスした場合、このドメインは、クロスドメインリクエストで取得したトークンを渡して_www.privatesite.com/turn_off_ip_lockdown_にリクエストを送信したり、同じメソッドを使用して_mynas/format_drive_にリクエストを送信したりする可能性があります。

おそらくそうは思いませんが、標準はできる限り堅牢になるように記述されていると思います。このようなシナリオで利点を追加するため、_Access-Control-Allow-Origin_を削除しても意味がありません。

25
SilverlightFox

CORSポリシーで最初に私を悩ませたのは、リソース/タイプに関係なく、それらの無差別のアプリケーションでした。感情はあなたの質問に非常によく共鳴していると思います。 W3仕様は実際には アドバイス です：

アクセス制御チェックなしでパブリックにアクセス可能なリソースは、常に値が「*」のAccess-Control-Allow-Originヘッダーを安全に返すことができます。

したがって @ SilverlightFoxの答え のシナリオは可能ですが、IMHOは仕様を作成するときに考慮されることはほとんどありませんでした。代わりに、W3は「明示的に許可されていないものはすべて制限する必要があります」考え方によって推進されているように見えます。設定しないか、個々のブラウザでサポートが不足しています：

  • サードパーティのRESTful APIを使用するリッチクライアント側アプリケーション。認証がある場合は、リクエストごとに送信されるため、Hijackへの「セッション」はありません（ステートレスです）。それでも、.json応答はCORSの対象になるため、jsonpまたは適切なAccess-Control-Allow-Originヘッダーを実装するか、エンドポイントへのトンネルをあきらめてセットアップするようにサードパーティに説得する必要があります（どちらを使用するかを推測します）。

  • Webfonts CORSの影響を受ける 、ただし、このドラフト仕様を実装したのはFirefoxだけです。つまり、フォント（またはすべての静的コンテンツにサブドメイン）にCDNを使用している場合は、*対応にするのが最適です。

  • ボーナスherp derpは、*ヘッダーで応答せず、代わりにリクエストOriginヘッダー値をエコーするCDNを指します：...-Allow-Origin: domainAが設定されたプロキシでキャッシュされると、他のドメインのユーザーはキャッシュ無効化なしではアクセスできなくなります（これはCDNパフォーマンスの点で後退の一種です）。

  • canvasで外部の画像/ビデオを使用 のようないくつかのフリンジシナリオもあります。

*に適したリソースにアクセスするときのこれらの不便さは、デフォルトで少なくともCORSが最も重要なときに機能するため、単に許容できると見なすことができます。

12
o.v.