24

我正在阅读有关CORS的信息，我认为实现既简单又有效。

但是，除非我遗漏了什么，否则我认为规范中遗漏了很大一部分。据我了解，是外部站点根据请求的来源（并且可选地包括凭据）决定是否允许访问其资源。这可以。

但是，如果页面上的恶意代码想要将用户的敏感信息发布到外部站点怎么办？外部站点显然要对请求进行身份验证。因此，如果我没有遗漏什么，CORS 实际上使窃取敏感信息变得更容易。

我认为，如果原始站点也可以提供其页面允许访问的服务器的不可变列表，那将更有意义。

所以扩展的序列将是：

  1. 提供一个包含可接受 CORS 服务器列表的页面（abc.com、xyz.com 等）
  2. 页面想要向 abc.com 发出 XHR 请求 - 浏览器允许这样做，因为它在允许列表中，并且身份验证正常进行
  3. 页面想要向恶意网站发出 XHR 请求 - 请求在本地被拒绝（即被浏览器），因为服务器不在列表中。

我知道恶意代码仍然可以使用 JSONP 来完成其肮脏的工作，但我会认为 CORS 的完整实现将意味着脚本标签多站点漏洞的关闭。

我还查看了官方的 CORS 规范（http://www.w3.org/TR/cors），找不到任何关于这个问题的提及。

4

6 回答 6

15

但是，如果页面上的恶意代码想要将用户的敏感信息发布到外部站点怎么办？

怎么样？你已经可以在没有 CORS 的情况下做到这一点。甚至早在 Netscape 2 中，您始终能够通过简单的 GET 和 POST 请求将信息传输到任何第三方站点，这些请求由简单的接口form.submit()或new Image设置window.location。

如果恶意代码可以访问敏感信息，那么您已经完全迷失了。

3) 页面想要向恶意网站发出 XHR 请求 - 请求在本地被拒绝

为什么页面会尝试向尚未列入白名单的站点发出 XHR 请求？

如果您试图防止由于 XSS 漏洞而注入的恶意脚本的操作，那么您正在尝试修复症状，而不是原因。

于 2010-03-28T14:41:00.413 回答
3

你的担心完全有道理。

然而，更令人担忧的是，不需要任何恶意代码就可以利用这一点。有许多基于 DOM 的跨站点脚本漏洞允许攻击者利用您描述的问题并将恶意 JavaScript 插入易受攻击的网页。问题不仅仅是数据可以发送到哪里，而是数据可以从哪里接收。

我在这里更详细地讨论这个：

于 2012-04-15T20:43:55.127 回答
2

在我看来，CORS 纯粹是在扩展可能性，并试图安全地做到这一点。我认为这显然是一个保守的举动。在更安全的同时对其他标签（脚本/图像）制定更严格的跨域策略会破坏大量现有代码，并使采用新技术变得更加困难。希望可以采取一些措施来关闭该安全漏洞，但我认为他们需要首先确保其轻松过渡。

于 2010-03-28T13:45:21.437 回答
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 兼容浏览器不会这样做。控制交互的是浏览器。浏览器阻止 bobthehacker.com 访问网关。那是您缺少的部分。

于 2017-02-02T17:23:55.470 回答
1

我还查看了官方CORS 规范，但找不到任何关于此问题的提及。

正确的。CORS 规范正在解决一个完全不同的问题。您误认为它使问题变得更糟 - 它使问题既不好也不坏，因为一旦恶意脚本在您的页面上运行，它就已经可以将数据发送到任何地方。

不过，好消息是有一个广泛实施的规范可以解决这个问题：Content-Security-Policy。它允许您指示浏览器限制您的页面可以执行的操作。

例如，您可以告诉浏览器不要执行任何内联脚本，这将立即击败许多 XSS 攻击。或者——正如你在这里所要求的——你可以明确地告诉浏览器允许该页面联系哪些域。

于 2017-01-19T06:53:39.590 回答
0

I share David's concerns. Security must be built layer by layer and a white list served by the origin server seems to be a good approach.

Plus, this white list can be used to close existing loopholes (forms, script tag, etc...), it's safe to assume that a server serving the white list is designed to avoid back compatibility issues.

于 2010-05-06T11:13:19.033 回答