CORS-プリフライトリクエストを導入する動機は何ですか？

クロスオリジンリソースシェアリングは、Webページが（wikipediaから）別のドメインにXMLHttpRequestsを作成できるようにするメカニズムです。

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

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

かなり検索した後、私が見つかりました。この作品 www.w3.orgで情報の（7.1.5）を：

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

これは文を理解するのが最も難しいと思います。私の解釈（「最良の推測」と呼ぶ方がよいでしょう）は、仕様を認識していないサーバーCからの要求からサーバーBを保護することです。

誰かがシナリオを説明してもらえますか/ PR + RRがRR単独よりもうまく解決する問題を示しますか？

プリフライトリクエストの目的について混乱する時間を費やしましたが、今は理解できたと思います。

重要な洞察は、プリフライトリクエストはセキュリティ上の問題ではないということです。むしろ、それらはルールを変更しないものです。

プリフライトリクエストはセキュリティとは関係がなく、CORSを意識して現在開発中のアプリケーションには影響しません。むしろ、プリフライトメカニズムは、CORSを意識せずに開発されたサーバーにメリットをもたらし、両方がCORS対応であることをクライアントとサーバー間の正常性チェックとして機能します。CORSの開発者は、受信しないという前提に依存しているサーバーが十分にあると感じました（たとえば、プリフライトメカニズムを発明して両側をオプトインできるようにしたクロスドメインDELETE要求）。彼らは、クロスドメインコールを単純に有効にするという代替案では、既存のアプリケーションが多すぎて壊れてしまうと感じていました。

ここには3つのシナリオがあります。

1. 古いサーバーは、もはや開発中ではなく、CORSより前に開発されました。これらのサーバーは、たとえばクロスドメインのDELETEリクエストを受信しないことを想定している場合があります。このシナリオは、プリフライトメカニズムの主要な受益者です。はい、これらのサービスは悪意のある、または非準拠のユーザーエージェントによって既に悪用される可能性があります（そしてCORSはこれを変更するために何もしません）。 Webの基本的なルールが変更されたため、中断します。

2. まだ開発中のサーバーですが、古いコードが多く含まれていて、すべての古いコードを監査してクロスドメインの世界で適切に動作することを確認することは現実的ではありません。このシナリオでは、サーバーがCORSに徐々にオプトインできるようにします。たとえば、「この特定のヘッダーを許可する」、「この特定のHTTP動詞を許可する」、「Cookie /認証情報を許可する」送信済み」など。このシナリオはプリフライトメカニズムの恩恵を受けます。

3. CORSを意識して作成された新しいサーバー。標準的なセキュリティ慣行によれば、サーバーは着信要求に直面してもリソースを保護する必要があります。サーバーはクライアントを信頼して悪意のある行為を行わないようにすることはできません。このシナリオはプリフライトメカニズムの恩恵を受けません。プリフライトメカニズムは、リソースを適切に保護しているサーバーに追加のセキュリティを提供しません。

プリフライトリクエストを導入した動機は何ですか？

ブラウザが特定のリクエストを送信する前にCORS対応サーバーを処理していることを確認できるように、プリフライトリクエストが導入されました。これらのリクエストは、潜在的に危険（状態を変える）と新しい（同じ発生元ポリシーのためにCORSの前には不可能であった）の両方であるリクエストとして定義されました。プリフライト要求を使用するということは、CORSが可能にする潜在的に危険な新しいタイプの要求にサーバーが（プリフライトに適切に応答することによって）オプトインする必要があることを意味します。

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

例を挙げてもらえますか？

ブラウザユーザーがの銀行サイトにログインしているとしましょうA.com。悪意のあるB.comユーザーに移動すると、そのページにはDELETEリクエストをに送信しようとするJavascriptが含まれA.com/accountます。ユーザーはにログインしA.comているため、送信されたリクエストには、ユーザーを識別するCookieが含まれます。

CORSが導入される前は、ブラウザの同一生成元ポリシーによって、このリクエストの送信がブロックされていました。しかし、CORSの目的は、この種のクロスオリジンコミュニケーションを可能にすることなので、もはや適切ではありません。

ブラウザは単にを送信しDELETE、サーバーにその処理方法を決定させることができます。しかしA.com、CORSプロトコルを認識していない場合はどうなりますか？それは先に進んで危険を実行するかもしれませんDELETE。ブラウザーのSame Origin Policyにより、そのような要求を受信することはできないため、このような攻撃に対して強化されていない可能性があると想定されていた可能性があります。

