What is the threat model for the same origin policy?

Question

http://en.wikipedia.org/wiki/Same_origin_policy

The same origin policy prevents a script from one site talking to another site. Wiki says it's an "important security concept", but I'm not clear on what threat it prevents.

I understand that cookies from one site should not be shared with another, but that can be (and is) enforced separately.

The CORS standard http://en.wikipedia.org/wiki/Cross-Origin_Resource_Sharing provides a legitimate system for bypassing the same origin policy. Presumably it doesn't allow whatever threat the same origin policy is designed to block.

Looking at CORS I'm even less clear who is being protected from what. CORS is enforced by the browser so it doesn't protect either site from the browser. And the restrictions are determined by the site the script wants to talk to, so it doesn't seem to protect the user from either site.

So just what is the same origin policy for?

Answer 1

The article @EricLaw mentions, "Same Origin Policy Part 1: No Peeking" is good.

Here's a simple example of why we need the 'same origin policy':

It's possible to display other webpages in your own webpage by using an iframe (an "inline frame" places another HTML document in a frame). Let's say you display www.yourbank.com. The user enters their bank information. If you can read the inner HTML of that page (which requires using a script), you can easily read the bank account information, and boom. Security breach.

Therefore, we need the same origin policy to make sure one webpage can't use a script to read the information of another webpage.

Answer 2

The purpose of the same origin policy is to avoid the threat of a malicious site M reading information from trusted site A using the authority (i.e. authorization cookies) of a user of A. It is a browser policy, not a server policy or an HTTP standard, and is meant to mitigate the risk of another browser policy—sending cookies from site A when contacting site A.

Note that there's nothing to stop M from accessing A outside of a browser. It can send as many requests as it wants. But it won't be doing so with the authority of an unknowing user of A, which is what might otherwise happen in the browser.

Also note that the policy prevents the M page from reading from A. It does not protect the A server from the effects of the request. In particular, the browser will allow cross-domain POSTS—cookies and all—from M to A. That threat is called Cross-Site Request Forgery; it is not mitigated by the Same Origin Policy and so additional measures must be provided to protect against it.

Answer 3

As an example, it prevents Farmville from checking the balance on your banking account. Or, even worse, messing with the form your are about to send (after entering the PIN/TAN) so they get all the money.

CORS is mainly a standard for web sites which are sure they do not need this kind of protection. It basically says "it's OK for a script from any web site to talk to me, no security can possibly be broken". So it really does allow things which would be forbidden by the SOP, on places where the protection is not needed and cross-domain web sites are beneficial. Think of meshups.