同源政策和CORS - 有什么意义？ [英] same-origin policy and CORS - what's the point?

问题描述

我对理解同源策略以及解决方法的不同方法有些麻烦。


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


也很清楚，有时，能够打破这条规则很有用，因此示例mashup应用程序访问来自不同服务器的信息，以便建立所需的结果。这样做的一个方法是CORS。


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


2 ）另一方面，我们有JSONP，允许我们从服务器检索任意代码或数据，而不启用CORS，从而避免SOP的主要目标。所以再次，一个能够管理JSONP的恶意服务器能够注入数据或代码，即使在浏览器中硬连线的SOP。


所以我的问题是：


第二个参数是否正确？是服务器的决定是否浏览器必须接受内容？
第二个参数是否正确？这是不是在浏览器的决定是否接受数据？


不是JSONP呈现SOP无用？


感谢启发我！ ！

I have some trouble understanding the same-origin policy and the different ways to "workaround" it.

It is clear that the same-origin policy exists as a security measure, so one script that comes from a server/domain has no access to data coming from another server/domain.

It is also clear that sometimes, it is useful to be able to break this rule, so for example a mashup application accesses information from different servers in order to build up the results wanted. And one of the ways to do this is CORS.

1) If I'm not wrong, CORS allows the target server to say to the browser "it is ok for you to take data/code from myself" by adding some headers in the response. But, if this is correct, this means that a malicious server could just add this header and the browser would allow the retrieval of any data or code, potentially harmful, coming from that server.

2) On the other side, we have JSONP, allowing us to retrieve arbitrary code or data from a server without CORS enabled, thus avoiding the main goal of the SOP. So again, a malicious server able to manage JSONP is able to inject data or code even with the SOP hardwired in the browser.

So my questions are:

Is the second argumentation correct? Is it the decision of the server whether the browser must accept the contents? Is the second argumentation correct? It is, again, not in the browser's decision whether to accept or not data?

Does not JSONP render the SOP useless?

Thanks for enlightening me!!

推荐答案

这里需要注意的是，如果用户登录了网站 http://example.com/ 和请求 http://example.com/delete?id=1 删除用户的帖子，然后以下代码将删除该用户的帖子：

The important thing to note here is that if the user is signed in to a site http://example.com/ and the request http://example.com/delete?id=1 deletes a post by the user, then the following code will delete the user's post:

<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

This is called a CSRF/XSRF attack (cross-site request forgery). This is why most server-side web applications demand a transaction ticket: instead of http://example.com/delete?id=1 you have to do 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

...because it doesn't contain the txid parameter. Now, let's consider what happens if the site could be accessed using XmlHttpRequest. The script running on the user's browser could behind the user's back retrieve and parse http://example.com/pageThatContainsDeleteLink, extract the txid and then request http://example.com/delete?id=1&txid=SomethingTheUserCannotGuess

现在，如果XmlHttpRequest不能访问具有不同来源的站点，尝试检索txid的唯一方法是尝试做类似于：

Now, if XmlHttpRequest cannot access sites having a different origin, the only way to try to retrieve the txid would be to try to do something like:

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

...但它没有帮助，因为结果是一个HTML页面， JavaScript代码。因此，您可以在其他网站加入< script>：s，但不能通过XmlHttpRequest访问其他网站。

...but it doesn't help as the result is a HTML page, not a piece of JavaScript code. So, there's a reason why you can include <script>:s from other sites but not access other sites via XmlHttpRequest.

您可能有兴趣阅读： a href =http://haacked.com/archive/2008/11/20/anatomy-of-a-subtle-json-vulnerability.aspx/ =nofollow> http://haacked.com/archive /2008/11/20/anatomy-of-a-subtle-json-vulnerability.aspx/

You may be interested in reading this: http://haacked.com/archive/2008/11/20/anatomy-of-a-subtle-json-vulnerability.aspx/

这次攻击在当天对Gmail有效，允许您从在其他网站上运行的JavaScript代码获取用户的电子邮件。这一切都表明，WWW的安全模型是非常微妙，没有好好考虑。

This attack worked against Gmail back in the day and allowed you to fetch the user's mails from JavaScript code running on another site. This all shows that the security model of WWW is very subtle and not well thought of. It has evolved instead of being well-designed.

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

As for your question: you seem to think that the server http://example.com/ is the malicious one. That's not the case. Using the notations of my answer, http://example.com/ is the server that is the target of the attack, and http://attacker.com/ is the site of the attacker. If http://example.com/ opens up the possibility to send requests using JSONP or CORS, it is true that it may become vulnerable to the CSRF/XSRF attack I just described. But it does not mean that other sites would become vulnerable to the attack. Similarly, if http://attacker.com/ opens up the possibility to send requests using JSONP or CORS, the attacker's site just became vulnerable to a CSRF/XSRF attack. Thus, a misinformed server administrator may open up a hole in his own site but it doesn't affect the security of other sites.

这篇关于同源政策和CORS - 有什么意义？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！