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?
Changing Origin Occasionally, the same origin policy may block requests between subdomains on the same domain. The easiest way to solve this problem is to set document. domain from within JavaScript.
For example, it prevents a malicious website on the Internet from running JS in a browser to read data from a third-party webmail service (which the user is signed into) or a company intranet (which is protected from direct access by the attacker by not having a public IP address) and relaying that data to the attacker ...
The same-origin policy restricts which network messages one origin can send to another. For example, the same-origin policy allows inter-origin HTTP requests with GET and POST methods but denies inter-origin PUT and DELETE requests.
XSS is essentially a full SOP bypass because Javascript that runs on page A would operate under the security context of page A. This means that if an attacker is able to get a malicious script executed on the victim page, the script can access the page's resources and data.
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.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With