Does SOP prevent a class of CSRF attacks?

Question

Just want to settle a debate I'm having with someone.

Suppose there is no SOP. Via an XSS exploit, code can run on website A.com and submit an XHR request to B.com. Suppose B.com stores an auth token in an HTML page (maybe to interface with WASM/Flash/Java applet) and this data is read. Then CSRF can be used with this auth token to say change a users password on B.com.

Clearly its true that SOP will prevent this attack from happening (assuming there's no CORS setup to allow this)

This means that "SOP" prevents the class of CSRF attack I've described.

Is this true? Yes? No?

Answer 1

SOP mostly does not stop CSRF - the entire point of CSRF is that it's an attack you can make despite SOP, and which (unlike XSS) doesn't require an injection vulnerability - but in some cases SOP does prevent CSRF that would otherwise be possible.

So YES, SOP prevents some classes of CSRF.

---

SOP obviously doesn't stop CSRF in general - after all, all browsers worth mentioning implement SOP, and yet CSRF is still a concern - because of the ways that cookies do not fully follow SOP. In particular, SOP prevents site X from reading or setting the cookies of site Y, but it does not prevent X from using site Y's cookies. The new samesite flag for cookies partially mitigates this, but the "site" that is used for considering a cookie is much more inclusive than the origin used for SOP (anything that is a different site is a different origin, but the reverse is not true; subdomains, different ports, and different protocols can all be part of the same site despite being different origins).

Given the above, you might think that any site or service using cookies for authentication/session tokens is at risk of CSRF (especially if it doesn't use samesite cookies, but plausibly even if it does). However, that's not entirely true. There are a few cases where SOP can prevent CSRF without requiring specific anti-CSRF mitigations; if a web service endpoint has any of the following:

• requires a custom request header
• specifies a content type other than the ones you can send with an HTML form
• requests access to response headers

this will trigger a pre-flight request for cross-origin script-initiated requests. Assuming CORS is not (mis)configured to allow such requests - CORS being a way to selectively relax SOP - the browser won't send them. Note that authenticated cross-origin scripted requests (e.g. withCredentials=true) are not necessarily pre-flighted, and the server may well process them even if it then returns a response that doesn't have the CORS headers necessary for the browser to read the response body.

Furthermore, SOP is an essential tool in the mitigations against CSRF. Consider the usual ways of preventing CSRF (aside from "ensure every request would require a pre-flight"):

• anti-CSRF token served in the DOM (e.g. in a hidden field); without SOP the attacker could read it out of the DOM themselves via a GET request
• double-submit cookie containing an anti-CSRF token not sent in the DOM; cookies not being readable or settable by other sites is essential to this mechanism working.

Answer 2

Without SOP, CSRF attacks would be a lot more dangerous and rampant because of the exact scenario you describe. But it's important to note that SOP doesn't stop CSRF completely.

I'm going to go ahead and answer your question with a "YES"

Answer 3

No, SOP (Same-Origin Policy) does not prevent what is traditionally considered CSRF (Cross-Site Request Forgery). In fact, traditional CSRF payloads exploit an inherent weakness in the SOP, but mostly the way browsers handle storage. For functionality to be vulnerable to CSRF, said functionality must be mutative and state changing, because the response cannot be read.

What you're describing would almost certainly be considered a new classification of vulnerability, in fact, it would be complete and utter breach of cross-origin access controls, not CSRF.

Furthermore, the necessary condition for a CSRF vulnerability to exist is the usage of cookie-based session management or in other edge cases some sort of automatically populated identifier, such as IP addresses. With or without, the SOP does not prevent this. The fundamental flaw that enables CSRF exits because of the browsers nature to programmatically populate requests with session cookies (in the most common case); this is agnostic of the SOP.

Simply put, by definition and inspection of the name itself, "Cross-Site Request Forgery", the entire concept is we're forging an HTTP request, we aren't expecting an HTTP response, which is what the SOP thwarts. This is why CSRF targets mutative functionality, which doesn't require an HTTP response to cause damage.

One could argue the SOP prevents the scenario you're describing, however, the scenario you're describing doesn't conform to the consensus criteria necessary of the CSRF vulnerability classification. Also, if you're inducing someone's client to make an HTTP request elsewhere, the response would be returned to the client, not the attacker, even if the SOP didn't prevent cross-origin reads, the response would be lost. Other forms of complex requests require preflighting.

SOP implementation predates the classification of what the consensus considers a CSRF vulnerability. SOP was not designed or intended to prevent CSRF attacks. The necessary inherent flaws that enable the exploitation of what is consider a CSRF attack are not mitigated by SOP.