same-origin policy and CORS - what's the point?

Question

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!!

question from:https://stackoverflow.com/questions/29167428/same-origin-policy-and-cors-whats-the-point

Answer 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" />

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

Now the following attack won't work:

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

...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

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

...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.

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

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.

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.