Same Origin Policy & Exemptions

Posted on Updated on


The Web Browser Security

The Web browsers defend against malicious code by imposing restrictions against certain features.

  • Arbitrary file operations in Client Side JavaScript  (File Operations only on a sandbox environment)
  • General purpose networking capabilities (Web Sockets with restrictions only to send a string message)
  • Open a new browser window, only on response to user-initiated event (mouse click)
  • Close other browser window, only on user confirmation.
  • Cannot set value property of HTML File Upload elements
  • A script cannot read the content of documents loaded from different servers than the document that contains the script (The same origin policy)

In this write-up I’ll focus on SOP (Same Origin Policy & its exemptions).

Same Origin Policy

The Same-Origin policy is a security restriction on the web content the JavaScript code can interact with.  It affects the below:

  • Access restrictions on DOM elements of the document loaded from other host
  • Scripted HTTP request to other host

This comes into effect when a web page contains <iframe> element or opens other browser windows.  In this case, a script can read only the properties of windows and documents that have the same origin as the document that contains the script.

What Is Same Origin?

The origin of the document is defined as the protocol, host and port of the URL from which the document was loaded.

  • Documents loaded from web servers have different origins
  • Documents loaded through different ports of the same have different origins
  • Documents loaded using different protocols (http, https etc.) have different origins, even if they come from same host.

The Script Origin

It is important to note that the origin of the script is not relevant to the same-origin policy, what is targeted here is the origin of the document in which the script is embedded.

For example, a script hosted by Host A is included in a web page served by Host B.  The origin of the script is Host B and the script has full access to the content of the document that contains it.  If the script opens a third window and loads a document from host C into it, the same-origin policy comes into effect and prevents the scripts from accessing the document.

The same-origin policy affects all the properties of the document object of the window or frame that was loaded from different host.  For example, if you script opened the window, your script can close it, but it cannot access the properties of the document.

Relaxing the Same-origin Policy

In some situations the same-origin policy becomes restrictive.  So, HTML5/JavaScript provides ways to work around the restrictions, yet keeping the security intact.

Domain

The same-origin policy poses problems large websites that use multiple sub domains.  For example, a script in a document from home.example.com might want to read properties of a document loaded from developer.example.com or scripts from order.example.com.  But as per Same-origin policy this is restricted.

If two windows  (or frames) contains 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”.

Cross Origin Resource Sharing (CORS)

CORS allows Web Servers to expose services to be accessed by 3rd party applications and Web Applications which are hosted across the internet.

The CORS is a (draft) standard that extends HTTP with a new Origin: request header and a new Access-Control-Allow-Origin response header.  It allows the 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 use this new header to allow the cross-origin HTTP requests with XMLHTTPRequest that would otherwise have been forbidden by the same-origin policy.

Cors

To keep it simple:

  • If the User Agent ( Web Browser) identifies that the XHR request is a cross origin request, then it will send a HTTP request with “Origin” header, before actually sending a Get or Post.  In the “Origin” it will put origin of its original host.
  • In the Web Server / Web Host, on receiving HTTP request with “Origin” header, it will look for its configuration, whether that particular “Origin” can be allowed to access the specific resource.  If it is allowed, it send the response with “Access-Control-Allow-Origin” header, updated with the host name. Also sends the list of allowed HTTP commands (eg. GET, PUT, POST & DELETE).

Further Reading:

Example: http://www.html5rocks.com/en/tutorials/cors/

Security Issues: https://code.google.com/p/html5security/wiki/CrossOriginRequestSecurity

CORS desevers a separate write up with more details.  I’ll do it soon.

Cross Document Messaging

This mechanism allows a script from one document to pass text message to a script in another document, irrespective of the script origin.

Calling the postMessage() method on a Window object results in the asynchronous delivery of a message event.

The onmessage event handler to receive and message sent using postMessage().

Summary

The same origin policy is enabled by default in all the industry standard browsers.  So, by using “domain”, CORS and Cross Document Messaging we can work around the limitations of SOP without compromising the security of the web browser.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s