Why is the same origin policy so important?

Why is the same origin policy important?

Assume you are logged into Facebook and visit a malicious website in another browser tab. Without the same origin policy JavaScript on that website could do anything to your Facebook account that you are allowed to do. For example read private messages, post status updates, analyse the HTML DOM-tree after you entered your password before submitting the form.

But of course Facebook wants to use JavaScript to enhance the user experience. So it is important that the browser can detect that this JavaScript is trusted to access Facebook resources. That's where the same origin policy comes into play: If the JavaScript is included from a HTML page on facebook.com, it may access facebook.com resources.

Now replace Facebook with your online banking website, and it will be obvious that this is an issue.

What is the origin?

I can't really fully understand what same origin domain means. I know it means that when getting a resource from another domain (say a JS file) it will run from the context of the domain that serves it (like google analytics code), which means it can't modify the data or read the data on the domain that "includes the resource".

This is not correct: The origin of a JavaScript file is defined by the domain of the HTML page which includes it. So if you include the Google Analytics code with a <script>-tag, it can do anything to your website but does not have same origin permissions on the Google website.

How does cross domain communication work?

The same origin policy is not enforced for all requests. Among others the <script>- and <img>-tags may fetch resources from any domain. Posting forms and linking to other domains is possible, too. Frames and iframes way display information from other domains but interaction with that content is limited.

There are some approaches to allow XMLHttpRequest (ajax) calls to other domains in a secure way, but they are not well supported by common browsers. The common way to enable communication with another domain is JSONP:

It is based on a <script>-tag. The information, which shall be sent to another domain, is encoded in the URL as parameters. The returned JavaScript consists of a function call with the requested information as parameter:

<script type="text/javascript" src="http://example.com/
     ?some-variable=some-data&jsonp=parseResponse">
</script>

The dynamically generated JavaScript from example.com may look like:

parseResponse({"variable": "value", "variable2": "value2"})

What is Cross Site Scripting?

Cross Site Scripting is a vulnerability that allows an attacker to inject JavaScript code into a website, so that it originates from the attacked website from the browser point of view.

This can happen if user input is not sufficiently sanitised. For example a search function may display the string "Your search results for [userinput]". If [userinput] is not escaped an attacker may search for:

<script>alert(document.cookie)</script>

The browser has no way to detect that this code was not provided by the website owner, so it will execute it. Nowadays cross site scripting is a major issue, so there is work done to prevent this vulnerability. Most notable is the Content Security Policy approach.

What does that really mean? Can you please give me a real life example?

Attack example 1: Cross-Site Request Forgery (CSRF) with an HTML form

On page at evil.com the attacker has put:

<form method="post" action="http://bank.com/trasfer">
    <input type="hidden" name="to" value="ciro">
    <input type="hidden" name="ammount" value="100000000">
    <input type="submit" value="CLICK TO CLAIM YOUR PRIZE!!!">
</form>

Without further security measures, this would:

the request does get sent. The SOP does not forbid this request from being sent.
it includes authentication cookies from bank.com which log you in

It is the synchronizer token pattern, alone, even without the SOP, prevents this from working.

Synchronizer token pattern

For every form on bank.com, the developers generate a one time random sequence as a hidden parameter, and only accept the request if the server gets the parameter.

E.g., Rails' HTML helpers automatically add an authenticity_token parameter to the HTML, so the legitimate form would look like:

<form action="http://bank.com/transfer" method="post">
  <p><input type="hidden" name="authenticity_token"
            value="j/DcoJ2VZvr7vdf8CHKsvjdlDbmiizaOb5B8DMALg6s=" ></p>
  <p><input type="hidden" name="to"      value="ciro"></p>
  <p><input type="hidden" name="ammount" value="100000000"></p>
  <p><button type="submit">Send 100000000$ to Ciro.</button></p>
</form>

as mentioned at: https://stackoverflow.com/questions/941594/understanding-the-rails-authenticity-token/26895980#26895980

So if evil.com makes a post single request, he would never guess that token, and the server would reject the transaction!

See also: synchronizer token pattern at OWASP.

Attack example 2: Cross-Site Request Forgery (CSRF) with JavaScript AJAX

But then, what prevents the evil.com from making 2 requests with JavaScript, just like a legitimate browser would do:

XHR GET for the token
XHR POST containing the good token

so evil.com would try something like this (jQuery because lazy):

$.get('http://bank.com/transfer')
// Parse HTML reply and extract token.
$.post('http://bank.com/transfer', {
  to: 'ciro',
  ammount: '100000000',
  authenticity_token: extracted_token
})

This is where the SOP comes into play. Although the $.get and $.post do actually send the authenticated request just like the HTML form, the sender's browser prevents the JavaScript code from reading the HTML reply back, because the request was sent to a separate domain!

The Chromium developer console shows an error for it of type:

Access to XMLHttpRequest at 'http://bank.com' from origin 'http://evil.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

which has been asked at: https://stackoverflow.com/questions/20035101/why-does-my-javascript-code-get-a-no-access-control-allow-origin-header-is-pr

Why not just not send cross request cookies instead?

What if implementations had a rule like: "allow any request, but only send cookies on current domain XHR"? Wouldn't that be simpler?

But that would still allow for another type of attack: when authentication is based not on cookies, but on source (IP) of the request!

For example, you are in your company's intranet and from there you can access an internal server, which is not visible from the outside and serves secret data.

Are all cross-origin requests forbidden?

Even forgetting CORS, no, we do them every day!

From MDN:

Cross-origin writes are typically allowed: links, redirects and form submissions.

[My comment]: e.g., when you click a link, you often expected to go logged in to the website, and that requires making an authenticated GET request that returns the new page.
Cross-origin embedding is typically allowed: images, external CSS and Javascript, iframes.
Cross-origin reads are typically not allowed: XHR (example above), iframe read.

However, read access is often leaked by embedding. For example you can read the width and height of an embedded image, the actions of an embedded script, or the availability of an embedded resource (and thus possibly if the user is logged in or not on a given domain)

In particular, it would be possible to use a form in evil.com that makes an authenticated POST request to bank.com. This is why the SOP alone is not enough: the synchronizer token is also needed.

Why is the same origin policy so important?

Why is the same origin policy important?

What is the origin?

How does cross domain communication work?

What is Cross Site Scripting?

Tags:

Javascript

Same Origin Policy

Web Browser

Web Application

Related

Recent Posts