我正在研究HTML5的安全问题。我看到了Shreeraj Shah所做的所有演讲。我尝试使用withCredentials标记集将我自己的服务器模拟基本的CSRF攻击（因此在响应消息中应该重放cookie）并在请求中将text-Type集添加到text / plain（绕过预检调用） 。 当我尝试启动攻击时，浏览器告诉我，由于Access-Control-Allow-Origin标头，XMLHttpRequest无法完成。所以我在受害者网页的标题中放了一个*，浏览器告诉我，当我发送withCredentials设置为true的请求时，我不能使用*字符。 我尝试使用存储在同一域中的Web应用程序做同样的事情，一切都很好（我想这是因为浏览器不会检查请求是否来自同一个域）。
我问，这是现代浏览器最近设置的新功能，以避免这种问题？ 因为在Shreeraj的视频中，请求是跨越不同的域并且它有效...
谢谢大家，对不起我的英文： - ）
编辑：
我认为我发现CSRF攻击不能像Shreeraj的演示中那样正常工作的原因。 我阅读了2010年发布的上一篇CORS文档，我发现当Access-Control-Allow-Origin设置为*时，没有任何关于将凭证标志设置为true的建议，但如果我们查看最后两个有关CORS（2012年和2013年）的出版物，在6.1节中，其中一个注释是，如果将Access-Control-Allow-Origin设置为*，我们就无法使用凭证标志设置为true。
以下是链接：
前一个（2010）：http://www.w3.org/TR/2010/WD-cors-20100727/
最后两个（2012年，2013年）：http://www.w3.org/TR/2012/WD-cors-20120403/ --- http://www.w3.org/TR/cors/
以下是我正在讨论的部分：http://www.w3.org/TR/cors/#supports-credentials
如果我们查看以前的文档，我们找不到它，因为没有。
我认为这就是为什么Shreeraj Shah在2012年进行的简单CSRF攻击今天不起作用的原因（当然在遵循w3c建议的现代浏览器中）。可能是吗？
答案 0 :(得分：1)
尽管浏览器出错（如果没有飞行前），仍会提出请求。
Access-Control-Allow-Origin只允许访问来自不同域的响应，它不会影响实际的HTTP请求。
e.g。即使evil.com使用AJAX没有设置CORS标头，example.com/transferMoney仍然可以向example.com发出POST请求。