What does that really mean? Can you please give me a real life example?
Attack example 1: Cross-Site Request Forgery (CSRF) with AJAX
On page at evil.com the attacker has put (jQuery because lazy):
$.post('http://bank.com/transfer', { to: 'ciro', ammount: '100' })
The attacker then convinces you to visit evil.com (YOU'VE GAINED A PRIZE!)
Without further security measures, this would work because authentication cookies from bank.com would be sent and authenticate you.
But because of the SOP, the browser prevents this request from being made.
Attack example 2: CSRF with a form
On evil.com:
<form method="post" action="http://bank.com/trasfer">
<input type="hidden" name="to" value="ciro">
<input type="hidden" name="ammount" value="100">
<input type="submit" value="Click to see cat photos">
</form>
If the user clicks the submit button, the browser will permit this. The SOP alone does not forbid this type of use.
It is the combination of the SOP + synchronizer token pattern that prevents that from working.
Synchronizer token pattern
For every form on bank.com, 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="100"></p>
<p><button type="submit">Send 100$ to Ciro.</button></p>
</form>
So if evil.com makes a post single request, he would never guess that token, and the server would reject the transaction.
But then, what prevents the evil.com from making 2 requests:
- XHR GET for the token
- XHR POST containing the good token
This is where the SOP comes into play: step 1 is forbidden because it violates the SOP. The SOP prevents you from reading cross request data back into JavaScript. Step 2 however, is perfectly possible.
See also: synchronizer token pattern at OWASP.
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.
See also: CSRF at OSWAP.
Other prevention approaches
- check if certain headers is present e.g.
X-Requested-With:
- check the value of the
Origin header: Why is the synchronizer token pattern preferred over the origin header check to prevent CSRF
- re-authentication: ask user for password again. This should be done for every critical operation (bank login and money transfers, password changes in most websites), in case your site ever gets XSSed. The downside is that the user has to type the password multiple times, which is tiresome, and increases the chances of keylogging / shoulder surfing.
