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 page上的“处理不那么简单的请求”。）预检响应还列出了{{{}中包含的允许的非简单标头。 1}}。

这是因为允许客户端向服务器发送DELETE请求可能非常糟糕，即使JavaScript永远不会看到跨域结果 - 再次记住，服务器通常没有任何验证义务该请求来自合法域（尽管可能使用请求中的Access-Control-Allow-Headers标头）。

Answer 2

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

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

可以访问相同原始策略阻止的数据。

执行恶意内容（例如“POST http://bank.example/give/money?to=attacker”或“POST http://forum.example.com/post?message=spamspamspamspam"”的请求称为CSRF attacks，并且必须由服务器进行辩护。

通过CORS理解XMLHttpRequest（responseText）

2 个答案: