1

As said here, a CSRF attack has little to do with SOP. However, on the OWASP CSRF page it is said that

Fortunately, this request will not be executed by modern web browsers thanks to same-origin policy restrictions. This restriction is enabled by default unless the target web site explicitly opens up cross-origin requests from the attacker's (or everyone's) origin by using CORS with the following header:

And also when I tried to do Fetch / XMLHttpRequest, when it's blocked by SOP, the request didn't even get to my server, so is the answer in the first link above still valid? Thanks

tim
  • 29,018
  • 7
  • 95
  • 119
Sumanto Dinar
  • 11
  • 1

1 Answers1

1

The same origin policy allows:

  • Cross-origin writes are typically allowed. Examples are links, redirects, and form submissions. Some HTTP requests require preflight.
  • Cross-origin embedding is typically allowed. (Examples are listed below.)
  • Cross-origin reads are typically disallowed, but read access is often leaked by embedding. For example, you can read the dimensions of an embedded image, the actions of an embedded script, or the availability of an embedded resource.

The important part here is "typically" and "Some HTTP requests require preflight".

This means that you cannot perform eg PUT requests even though they are "write" actions, because they require preflight.

Which is also what the OWASP article says: You can't use CSRF with other HTTP methods than GET and POST.

Incidentally, you can use xmlhttprequest to send out POST requests:

// hosted on evil.com:
<script>
var xhr = new XMLHttpRequest();
xhr.open('POST', 'http://example.com/test.php', true);
xhr.send("test");
</script>

This will show an error in your browser console about a SOP violation. But the violation is not the POST request (which will be issued), but the potential of reading out the response (which is not allowed).

As the SOP doesn't forbid write actions, it doesn't really relate to CSRF (which is all about write actions). It does however interfere with some CSRF attacks (eg PUT requests or requests with custom headers), so the SOP can be used in CSRF-prevention (eg by checking a custom header or only using PUT requests).

tim
  • 29,018
  • 7
  • 95
  • 119
  • Thanks for the answer, unfortunately I need more explanation about why an SOP-blocked request did not get to my server. I'm using fetch with GET as the verb. – Sumanto Dinar Sep 08 '19 at 13:33
  • @SumantoDinar If you were making a simple GET request then SOP would not have blocked it from arriving at your server. You can verify this in your browser's network requests. Likely there is something else that is causing confusion. Note that in all situations your server would have at least received the OPTIONS pre-flight request. Therefore, if you don't see anything traffic reaching your server at all, then something else unrelated to SOP is wrong. – Conor Mancone Oct 17 '19 at 13:41