Building a safer Internet with the SOP for developers.

In one sentence, the Same-Origin Policy is this: A script from one page can only access data from another page if they have the same origin.

Good cookies, bad cookies

Let’s take a look at an example. Modern web applications often base their authentication on cookies, which the browser automatically includes when sending requests to the same server. This system makes session persistence a breeze, but it also comes with a critical flaw.

Imagine if you are logged in into an online bank at bank.com, and at the same time, you are visiting a malicious site, attacker.com, in the same browser. If the SOP doesn’t exist, a script hosted on attacker.com can generate requests to access your information on bank.com. Your browser would automatically include your bank.com cookies in every request it sends to the bank, even if the request originated from attacker.com, a malicious domain. The malicious domain can therefore harvest sensitive data using the cookies included by your browser.

Here is where the SOP comes into play: SOP will prevent the malicious script hosted on attacker.com from reading the data returned from bank.com. This is one of the fundamental defenses deployed in the modern Internet and is critical in preventing many potential attacks.

Who has the same origin?

Two pages are said to have the same origin if they share the same protocol, hostname, and port number. Let’s say that a page is at:

• https://shiftleft.io/

Which of these following pages would be of the same origin as this page?

• https://shiftleft.io/learn
• http://shiftleft.io/learn
• https://twitter.com
• https://shiftleft.io:8080/learn

Only the first page has the same origin because it shares the same protocol, hostname, and port number as https://shiftleft.io/. The second URL uses a different protocol, the third one is of a different hostname, and the fourth one differs in the port number.

Relaxing the SOP

Although the SOP is fantastic from a security standpoint, it is often way too restrictive for the complex functionalities of modern web applications. For example, multiple subdomains or multiple domains of the same organization would not be able to share information! Thankfully, there are ways for you to work around SOP.

document.domain

The first option is to set the “document.domain” of the cross-domain pages with a script. For example, setting the domain of both a.domain.com and b.domain.com to domain.com will allow them to share data.

The main limitation of this approach is that you can only set the document.domain of a page to a parent domain, so this will only work for sharing information between subdomains of the same domain.

Cross-domain messaging: postMessage()

PostMessage is another way of working around SOP. In this technique, you share data with a cross-origin page by sending text-based messages using the “Window.postMessage()” method. The receiving window then handles the message using an “onmessage” event handler.

Since using postMessage() requires the sender to obtain the window object of the receiver, this method only allows data sharing between a window and its iframes or popups.

JSON with Padding

JSON with Padding, or JSONP, is another technique that works around SOP.

The SOP does not limit javascript code, and the HTML <script> tag is allowed to load Javascript code from any origin. So an easy way of sharing data across origins is to load it as Javascript code. However, because most data are not valid Javascript, simply including data within script tags will cause syntax errors. JSONP refers to the practice of wrapping JSON data in a Javascript function. Then a script located at a different origin can read the JSON data by loading the Javascript code and processing the function.

JSONP implementations tend to be prone to security issues. Now that CORS is an option, you should avoid using JSONP.

Cross-origin resource sharing

Cross-origin resource sharing, or CORS, is the best practice for controlled SOP bypass. In most cases, this is the option you should go for.

CORS allows servers to explicitly specify the list of origins allowed to access its data via the Access-Control-Allow-Origin header. For instance, you can serve the page with this header to allow pages from https://twitter.com to access the data contained on the current page.

Access-Control-Allow-Origin: https://twitter.com

And that’s the basics of the same-origin policy! The SOP is an important defense mechanism of the modern Internet. When SOP bypasses are necessary, implementing them securely is the key to protecting your users’ data.

Want to learn more about application security? Take our free OWASP top ten courses here: https://www.shiftleft.io/learn/.

What other security concepts do you want to learn about? I’d love to know. Feel free to connect on Twitter @vickieli7.

What is the Same-Origin Policy? was originally published in ShiftLeft Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

*** This is a Security Bloggers Network syndicated blog from ShiftLeft Blog - Medium authored by Vickie Li. Read the original post at: https://blog.shiftleft.io/what-is-the-same-origin-policy-f5e365adad7e?source=rss----86a4f941c7da---4