同源策略和 CORS - 有什么意义？

Question

我在理解同源策略以及“解决”它的不同方法时遇到了一些麻烦。

很明显，同源策略是作为一种安全措施存在的，因此来自服务器/域的一个脚本无法访问来自另一个服务器/域的数据。

也很明显，有时能够打破此规则很有用，例如，mashup 应用程序访问来自不同服务器的信息以构建所需的结果。其中一种方法是 CORS。

1) 如果我没记错的话，CORS 允许目标服务器通过添加一些内容对浏览器说“你可以从我自己那里获取数据/代码”响应中的标头。但是，如果这是正确的，这意味着恶意服务器可以只添加此标头，并且浏览器将允许检索来自该服务器的任何可能有害的数据或代码。

2) 另一方面，我们有 JSONP，允许我们在没有启用 CORS 的情况下从服务器检索任意代码或数据，从而避免了 SOP 的主要目标。因此，即使在浏览器中硬连线 SOP，能够管理 JSONP 的恶意服务器也能够注入数据或代码。

所以我的问题是：

第二个论证正确吗？浏览器是否必须接受内容是服务器的决定吗？ 第二个论证正确吗？同样，是否接受数据不在浏览器的决定中？

JSONP 不会使 SOP 无用吗？

谢谢你启发我！！

Answer 1

这里需要注意的重要一点是，如果用户登录到站点http://example.com/，并且请求http://example.com/delete?id=1 删除了用户的帖子，那么以下代码将删除用户的帖子：

<script src="http://example.com/delete?id=1" />

这称为 CSRF/XSRF 攻击（跨站请求伪造）。这就是为什么大多数服务器端 Web 应用程序都需要交易票据的原因：您必须使用 http://example.com/delete?id=1 而不是 http://example.com/delete?id=1&txid=SomethingTheUserCannotGuess

现在下面的攻击不起作用了：

<script src="http://example.com/delete?id=1" />

...因为它不包含 txid 参数。现在，让我们考虑如果可以使用 XmlHttpRequest 访问该站点会发生什么。在用户浏览器上运行的脚本可以在用户背后检索和解析http://example.com/pageThatContainsDeleteLink，提取txid然后请求http://example.com/delete?id=1&txid=SomethingTheUserCannotGuess

现在，如果 XmlHttpRequest 无法访问具有不同来源的站点，尝试检索 txid 的唯一方法是尝试执行以下操作：

<script src="http://example.com/pageThatContainsDeleteLink" />

...但这无济于事，因为结果是 HTML 页面，而不是一段 JavaScript 代码。因此，您可以包含来自其他站点的<script>s 但不能通过 XmlHttpRequest 访问其他站点是有原因的。

您可能有兴趣阅读以下内容：http://haacked.com/archive/2008/11/20/anatomy-of-a-subtle-json-vulnerability.aspx/

这种攻击在过去曾针对 Gmail，并允许您从运行在另一个站点上的 JavaScript 代码中获取用户的邮件。这都说明WWW的安全模型很微妙，没有经过深思熟虑。它已经进化而不是精心设计。

至于您的问题：您似乎认为服务器http://example.com/ 是恶意服务器。事实并非如此。使用我的答案的符号，http://example.com/ 是作为攻击目标的服务器，http://attacker.com/ 是攻击者的站点。如果http://example.com/ 开启了使用 JSONP 或 CORS 发送请求的可能性，那么它确实可能容易受到我刚才描述的 CSRF/XSRF 攻击。但这并不意味着其他网站会容易受到攻击。同样，如果http://attacker.com/ 开启了使用 JSONP 或 CORS 发送请求的可能性，那么攻击者的站点就会容易受到 CSRF/XSRF 攻击。因此，被误导的服务器管理员可能会在他自己的站点中打开一个漏洞，但不会影响其他站点的安全。