Same-origin policy

In computing, the same-origin policy (sometimes abbreviated as SOP) is an important concept in the web application security model. Under the policy, a web browser permits scripts contained in a first web page to access data in a second web page, but only if both web pages have the same origin. An origin is defined as a combination of URI scheme, host name, and port number. This policy prevents a malicious script on one page from obtaining access to sensitive data on another web page through that page's Document Object Model.

HTTP
Request methods
Header fields
Status codes
Security access control methods
Security vulnerabilities

This mechanism bears a particular significance for modern web applications that extensively depend on HTTP cookies[1] to maintain authenticated user sessions, as servers act based on the HTTP cookie information to reveal sensitive information or take state-changing actions. A strict separation between content provided by unrelated sites must be maintained on the client-side to prevent the loss of data confidentiality or integrity.

It is very important to remember that the same-origin policy applies only to scripts. This means that resources such as images, CSS, and dynamically-loaded scripts can be accessed across origins via the corresponding HTML tags[2] (with fonts being a notable exception[3]). Attacks take advantage of the fact that the same origin policy does not apply to HTML tags.

History

The concept of same-origin policy was introduced by Netscape Navigator 2.02 in 1995,[4] shortly after the introduction of JavaScript in Netscape 2.0[5][6]. JavaScript enabled scripting on web pages, and in particular programmatic access to the Document Object Model (DOM).

The policy was originally designed to protect access to the DOM, but has since been broadened to protect sensitive parts of the global JavaScript object.

Implementation

All modern browsers implement some form of the same-origin policy as it is an important security cornerstone.[7] The policies are not required to match an exact specification [8] but are often extended to define roughly compatible security boundaries for other web technologies, such as Microsoft Silverlight, Adobe Flash, or Adobe Acrobat, or for mechanisms other than direct DOM manipulation, such as XMLHttpRequest.

Origin determination rules

The algorithm used to calculate the "origin" of a URI is specified in RFC 6454, Section 4. For absolute URIs, the origin is the triple {scheme, host, port}. If the URI does not use a hierarchical element as a naming authority (see RFC 3986, Section 3.2) or if the URI is not an absolute URI, then a globally unique identifier is used. Two resources are considered to be of the same origin if and only if all these values are exactly the same.

To illustrate, the following table gives an overview of typical outcomes for checks against the URL "http://www.example.com/dir/page.html".

Compared URL Outcome Reason
http://www.example.com/dir/page2.html Success Same scheme, host and port
http://www.example.com/dir2/other.html Success Same scheme, host and port
http://username:password@www.example.com/dir2/other.html Success Same scheme, host and port
http://www.example.com:81/dir/other.html Failure Same scheme and host but different port
https://www.example.com/dir/other.html Failure Different scheme
http://en.example.com/dir/other.html Failure Different host
http://example.com/dir/other.html Failure Different host (exact match required)
http://v2.www.example.com/dir/other.html Failure Different host (exact match required)
http://www.example.com:80/dir/other.html Depends Port explicit. Depends on implementation in browser.

Unlike other browsers, Internet Explorer does not include the port in the calculation of the origin, using the Security Zone in its place.[9]

Security applications

The same-origin policy helps protect sites that use authenticated sessions. The following example illustrates a potential security risk that could arise without the same-origin policy. Assume that a user is visiting a banking website and doesn't log out. Then, the user goes to another site that has some malicious JavaScript code running in the background that requests data from the banking site. Because the user is still logged in on the banking site, the malicious code could do anything the user could do on the banking site. For example, it could get a list of the user's last transactions, create a new transaction, etc. This is because the browser can send and receive session cookies to the banking site based on the domain of the banking site.

The user visiting the malicious site would expect that the site he or she is visiting has no access to the banking session cookie. While it is true that the JavaScript has no direct access to the banking session cookie, it could still send and receive requests to the banking site with the banking site's session cookie. Because the script can essentially do the same as the user would do, even CSRF protections by the banking site would not be effective.

Relaxing the same-origin policy

In some circumstances, the same-origin policy is too restrictive, posing problems for large websites that use multiple subdomains. At first, a number of workarounds such as using the fragment identifier or the window.name property were used to pass data between documents residing in different domains. Modern browsers support multiple techniques for relaxing the same-origin policy in a controlled manner:

Data tainting

Netscape Navigator briefly contained a taint checking feature. The feature was experimentally introduced in 1997 as part of Netscape 3.[10] The feature was turned off by default, but if enabled by a user it would allow websites to attempt to read JavaScript properties of windows and frames belonging to a different domain. The browser would then ask the user whether to permit the access in question.[11][12]

document.domain property

If two windows (or frames) contain scripts that set domain to the same value, the same-origin policy is relaxed for these two windows, and each window can interact with the other. For example, cooperating scripts in documents loaded from orders.example.com and catalog.example.com might set their document.domain properties to “example.com”, thereby making the documents appear to have the same origin and enabling each document to read properties of the other. Setting this property implicitly sets the port to null, which most browsers will interpret differently from port 80 or even an unspecified port. To assure that access will be allowed by the browser, set the document.domain property of both pages.[13]

The document.domain concept was introduced as part of Netscape Navigator 3,[14] released in 1996.[10]

Cross-Origin Resource Sharing

The other technique for relaxing the same-origin policy is standardized under the name Cross-Origin Resource Sharing. This standard extends HTTP with a new Origin request header and a new Access-Control-Allow-Origin response header.[15] It allows servers to use a header to explicitly list origins that may request a file or to use a wildcard and allow a file to be requested by any site. Browsers such as Firefox 3.5, Safari 4 and Internet Explorer 10 use this header to allow the cross-origin HTTP requests with XMLHttpRequest that would otherwise have been forbidden by the same-origin policy.

