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

Question

我很难理解同源策略和“解决”它的不同方法。

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

也很明显，有时打破这一规则是很有用的，例如mashup应用程序访问来自不同服务器的信息以构建所需的结果。做到这一点的方法之一是CORS。

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

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

所以我的问题是:

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

难道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" />

这种攻击以前针对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攻击。因此，信息错误的服务器管理员可能会在自己的站点上打开一个漏洞，但不会影响其他站点的安全。