このようなCORS非対応サーバーを保護するために、このプロトコルでは、ブラウザが最初にプリフライト要求を送信する必要があります。この新しい種類のリクエストは、CORS対応サーバーのみが適切に応答できるため、ブラウザは実際のを送信しても安全かどうかを確認できますDELETE。

なぜブラウザがこれほど面倒なのか、攻撃者DELETEは自分のコンピュータからリクエストを送信できないのですか？

もちろん、そのようなリクエストにはユーザーのCookieは含まれません。これを防ぐために設計された攻撃は、ブラウザーが要求と共に他のドメインのCookie（特にユーザーの認証情報）を送信するという事実に依存しています。

以下のようなその音クロスサイトリクエストフォージェリサイト上のフォーム、B.com缶POSTにA.com、ユーザーのクッキーとは、ダメージを与えます。

そのとおり。これを説明する別の方法は、CORS非対応サーバーのCSRF攻撃面を増加させないようにプリフライト要求が作成されたことです。

しかし、プリフライトを必要としない「単純な」リクエストの要件を見ると、それPOSTはまだ許可されていることがわかります。DELETE！のように、状態を変更してデータを削除できます。

それは本当だ！CORSは、CSRF攻撃からサイトを保護しません。また、CORSがないと、CSRF攻撃からも保護されません。プリフライトリクエストの目的は、CSRFへの露​​出を、CORS以前の世界にすでに存在するものに制限することです。

はぁ。OK、プリフライトリクエストの必要性を不本意に受け入れます。しかし、なぜサーバー上のすべてのリソース（URL）に対してこれを行う必要があるのでしょうか。サーバーはCORSを処理するか、処理しません。

よろしいですか？複数のサーバーが単一のドメインに対する要求を処理することは珍しくありません。例えば、要求A.com/url1が1種類のサーバーでA.com/url2処理され、要求が別の種類のサーバーで処理される場合があります。単一のリソースを処理するサーバーがそのドメイン上のすべてのリソースについてセキュリティを保証できるのは、一般的には当てはまりません。

いいね。妥協しましょう。これらのURLへの追加のプリフライト要求を回避できるように、サーバーが発言できるリソースを正確に示すことができる新しいCORSヘッダーを作成しましょう。

良いアイデア！実際、ヘッダーAccess-Control-Policy-Pathはこの目的のためだけに提案されました。最終的に、しかし、それは、仕様書のうち残っていたどうやら一部のサーバーが誤ってブラウザに安全なように見えたパスへの要求が実際に壊れたサーバー上で安全ではないような方法で、URIの仕様を実装しているため。

これは、パフォーマンスよりもセキュリティを優先し、既存のサーバーを危険にさらすことなくブラウザーがCORS仕様をすぐに実装できるようにする慎重な決定でしたか？または、特定の時間に特定のサーバーのバグに対応するために、帯域幅を浪費し、レイテンシを2倍にするためにインターネットを破滅させるのは近視眼でしたか？

意見は異なります。

少なくとも、ブラウザは単一のURLのプリフライトをキャッシュしますか？

はい。おそらくそれほど長くはありませんが。WebKitブラウザーでは、プリフライトの最大キャッシュ時間は現在10分です。

はぁ。サーバーがCORSに対応していて、プリフライトリクエストによる保護が不要であることを知っている場合、それらを回避する方法はありますか？

あなたの唯一の現実的な選択肢は、「単純な」リクエストの要件を確実に満たすことです。それは、他の方法で含める（のようなX-Requested-With）カスタムヘッダーの除外、の横にあるContent-Type、などを意味する場合があります。

CORS仕様では、unsafeを含む「単純な」要求の拒否に対応していないため、何をする場合でも、適切なCSRF保護が実施されていることを確認する必要がありますPOST。仕様にあるように、「単純なリクエストが取得以外の意味を持つリソースは、クロスサイトリクエストフォージェリから保護する必要があります」。

CORSの前にクロスドメインリクエストの世界を検討してください。標準形式のPOSTを実行するか、scriptまたはimageタグを使用してGETリクエストを発行できます。GET / POST以外のリクエストタイプを作成できず、これらのリクエストでカスタムヘッダーを発行できませんでした。

CORSの出現により、仕様の作成者は、既存のWebのセマンティクスを壊すことなく、新しいクロスドメインメカニズムを導入するという課題に直面しました。彼らは、サーバーに新しい要求タイプをオプトインする方法を提供することでこれを行うことを選択しました。このオプトインはプリフライトリクエストです。