Cross-document messaging

Another technique, cross-document messaging allows a script from one page to pass textual messages to a script on another page regardless of the script origins. Calling the postMessage() method on a Window object asynchronously fires an "onmessage" event in that window, triggering any user-defined event handlers. A script in one page still cannot directly access methods or variables in the other page, but they can communicate safely through this message-passing technique.

JSONP
Main article: JSONP

Since HTML <script> elements are allowed to retrieve and execute content from other domains, a page can bypass the same-origin policy and receive JSON data from a different domain by loading a resource that returns a JSONP payload. JSONP payloads consist of an internal JSON payload wrapped by a pre-defined function call. When the script resource is loaded by the browser, the designated callback function will be invoked to process the wrapped JSON payload.

WebSockets
Main article: WebSocket

Modern browsers will permit a script to connect to a WebSocket address without applying the same-origin policy. However, they recognize when a WebSocket URI is used, and insert an Origin: header into the request that indicates the origin of the script requesting the connection. To ensure cross-site security, the WebSocket server must compare the header data against a whitelist of origins permitted to receive a reply.

Corner cases

The behavior of same-origin checks and related mechanisms is not well-defined in a number of corner cases such as for pseudo-protocols that do not have a clearly defined host name or port associated with their URLs (file:, data:, etc.). This historically caused a fair number of security problems, such as the generally undesirable ability of any locally stored HTML file to access all other files on the disk, or communicate with any site on the Internet.

Lastly, certain types of attacks, such as DNS rebinding or server-side proxies, permit the host name check to be partly subverted, and make it possible for rogue web pages to directly interact with sites through addresses other than their "true", canonical origin. The impact of such attacks is limited to very specific scenarios, since the browser still believes that it is interacting with the attacker's site, and therefore does not disclose third-party cookies or other sensitive information to the attacker.

Attacks in face of same-origin policy

Even when same-origin policy is in effect (without being relaxed by Cross-Origin Resource Sharing), certain cross-origin computer attacks can be performed. WebRTC can be used to find out the internal IP address of a victim.[16] If attempting to connect to a cross-origin port, responses cannot be read in face of same-origin policy, but a JavaScript can still make inferences on whether the port is open or closed by checking if the onload/onerror event fires, or if we get a timeout. This gives opportunities for cross-origin portscanning. Further, a JavaScript can even fingerprint services cross-origin by taking advantage of default files. For example, if a JavaScript loaded from the site evil.com attempts to open the file http://127.0.0.1/images/jenkins.png, and the onload event fires, then it can be inferred that the victim runs Jenkins on his own computer. This way, the attacker can find potentially vulnerable services for example on the internal network, even in face of same-origin policy. Should any service be vulnerable to Cross-site Request Forgery, they can even be compromised.[17]

gollark: So what was the problem?
gollark: Don't we all?
gollark: Honestly, there are 36 or so Greek letters and people use about 4.
gollark: Besides, as an iota male I don't actually care.
gollark: * alpha masculinity

See also

Further reading

References
  1. IETF HTTP State Management Mechanism, Apr, 2011
  2. Kemp, John (2011-02-04). "Security on the Web". Retrieved 2018-07-24. The same-origin policy states that a document from one unique origin may only load resources from the origin from which the document was loaded. In particular this applies to XMLHttpRequest calls made from within a document. Images, CSS and dynamically-loaded scripts are not subject to same-origin policy.
  3. "@font-face". MDN Web Docs. Retrieved 2018-07-24. Web fonts are subject to the same domain restriction (font files must be on the same domain as the page using them), unless HTTP access controls are used to relax this restriction.
  4. "Netscape 3.0 Handbook - Advanced topics". netscape.com. Archived from the original on 2002-08-08. Retrieved 2020-02-16. Navigator version 2.02 and later automatically prevents scripts on one server from accessing properties of documents on a different server.
  5. "JavaScript 1.0 - 1995". www.webdesignmuseum.org. Retrieved 2020-01-19.
  6. "Welcome to Netscape Navigator Version 2.0". netscape.com. 1997-06-14. Archived from the original on 1997-06-14. Retrieved 2020-02-16.
  7. "Browser Security Handbook, part 2". google.com. Retrieved 31 January 2014.
  8. "Same Origin Policy". W3C. Retrieved 31 January 2014.
  9. Lawrence, Eric. "IEInternals - Same Origin Policy Part 1". Retrieved 22 October 2013.
  10. "Netscape Navigator 3.0 - What's New". netscape.com. 1997-06-14. Archived from the original on 1997-06-14. Retrieved 2020-02-16.
  11. "JavaScript 1.3 Guide - Security". netscape.com. 2003-02-21. Archived from the original on 2003-02-21. Retrieved 2020-02-16.
  12. "JavaScript 1.3 Guide - Security". docs.oracle.com. Archived from the original on 2012-08-24. Retrieved 2020-02-16.
  13. LePera, Scott. "Cross-domain security woes". The Strange Zen Of JavaScript. Retrieved 4 April 2014.
  14. "Netscape 3.0 - JavaScript Handbook". netscape.com. Archived from the original on 2002-10-03. Retrieved 2020-02-16.
  15. Creating WSGI Middleware
  16. Finding out internal IP address with JavaScript
  17. Attacking the internal network from the public Internet using a browser as a proxy
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.