1

ここからのサンプルによると：

リクエストが GET、HEAD、または POST 以外のメソッドを使用する場合。また、POST を使用して、application/x-www-form-urlencoded、multipart/form-data、または text/plain 以外の Content-Type を持つリクエスト データを送信する場合 (たとえば、POST リクエストが XML ペイロードをサーバーに送信する場合) application/xml または text/xml を使用すると、リクエストはプリフライトされます。

したがって、次の例では、XML Content-Type とカスタム ヘッダーにより、プリフライトが実行されますX-PINGOTHER。

var invocation = new XMLHttpRequest();
var url = 'http://bar.other/resources/post-here/';
var body = '<?xml version="1.0"?><person><name>Arun</name></person>';

function callOtherDomain(){
  if(invocation)
    {
      invocation.open('POST', url, true);
      invocation.setRequestHeader('X-PINGOTHER', 'pingpong'); //<====
      invocation.setRequestHeader('Content-Type', 'application/xml'); //<====
      invocation.onreadystatechange = handler;
      invocation.send(body); 
    }
}

しかし、いわゆるプリフライト OPTIONS リクエスト (以下) では、サーバーは HTTP メソッドとカスタム ヘッダーのみを通知されます。誰もサーバーに について話しませんでしたXML Content-Type。

論理的には、プリフライト リクエストが送信される限り、Content-Typeがプリフライトを必要としない 3 つの形式ではないことを意味します。しかし、他にも多くの可能性があります。肝心なのは、サーバーはプリフライト要求が送信された理由を認識できる必要があるということです。

では、パズルのピース (コンテンツ タイプ) が欠けている状態で、サーバーがこの要求を許可するかどうかを合理的に決定するにはどうすればよいでしょうか?

ここに画像の説明を入力

4

1 に答える 1

3

CORS はほとんど常に安全です。Fetch Standardからの引用、

データが IP 認証またはファイアウォール (残念ながらまだ比較的一般的) によって保護されているリソースの場合、CORS プロトコルの使用は安全ではありません。(これが、CORS プロトコルを発明しなければならなかった理由です。)

ただし、それ以外の場合は、次のヘッダーを使用しても安全です。

Access-Control-Allow-Origin: *

リソースが Cookie または HTTP 認証に基づいて追加情報を公開する場合でも、上記のヘッダーを使用してもそれは明らかになりません。リソースは、すでに curl や wget で共有されているように、XMLHttpRequest などの API と共有されます。

したがって、言い換えると、curl および wget を使用して Web に接続されたランダムなデバイスからリソースにアクセスできない場合、前述のヘッダーは含まれません。ただし、アクセスできる場合は、アクセスしてもまったく問題ありません。

したがって、サーバーは、OPTIONS 要求に応答する方法を知るために、要求のコンテンツ タイプについて何も知る必要はありません。サーバーが知る必要があるのは、IP ベースの認証を介してのみアクセスできるか、ファイアウォールまたはイントラネットの背後にあるかについて尋ねられている URL であるかどうかです。そうである場合は、OPTIONS 要求を拒否する必要があります。そうでない場合、つまり、curl、wget、telnet、またはお気に入りの HTTP ライブラリなどのツールを使用してパブリック インターネット経由でリソースにアクセスできる場合は、OPTIONS 要求を許可する必要があります。そうすることで、ブラウザーに他のツールと同じアクセス権を与えるだけです。

その後、サーバーは、後続の POST 要求が着信したときに、さらに決定を下すことができます。しかし、それは常にこれをしたいと思うでしょう。CORS を尊重するブラウザーからの OPTIONS 要求だけを拒否することは望ましくありません。代わりに、どのソースからの POST リクエストも拒否する必要があります。

(ブラウザが特別である理由は次のとおりです。不適切なセキュリティ慣行に従い、特定の範囲内の IP アドレスを持つすべての人、つまり会社のコンピュータを使用しているすべての人が読み取ることができるイントラネットを考えてみましょう。通常、それは問題ではありません。 curl を使用している企業はデータにアクセスできますが、curl を使用している企業外の人はデータにアクセスできません. ただし、企業内の誰かが悪意のある Web サイトhttps://evil.com/を閲覧したとします. Evil.com が XHR API を使用してhttp://intranet/secret-dataにアクセスすると、リクエストは特権 IP アドレスから送信されますこれは、特権ユーザーのコンピューターのブラウザーが要求を実行しているためです。この種のセキュリティ リークを防ぐために、CORS プロトコルが発明されました。これにより、ブラウザはhttp://intranet/secret-dataに直接 POST を実行する代わりに、最初に OPTIONS リクエストを実行します。イントラネットはおそらく「いいえ、これにアクセスできません」と言うだけで、POST は発生しません。)

于 2016-01-08T02:56:32.903 に答える