0

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?

9
  • I don't see a "class of CSRF" described here and you don't attempt to define such a class - instead you only provide a single example. You are basically describing getting relevant information from A using XSS, i.e. one could extract this auth token from HTML with XSS. There is no need then to trigger an XHR from A too, but instead one could do such a request using other agents which are not restricted by SOP in the first place (i.e. script not browser). Oct 18, 2021 at 5:55
  • @SteffenUllrich You can send a POST request with XHR even with SOP, you just wont be able to read the response. The class of CSRF described here is where you read some data from a remote origin (step 1) then use that data in the CSRF (step 2). Other posters agree that SOP stops these cases. I think it can be fair to hence say that SOP helps mitigate / protects against some classes of CSRF attacks. Do you agree?
    – Jamal
    Oct 18, 2021 at 21:48
  • 1
    SOP prevents non-simple XHR, i.e. for example with a custom Authorization header. It prevents the attack as described by you, but it does not prevent using the stolen authentication token to be used outside the browser - because SOP is only a feature of the browser. I don't consider this a class of CSRF since the main point is the XSS here - to get the token. The CSRF is not even needed here since the stolen token can be used outside the browser. Oct 18, 2021 at 22:07
  • @SteffenUllrich In my example SOP will stop the XSS request from fetching the stolen authorization token. You're saying that you can just steal the token and use an outside script to manipulate the web service, hence CSRF isnt necessary. But what if the web service also requires an IP address, browser fingerprint, etc in addition to the token? You cannot use an external script then. This would be considered a textbook example of CSRF by OWASP. Do you agree?
    – Jamal
    Oct 18, 2021 at 22:11
  • 1
    @Jamal: sorry, I've read your description a bit wrong, assuming that the token was extracted from A. Anyway, the point of a CSRF attack is the execution of a cross site request. This cross site request is still executed. The point of SOP here is to prevent the reading of the response and SOP successfully does it. Thus it prevents the full execution of the multi-step attack, but it does not prevent the CSRF itself. It only prevents the CSRF to cause more harm. Seat belts (SOP) don't prevent a class of accidents (CSRF), but they reduce the impact (steal data from response). Oct 19, 2021 at 4:07

3 Answers 3

4

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.
0

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"

1
  • 1
    are you able to expand your answer to explain why the same-origin policy doesn't stop CSRF completely?
    – brynk
    Oct 18, 2021 at 3:01
-1

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.

3
  • I agree that SOP doesn't stop CSRF completely. I don't think that's the question though. I'm asking if SOP prevents some classes of CSRF attacks eg what I've described. I think @CBHacking brought up some examples too which SOP helps mitigate against like anti-CSRF tokens or double-submit cookies.
    – Jamal
    Oct 18, 2021 at 21:46
  • What you described is not a class of CSRF. If SOP didn't exist, it could be considered a new form of CSRF, sure, but if SOP didn't exist, there would be a plethora of security shortcomings within a grocery list of browser functionalities. Calling it CSRF would be an understatement. "If my grandmother had wheels, she would be a bicycle"
    – Poppy
    Oct 18, 2021 at 21:49
  • Your requirement of "cookie-based session management" is only found on a portswigger tutorial. OWASP definition includes other examples of authentication such as IP address, etc. And if we use logic and look at the name "Cross Site Request Forgery" surely we can agree the requirement you listed is not indeed a requirement but just one possible example and hence your argument is frivolous?
    – Jamal
    Oct 18, 2021 at 21:55

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.