したがって、カスタムヘッダーのないGET / POSTリクエストは、CORSの前にすでに可能だったので、プリフライトを必要としません。ただし、カスタムヘッダーを含むすべてのリクエスト、またはPUT / DELETEリクエストは、CORS仕様にとって新しいため、プリフライトが必要です。サーバーがCORSについて何も認識していない場合、サーバーはCORS固有のヘッダーなしで応答し、実際の要求は行われません。

プリフライト要求がないと、サーバーはブラウザーからの予期しない要求を認識し始める可能性があります。サーバーがこれらのタイプのリクエストに対応していないと、セキュリティ上の問題が発生する可能性があります。CORSプリフライトを使用すると、クロスドメインリクエストを安全な方法でWebに導入できます。

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

一部のサーバーは、ブラウザーが作成できないという想定（たとえば、クロスオリジンDELETEリクエストやX-Requested-Withヘッダー付きのクロスオリジンリクエスト）で（不十分に）保護されている可能性があるため、このようなリクエストは「信頼されます」。

サーバーが本当にランダムにCORSをサポートし、ランダムな要求に応答するだけではないことを確認するために、プリフライトが実行されます。

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

<!-- 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リクエストが、egによってすでに実行されている可能性があることです<script src="">（これがJSONPの仕組みです）。src属性を持つ要素は、プリフライトなしでクロスオリジンGETをトリガーできるため、「単純な」XHRの事前ファイトを要求してもセキュリティ上のメリットはありません。

他の答えは、戦前にセキュリティが強化される理由に焦点を合わせていないように感じます。

シナリオ：

1）プリフライト付き。ユーザーがsafe-bank.comに認証されている間、攻撃者はサイトdummy-forums.comからのリクエストを偽造
します。サーバーがオリジンを確認せず、何らかの欠陥がある場合、ブラウザーはプリフライトリクエスト、OPTIONを発行します方法。サーバーは、ブラウザーが応答として予期しているCORSを認識しないため、ブラウザーは続行しません（まったく害はありません）

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

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

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

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

ソース

プレフライトリクエストは、サーバーの状態を変更できるリクエストに必要です。リクエストには2つのタイプがあります-

1）サーバー上の状態を変更できない呼び出し（GETなど） -ユーザーは要求に対する応答を受け取る可能性があります（サーバーがオリジンをチェックしない場合）が、要求ドメインが応答ヘッダーAccess-Control-に追加されていない場合Allow-Origin、ブラウザはユーザーにデータを表示しません。つまり、リクエストはブラウザから送信されますが、ユーザーはレスポンスを表示/利用できません。

2）サーバーの状態を変更できる呼び出し（POST、DELETEなど） -1）から、ブラウザーは要求をブロックしませんが、応答を確認します。事前のチェックなしに状態変更呼び出しを行うことはできません。 。このような呼び出しは、ブラウザーへの応答が失敗した場合でも、呼び出し元を確認しない信頼するサーバーに変更を加える可能性があります（クロスサイトリクエストフォージェリと呼ばれます）。このため、状態変更の呼び出しをサーバーに送信する前にOPTIONS呼び出しを行うプリフライトリクエストという概念があります。

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

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

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

プリフライトされたリクエストと古いサーバーの利点の間の引用された相関関係を理解し​​ていませんでした。CORSの前に実装された、またはCORS認識なしで実装されたWebサービスは、最初にその応答に "Access-Control-Allow-Origin"ヘッダーがないため、クロスサイト要求を受信しません。

CORSをサポートするブラウザーでは、読み取り要求（GETなど）は同じ生成元ポリシーによって既に保護されています。悪意のあるWebサイトが（たとえば、被害者のインターネットバンキングWebサイトやルーターの構成インターフェイスに対して）認証されたクロスドメイン要求を行おうとすると、銀行またはルーターがAccess-Control-Allow-Originヘッダーを設定しないため、返されたデータを読み取ることができます。

ただし、書き込み要求（POSTなど）では、要求がWebサーバーに到着したときに損傷が発生します。* WebサーバーはOriginヘッダーをチェックして、要求が正当であるかどうかを判断できますが、この確認は多くの場合、実装されていません。 CORSまたはWebサーバーの場合はCORSよりも古いため、クロスドメインPOSTは同一生成元ポリシーによって完全に禁止されていると想定しています。

そのため、ウェブサーバーには、クロスドメインの書き込みリクエストの受信をオプトインする機会が与えられます。

_{*基本的に、CSRFのAJAXバージョン。}