1

Per mine understanding, by default same origin policy(SOP) is enabled by default by all browsers. This means that a web browser permits scripts contained in a first web page to access data in a second web page, but only if both web pages have the same origin.

My question is do we need to handle CSRF attack separately with the CSRF token as SOP is in place. I see almost all websites mitigates it by CSRF token implementation buy why it is required when SOP is in place ?

I see another related cookie “SameSite=strict” at this blog to prevent CSRF . To me it looks like SOP which is provided by browser by default. So is it really required ?

Improve this question

1 Answer 1

Reset to default
2

The same origin policy does not prevent all authenticated cross site interactions. Specifically, cross origin writes and embeds are generally allowed, while reads are prevented:

  • Cross-origin writes are typically allowed. Examples are links, redirects, and form submissions.
  • Cross-origin embedding is typically allowed.
  • Cross-origin reads are typically disallowed, but read access is often leaked by embedding.

Many of the allowed cases are important for the web to function properly.

Chrome will still soon change to a default samesite=lax, which will eg prevent cross-site POST requests with cookies (and also most embeds such as images or iframes).

It will however not prevent other "write" type actions such as visiting links. So GET-based CSRF remains an option even with samesite=lax (not with samesite=strict though).

Because of this - and because you should not rely on the client having additional security features (users may eg use other browsers than Chrome), CSRF prevention is still necessary to be employed by each site (using samesite=strict may be used as CSRF prevention, though it may break if the site allows users to post/control a sub-set of HTML such as links, forms, images, etc, or if it has other vulnerabilities such as open redirects).

Improve this answer
4
  • Thanks. As you said read are disallowed(point 3) , does it mean browser will not even trigger the request to server for GET but will do it for other methods like POST/PUT/DELETE? What if someone returned response as part of POST request, will browser be ale to read it ? Another point is does not browser initiates the preflight request for any http method GET/POST/PUT/DELETE as part SOP and then server tells whether it allows it or not ?
    – user3198603
    Commented Jan 14, 2020 at 2:33
  • @user3198603 read/write here doesn't really correspond to the HTTP methods. A browser will trigger GET requests (simple example: a link; but an ajax GET request with no custom headers will also trigger; in either case you can't read the response though). Same with POST (either form submit or ajax). Preflight only happens for ajax PUT/DELETE or GET/POST with non-default headers. So if preflight triggers, the server can allow it via CORS to bypass the SOP. If preflight doesn't trigger, the request will be sent out (write), but the response cannot be read (read) because the browser disallows it.
    – tim
    Commented Jan 14, 2020 at 8:31
  • One last thing , you said in either case you can't read the response though Does it mean server will send the valid response but browser can not read it ? Does it also mean if I put any interceptor tool like burp b/w browser and server to intercept the response, tool can see the response but when it goes to browser it rejects it ?
    – user3198603
    Commented Jan 15, 2020 at 1:40
  • @user3198603 yes, exactly.
    – tim
    Commented Jan 15, 2020 at 8:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .