我正在阅读CORS，我认为实施既简单又有效。
然而，除非我遗漏了什么，否则我认为规格中有很大一部分缺失。据我了解，根据请求的来源（以及可选地包括凭证）决定是否允许访问其资源的外国站点。这很好。
但是，如果页面上的恶意代码想要将用户的敏感信息发布到外部网站，该怎么办？外国站点显然将验证请求。因此，如果我没有遗漏某些内容，CORS实际上会更容易窃取敏感信息。
我认为如果原始网站还可以提供其页面允许访问的不可变服务器列表，那将更有意义。
因此扩展的序列将是：
我知道恶意代码仍然可以使用JSONP来完成其脏工作，但我认为CORS的完整实现意味着关闭脚本标记多站点漏洞。
我还查看了官方的CORS规范（http://www.w3.org/TR/cors），但没有找到任何关于此问题的提及。
答案 0 :(得分：15)
但是，如果页面上的恶意代码想要将用户的敏感信息发布到外部站点，该怎么办？
怎么样？你可以在没有CORS的情况下做到这一点。即使回到Netscape 2，您也始终能够通过简单的GET和POST请求将信息传输到任何第三方网站，这些请求只需form.submit()，new Image或设置{{1 }}
如果恶意代码可以访问敏感信息，那么您已经完全丢失了。
3）Page想要向malicious.com发出XHR请求 - 请求在本地拒绝
为什么网页会尝试向尚未列入白名单的网站发出XHR请求？
如果您正在尝试防止由于XSS漏洞而注入的恶意脚本的操作，那么您正试图修复症状，而不是原因。
答案 1 :(得分：3)
您的担忧完全有效。
然而，更令人担忧的是，不需要存在任何恶意代码来利用它。有许多基于DOM的跨站点脚本漏洞，允许攻击者利用您描述的问题并将恶意JavaScript插入到易受攻击的网页中。问题不仅仅在于可以发送数据的地方，还有可以从中接收数据的地方。
我在这里更详细地讨论这个问题：
答案 2 :(得分：2)
在我看来，CORS正在纯粹扩展可能的东西，并试图安全地进行。我认为这显然是一种保守的举动。在更安全的情况下对其他标签（脚本/图像）制定更严格的跨域策略会破坏大量现有代码，并使采用新技术变得更加困难。希望有一些事情可以解决这个安全漏洞，但我认为他们需要先确保一个简单的过渡。
答案 3 :(得分：1)
问题不在于网站可以访问其已有权访问的其他网站资源。问题是域之一 - 如果我在我的公司使用浏览器，并且ajax脚本恶意地决定尝试10.0.0.1（可能是我的网关），它可能只是因为请求现在来自我的访问电脑（也许是10.0.0.2）。
所以解决方案 - CORS。我并不是说它是最好的，但是解决了这个问题。
1）如果网关无法返回'bobthehacker.com'接受的原始标题，则浏览器拒绝该请求。这可以处理旧的或未准备好的服务器。
2）如果网关仅允许来自myinternaldomain.com域的项目，它将拒绝'bobthehacker.com'的ORIGIN。在SIMPLE CORS的情况下，它实际上仍会返回结果。默认情况下;您可以将服务器配置为甚至不这样做。然后在不通过浏览器加载的情况下丢弃结果。
3）最后，即使它接受某些域，您也可以控制接受和拒绝的标头，以使来自这些网站的请求符合某种形状。
注意 - ORIGIN和OPTIONS标头由请求者控制 - 显然，创建自己的HTTP请求的人可以在其中放置他们想要的任何内容。然而，现代的CORS兼容浏览器WONT可以做到这一点。浏览器控制着交互。浏览器阻止bobthehacker.com访问网关。那是你缺少的部分。
答案 4 :(得分：0)
我与David分享了他们的担忧。 必须逐层构建安全性，并且源服务器提供的白名单似乎是一种很好的方法。
此外，此白名单可用于关闭现有漏洞（表单，脚本标签等），可以安全地假设服务白名单的服务器旨在避免后向兼容性问题。
答案 5 :(得分：0)
我还检查了官方CORS spec，但未发现此问题。
右。 CORS规范正在解决一个完全不同的问题。你错了，它会让问题变得更糟 - 它使问题既不好也不坏，因为一旦恶意脚本在你的页面上运行，它就已经可以在任何地方发送数据。
但好消息是，是 widely-implemented规范解决了这个问题：Content-Security-Policy。它允许您指示浏览器限制您的页面可以执行的操作。
例如，您可以告诉浏览器不要执行任何内联脚本，这将立即击败许多XSS攻击。或者 - 正如您在此处所要求的那样 - 您可以明确告诉浏览器允许页面与哪些域联系。