通过CORS理解XMLHttpRequest(responseText)

Question

对于一个项目,我正在查看各种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,数据显示所请求页面的来源.那么只是浏览器和Javascript阻止responseText以任何实质性方式使用,即使它实际上被转移了吗？

代码如下:

  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();
}

提前致谢.

Answer 1

对于像GET或POST这样的"简单"HTTP动词,是的,提取整个页面,然后浏览器决定JavaScript是否可以使用这些内容.服务器不需要知道请求的来源; 它是浏览器的工作检查来自服务器的答复,并决定是否JS被允许看到的内容.

对于像PUT或DELETE这样的"非简单"HTTP动词,浏览器使用OPTIONS请求发出"预检请求".在这种情况下,浏览器首先检查是否支持域和动词,分别通过检查Access-Control-Allow-Origin和Access-Control-Allow-Methods.(有关详细信息,请参阅HTML5 Rocks 的CORS页面上的" 处理不那么简单的请求 " .)预检响应还列出了允许的非简单标头,包括在内.Access-Control-Allow-Headers

这是因为允许客户端向服务器发送DELETE请求可能非常糟糕,即使JavaScript永远不会看到跨域结果 - 再次记住,服务器通常没有义务验证请求来自合法域(尽管它可以使用Origin请求中的标头).

Answer 2

那么只是浏览器和Javascript阻止responseText以任何实质性方式使用,即使它实际上被转移了吗？

是.你可以用JS做任何你喜欢的请求.

它可以访问同一原始策略阻止的数据.

执行恶意攻击(例如" POST http://bank.example/give/money?to=attacker"或" POST http://forum.example.com/post?message=spamspamspamspam")的请求称为CSRF攻击,必须由服务器进行防御.