Same origin policy

From Wikipedia, the free encyclopedia

In computing, the same origin policy is an important security measure for client-side scripting (mostly JavaScript). The policy dates from Netscape Navigator 2.0, with necessary coverage fixes in Navigator 2.01 and Navigator 2.02. It prevents a document or script loaded from one "origin" from getting or setting properties of a document from a different "origin".

Contents

[edit] Access restriction

The philosophy of the same origin policy is simple: the browser should not trust content loaded from arbitrary websites. Web pages run within the sandbox are prevented from accessing resources from other origins. Without this protection, a malicious web page could compromise the confidentiality or integrity of another web page.

The term "origin" is defined using the domain name, protocol and port. Two pages belong to the same origin if and only if these three values are the same. To illustrate, the following table gives examples of origin comparisons to the URL "http://www.example.com/dir/page.html".

URL Outcome Reason
http://www.example.com/dir2/other.html Success Same protocol and host
http://www.example.com/dir/inner/other.html Success Same protocol and host
http://www.example.com:81/dir2/other.html Failure Same protocol and host but different port
https://www.example.com/dir2/other.html Failure Different protocol
http://en.example.com/dir2/other.html Failure Different host
http://example.com/dir2/other.html Failure Different host

By using relative URLs and limiting the use to URLs in the same origin, this restriction can be easily avoided.

[edit] Overcoming access restriction

It is possible to "overcome" this restriction by signing the script. However, in practice signed script is rarely used. This is mainly because Internet Explorer does not support signed scripts, and not everyone can afford a widely recognized digital signature, especially not casual web developers. Even if the script is signed, a prompt window would appear whenever the script required access to extended privileges. This is another security measure (as a signed script is by no means a script that can be trusted): it is trusted that the script comes from that origin, but it is still unknown what the script actually does.

The same-origin policy is overcome when user save the untrusted HTML files and run them from the local filesystem. This makes it possible for a locally-run HTML file to, for instance, retrieve data from the local filesystem. The information here and here explain some of the potential problems, however applications such as TiddlyWiki use this ability to save changes locally and simplify the XMLHttpRequest process.

It is also possible to implement a proxy script on the server.

[edit] JSON

For more details on this topic, see JSON#Cross-site request forgery.

While it is not possible to directly query websites for data due to the same origin policy, the <script> tag does not honor the same-origin policy and can be used in conjunction with JSON.

[edit] DNS rebinding

Main article: DNS rebinding

The DNS basis of the same origin policy can be subverted by setting a very low TTL at an attacker's DNS server and returning forged responses to subsequent DNS requests.

[edit] Session hijack

Main article: Cross-site request forgery

The same-origin policy doesn't restrict posting data (via POST or GET method). The javascript can still send HTTP POST/GET request to any domain, but it just can't access the contents of the data return from that request (because of same-origin policy). The stored cookies will be sent along with that HTTP request. It can then hijack the cookies session, and do any transaction blindly.

Some web applications, prevent this session hijack by adding another credential token into the request form. This token is embeded in HTML, and can't be read by the script on the other domain due to same-origin policy. The field wpEditToken in the edit form of MediaWiki software is an example of this.

[edit] Vendor adoption

This policy is used in modern web browsers that support client-side scripting. Internet Explorer uses an alternative approach of security zones in addition to the same-origin (or "same-site") policy. By default in Internet Explorer, internet web sites are restricted to their site-of-origin, but the user may choose to allow local intranet sites (or sites that they have explicitly trusted) to access data across domains (up to Internet Explorer 5). This is useful for certain types of applications that need to aggregate data from multiple sites, such as trusted internal portals.

[edit] See also

[edit] External links

Languages