3

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?

6

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.

  • Hi Arminius ,this is perfect , thank you so much for helping me out. – H4X Dec 11 '16 at 5:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.