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

Question

我在理解同源策略和“解决”它的不同方法时遇到了一些麻烦。
很明显，同源策略是作为一种安全措施而存在的，因此来自服务器/域的一个脚本无法访问来自另一个服务器/域的数据。
也很明显，有时能够打破此规则很有用，例如，mashup 应用程序访问来自不同服务器的信息以构建所需的结果。其中一种方法是 CORS。
1) 如果我没记错的话，CORS 允许 目标服务器通过在响应中添加一些标题对浏览器说“您可以从我自己那里获取数据/代码”。但是，如果这是正确的，这意味着恶意服务器可以只添加此 header ，并且浏览器将允许检索来自该服务器的任何可能有害的数据或代码。
2)另一方面，我们有 JSONP，允许我们在没有启用 CORS 的情况下从服务器检索任意代码或数据，从而避免了 SOP 的主要目标。因此，即使在浏览器中硬连线的 SOP 中，能够管理 JSONP 的恶意服务器也能够注入(inject)数据或代码。
所以我的问题是:
第二个论证正确吗？浏览器是否必须接受内容是服务器的决定吗？
第二个论证正确吗？再次，浏览器决定是否接受数据？
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 攻击。因此，被误导的服务器管理员可能会在他自己的站点中打开一个漏洞，但不会影响其他站点的安全性。