453

クロスオリジン リソース共有は、Web ページが XMLHttpRequests を別のドメイン (ウィキペディアから) に送信できるようにするメカニズムです。

私はここ数日間 CORS をいじっていますが、すべてがどのように機能するかについてかなりよく理解していると思います。

したがって、私の質問は、CORS / プリフライトがどのように機能するかについてではなく、新しいリクエスト タイプとしてプリフライトを考え出す理由についてです。実際のリクエスト (RR) が受け入れられるかどうかを確認するためだけに、サーバー A がサーバー B にプリフライト (PR) を送信する必要がある理由がわかりません。以前のPR。

かなり検索した後、 www.w3.org (7.1.5)で次の情報を見つけました。

この仕様が存在する前に特定のユーザー エージェントから発信できなかったクロスオリジン リクエストからリソースを保護するために、プリフライト リクエストが作成され、リソースがこの仕様を認識していることを確認します。

これはこれまでで最も理解しにくい文だと思います。私の解釈（「最善の推測」と呼ぶべきです）は、仕様を認識していないサーバーCからのリクエストに対してサーバーBを保護することに関するものです。

誰かがシナリオを説明したり、PR + RR が RR 単独よりもうまく解決する問題を示したりできますか?

4

9 に答える 9

42

<img src>CORS を使用すると、クロスオリジンまたはで以前に可能だったよりも多くのヘッダーとメソッド タイプを指定できます<form action>。

DELETE一部のサーバーは、クロスオリジン要求やヘッダー付きクロスオリジン要求など、ブラウザが作成できないという前提で (不十分に) 保護されている可能性があるX-Requested-Withため、そのような要求は「信頼」されます。

サーバーが本当に CORS をサポートしており、たまたまランダムなリクエストに応答しないようにするために、プリフライトが実行されます。

于 2013-03-13T11:43:08.703 に答える
17

コードを使用した別の見方を次に示します。

<!-- hypothetical exploit on evil.com -->
<!-- Targeting banking-website.example.com, which authenticates with a cookie -->
<script>
jQuery.ajax({
  method: "POST",
  url: "https://banking-website.example.com",
  data: JSON.stringify({
    sendMoneyTo: "Dr Evil",
    amount: 1000000
  }),
  contentType: "application/json",
  dataType: "json"
});
</script>

CORS より前の場合、上記のエクスプロイトの試みは、同一オリジン ポリシーに違反しているため失敗します。このように設計された API は、ブラウザーのネイティブ セキュリティ モデルによって保護されているため、XSRF 保護を必要としませんでした。CORS 以前のブラウザーでは、クロスオリジンの JSON POST を生成することは不可能でした。

現在、CORS が登場しています。プレフライトを介して CORS にオプトインする必要がなかった場合、突然、このサイトは大きな脆弱性を持つことになります。

一部のリクエストがプリフライトをスキップできる理由を説明するために、これは仕様によって回答されています。

単純なクロスオリジン リクエストは、この仕様に準拠していない現在展開されているユーザー エージェントによって生成される可能性があるリクエストと一致するものとして定義されています。

これを解決するために、GET は 7.1.5 で定義されている「単純なメソッド」であるため、プリフライトされません。(プリフライトを避けるために、ヘッダーも「シンプル」である必要があります)。これの正当な理由は、「単純な」クロスオリジン GET リクエストがすでに実行されている可能性があること<script src="">です (これが JSONP の仕組みです)。属性を持つ任意の要素srcはクロスオリジン GET をトリガーできるため、プレフライトなしで、「単純な」XHR でプレファイトを要求してもセキュリティ上の利点はありません。

于 2016-05-05T01:01:58.513 に答える
16

他の回答は、戦闘前がセキュリティを強化する理由に焦点を当てていないように感じます.

シナリオ:

1)プリフライトあり。ユーザーが safe-bank.com に対して認証されている間に、攻撃者がサイト dummy-forums.com からのリクエストを偽造し
ます サーバーが発信元をチェックせず、何らかの欠陥がある場合、ブラウザはプリフライト リクエスト OPTION を発行します方法。サーバーは、ブラウザーが応答として期待している CORS を認識していないため、ブラウザーは処理を続行しません (害はありません)

2) pre-flight なし。攻撃者は上記と同じシナリオでリクエストを偽造します。ブラウザはすぐに POST または PUT リクエストを発行し、サーバーはそれを受け入れて処理する可能性があります。これにより、何らかの害が生じる可能性があります。

攻撃者がランダムなホストからクロスオリジンで直接リクエストを送信した場合、認証なしのリクエストを考えている可能性が最も高くなります。これは偽造リクエストですが、xsrf リクエストではありません。そのため、サーバーは資格情報をチェックして失敗します。CORS は、要求を発行する資格情報を持つ攻撃者を防ごうとはしませんが、ホワイトリストはこの攻撃ベクトルを減らすのに役立つ可能性があります。

プリフライト メカニズムにより、クライアントとサーバー間の安全性と一貫性が向上します。キャッシングはそこでは使いにくいので、これがすべてのリクエストに対して追加のハンドシェイクに値するかどうかはわかりませんが、それがどのように機能するかです。

于 2015-09-14T15:54:47.093 に答える
3

さらに、ユーザー データに副作用を引き起こす可能性のある HTTP リクエスト メソッド(特に、GET 以外の HTTP メソッド、または特定の MIME タイプでの POST の使用) の場合、仕様では、ブラウザがリクエストを「プリフライト」することが義務付けられています。

ソース

于 2013-03-13T12:28:12.760 に答える
1

Performanceに関する preflighted リクエストではありませんか? プリフライトされたリクエストを使用すると、クライアントは大量のデータを送信する前に操作が許可されているかどうかをすぐに知ることができます。たとえば、JSON で PUT メソッドを使用します。または、ネットワーク上で認証ヘッダーの機密データを移動する前に。

PUT、DELETE、およびカスタムヘッダー以外のその他のメソッドの事実は、デフォルトでは許可されていません（「Access-Control-Request-Methods」および「Access-Control-Request-Headers」で明示的な許可が必要です）、そう聞こえますこれらの操作は、GET 要求ではなく、ユーザー データにより多くの影響を与える可能性があるためです。したがって、次のように聞こえます。

「あなたはhttp://foo.exampleからのクロスサイト リクエストを許可しているのを見ましたが、DELETE リクエストを許可してもよろしいですか? これらのリクエストがユーザー データに与える影響を考慮しましたか?」

プリフライトされたリクエストと古いサーバーの利点との間の引用された相関関係を理解できませんでした。CORS の前に実装された Web サービス、または CORS 認識なしで実装された Web サービスは、クロスサイト リクエストを受信することはありません。

于 2015-05-02T20:02:06.233 に答える