web-dev-qa-db-ja.com

CORS（responseText）を介したXMLHttpRequestの理解

プロジェクトでは、さまざまなHTML5およびJavascriptの要素とそれらを取り巻くセキュリティを検討しており、CORSを回避しようとしています。

私のテストに基づいて、私が削除した場合..

<?php
 header("Access-Control-Allow-Origin: *"); 
 header('Access-Control-Allow-Methods: GET, POST, OPTIONS');
 ?>

..アクセスしようとしているページから、Chromeのコンソールログに次のように表示されます。

XMLHttpRequest cannot load http://www.bla.com/index.php. Origin http://bla2.com is not allowed by Access-Control-Allow-Origin.

私はこれが正しいことを理解していますが、WiresharkはリターンでHTTP/1.1 200 OKを示し、データではリクエストされているページのソースを示しています。それでは、実際に転送されたとしてもresponseTextが実質的な方法で使用されるのをブロックしているのはブラウザとJavascriptだけなのでしょうか？

コードは次のとおりです。

  function makeXMLRequest() {
  xmlhttp=new XMLHttpRequest();
xmlhttp.onreadystatechange = function() {
    if (xmlhttp.readyState==4) {
        alert(xmlhttp.responseText);
    }
}
xmlhttp.open("GET","http://www.bla.com/index.php",true);
xmlhttp.send();
}

前もって感謝します。

javascriptxmlhttprequestcors
16
AreYouSure

GETやPOSTなどの「単純な」HTTP動詞の場合、はい、ページ全体がフェッチされ、ブラウザーはJavaScriptがコンテンツを使用するかどうかを決定します。サーバーは、リクエストの送信元を知る必要はありません。サーバーからの応答を検査し、JSがコンテンツの表示を許可されているかどうかを判断するのは、ブラウザーのジョブです。

PUTやDELETEのような「単純ではない」HTTP動詞の場合、ブラウザーはOPTIONS要求を使用して「プリフライト要求」を発行します。その場合、ブラウザーは最初にAccess-Control-Allow-OriginおよびAccess-Control-Allow-Methodsをそれぞれ確認することにより、ドメインおよび動詞がサポートされているかどうかを確認します。 （詳細については、HTML5 Rocksの CORSページ の「Not-So-Simple Request」を参照してください。）プリフライトレスポンスには、Access-Control-Allow-Headersに含まれる、許可される非シンプルヘッダーもリストされます。

これは、クライアントがDELETEリクエストをサーバーに送信できるようにすることは、JavaScriptがクロスドメインの結果を確認できなくても非常に悪い可能性があるためです-繰り返しますが、サーバーは通常、リクエストを検証する義務を負わない正当なドメインから来ている（ただし（mayリクエストからOriginヘッダーを使用してそうする）.

33
apsillers

それでは、実際に転送されたとしてもresponseTextが実質的な方法で使用されるのをブロックしているのはブラウザとJavascriptだけなのでしょうか？

はい。あなたはJSで好きなリクエストをすることができます。

同じOriginポリシーで防止されるのは、データへのアクセスです。

悪意のあることを行うリクエスト（「POST http://bank.example/give/money?to=attacker "または" POST http://forum.example.com/post?message=spamspamspamspam"）は CSRF攻撃 と呼ばれ、サーバーから防御する必要があります。

6
Quentin