5

I have been dealing with some confusions on the same-origin policy.

Let's say my attack looks like this. On page at evil.com the attacker has put (jQuery):

$.post('http://bank.com/transfer', { to: 'ciro', ammount: '100' })

The attacker then convinces you to visit evil.com.

Will this payload (jQuery) still execute? Would it send a request or throw an error without sending the request?

I am comparing this with XMLHttpRequest where the request at least goes but the response is not allowed to be read because of same-origin policy violations. In case of SOP violation, does the request always travel to the server? Are there any cases where SOP prevents the request from being sent and catches it before?

Arminius
  • 43,922
  • 13
  • 140
  • 136
H4X
  • 161
  • 1
  • 7

1 Answers1

9

Would it send a request or throw an error without sending the request?

Your POST request would be sent. However, the same-origin policy prevents that are you are able to read the response. Just like an ordinary form submission, it's a type of cross-origin write. Here is an overview from Mozilla:

  • Cross-origin writes are typically allowed. Examples are links, redirects and form submissions. Certain rarely used HTTP requests require preflight.
  • Cross-origin embedding is typically allowed. Examples are listed below.
  • Cross-origin reads are typically not allowed, but 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.

In your scenario, the request would trigger an involuntary action (a bank transfer). This type of attack is called cross-site request forgery (CSRF). To prevent these, developers have to actively take countermeasures such as implementing CSRF tokens.

Are there any cases where SOP prevents the request from being sent and catches it before?

Yes. For example, you cannot specify methods other than GET, POST and HEAD by default. Other methods need to be explicitly allowed using a technique called cross-origin resource sharing (CORS). That's why custom methods are sometimes used as a (questionable) alternative to CSRF tokens.

To allow a custom method FOO from any origin, the server could reply with these headers:

Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: FOO

Here is how Google Chrome rejects a request with the method FOO to https://www.google.com:

enter image description here

You can see that the browser first sends a preflight OPTIONS request to check which methods are permitted via CORS. The server then replies with a 405 status indicating that FOO is not allowed - and the entire request fails.

Community
  • 1
Arminius
  • 43,922
  • 13
  • 140
  • 136
  • Hi Arminius ,this is perfect , thank you so much for helping me out. – H4X Dec 11 '16 at 05:28
  • So same origin policy doesn't protect against evil.com sending a POST request that might alter state for the victim on bank.com (even though evil.com won't be able to read the response)? – M3RS Aug 25 '22 at 08:29
  • 1
    @M3RS Exactly! That's why techniques like CSRF tokens are necessary. In that case the bank would check if the POST request contains a specific secret value before altering the state. – Arminius Aug 25 '22 at 16:38