Re:CORS Is Stupid
by jub0bs on Sunday August 25, 2024 @06:18AM
(#41346147)
I've written quite a bit about CORS on my blog and I'm the author of a CORS middleware for Go. I always enjoy reading people's takes (whether good, bad, or somewhere in the middle) on CORS. I'll bite.
> I’m going to talk about CORS and the same-origin policy as one thing and use the terms mostly interchangeably.
This, IMO, is a dangerous oversimplification that trips many practitioners up. As Anne van Kesteren (the main author of the Fetch standard, the de facto CORS specification) puts it: "CORS was never a defense" (source: https://x.com/annevk/status/948831079649169408). No metaphor is perfect, but if you think of the same-origin policy as a seatbelt, CORS is the release button that lets you unbuckle that seatbelt (in a controlled manner). All other things being equal, activating CORS makes you less (not more) secure.
> [CORS] provides both opt-out protections as an attempt to mitigate XSRF attacks against unaware or unmodified sites and opt-in protections for sites to actively protect themselves.
Since CORS isn't a defense, I'm not sure what "protections" the author is referring to. In fact, the "warning" box further down the post appears to contradicts the author's earlier claim.
> The problem [...]
That's a broad description of CSRF. But it omits the fact that CSRF doesn't necessarily involve credentials. One example: in some cases, for better or worse, it's the victim's position within a private network that determines whether s/he can access the resource. This is why browsers are seeing additional restrictions on requests to "less public" networks, along with a mechanism (a natural extension of the CORS protocol) to opt-in to such requests: https://wicg.github.io/private-network-access/#goals
> The solution [...]
This section is misguided. CORS doesn't provide additional restrictions compared to a time where the XHR API only supported same-origin requests. In fact, regardless of CORS, many CSRF attacks are still viable through the use of a POST HTML form and need not involve CORS at all.
> The best solution is to set up server-wide middleware that ignores implicit credentials on all cross-origin requests. This example strips cookies, if you use HTTP Authentication or TLS client certificates be sure to ignore those too.
True that CSRF mostly (but not exclusively) stems from browser-managed credentials (what the author calls "implicit credentials"). And Fetch metadata request headers are a nice addition and can be used as part of CSRF protection. But the proposed solution (stripping implicit credentials) is both ineffective (see https://jakearchibald.com/2021/cors/#remove-credentials) and needlessly complicated (why the need to strip "implicit credentials" if you can ignore them and simply code your server to exclusively rely on "explicit credentials"?).
> Explicit credentials
This section contains sound advice. Most (though, not all) CSRF attacks become unviable when authentication relies on client-managed credentials (or "explicit credentials", as the author calls them).
> SameSite cookies [...] You should set the SameSite=Lax attribute on all of your cookies which will cause the browser to omit them for cross-origin requests.
Here, the author plays fast and loose with terminology and conflates "origin" with "site", which can mislead practitioners into a false sense of security.
> It is important to remember that cookies are still included in top-level GET navigations.
Not only that but, even in Chromium-based browsers, which now default to SameSite=Lax, cookies that lack a SameSite attribute have a two-minute window (since their creation) during which they're included in top-level POST requests, and that behaviour can lead to abuse: https://medium.com/@renwa/bypass-samesite-cookies-default-to...
> [CORS] is about preventing the accidental reuse of implicit credentials.
> I’m going to talk about CORS and the same-origin policy as one thing and use the terms mostly interchangeably.
This, IMO, is a dangerous oversimplification that trips many practitioners up. As Anne van Kesteren (the main author of the Fetch standard, the de facto CORS specification) puts it: "CORS was never a defense" (source: https://x.com/annevk/status/948831079649169408). No metaphor is perfect, but if you think of the same-origin policy as a seatbelt, CORS is the release button that lets you unbuckle that seatbelt (in a controlled manner). All other things being equal, activating CORS makes you less (not more) secure.
> [CORS] provides both opt-out protections as an attempt to mitigate XSRF attacks against unaware or unmodified sites and opt-in protections for sites to actively protect themselves.
Since CORS isn't a defense, I'm not sure what "protections" the author is referring to. In fact, the "warning" box further down the post appears to contradicts the author's earlier claim.
> The problem [...]
That's a broad description of CSRF. But it omits the fact that CSRF doesn't necessarily involve credentials. One example: in some cases, for better or worse, it's the victim's position within a private network that determines whether s/he can access the resource. This is why browsers are seeing additional restrictions on requests to "less public" networks, along with a mechanism (a natural extension of the CORS protocol) to opt-in to such requests: https://wicg.github.io/private-network-access/#goals
> The solution [...]
This section is misguided. CORS doesn't provide additional restrictions compared to a time where the XHR API only supported same-origin requests. In fact, regardless of CORS, many CSRF attacks are still viable through the use of a POST HTML form and need not involve CORS at all.
If you're looking for something to blame, perhaps look to XMLHttpRequest Level 2 (https://www.w3.org/TR/2009/WD-XMLHttpRequest2-20090820/), which lifted some restrictions on cross-origin requests; don't blame CORS.
> The best solution is to set up server-wide middleware that ignores implicit credentials on all cross-origin requests. This example strips cookies, if you use HTTP Authentication or TLS client certificates be sure to ignore those too.
True that CSRF mostly (but not exclusively) stems from browser-managed credentials (what the author calls "implicit credentials"). And Fetch metadata request headers are a nice addition and can be used as part of CSRF protection. But the proposed solution (stripping implicit credentials) is both ineffective (see https://jakearchibald.com/2021/cors/#remove-credentials) and needlessly complicated (why the need to strip "implicit credentials" if you can ignore them and simply code your server to exclusively rely on "explicit credentials"?).
> Explicit credentials
This section contains sound advice. Most (though, not all) CSRF attacks become unviable when authentication relies on client-managed credentials (or "explicit credentials", as the author calls them).
> SameSite cookies [...] You should set the SameSite=Lax attribute on all of your cookies which will cause the browser to omit them for cross-origin requests.
Here, the author plays fast and loose with terminology and conflates "origin" with "site", which can mislead practitioners into a false sense of security.
Although valuable, SameSite is unfortunately no panacea, esp. if some of your subdomains are vulnerable to XSS or subdomain takeover. More on this topic elsewhere: https://jub0bs.com/posts/2021-01-29-great-samesite-confusion...
> Access-Control-Allow-Origin: *
The author seems to imply that such a header is safe in all contexts, but that's simply not the case: https://security.stackexchange.com/questions/227779/concrete...
> It is important to remember that cookies are still included in top-level GET navigations.
Not only that but, even in Chromium-based browsers, which now default to SameSite=Lax, cookies that lack a SameSite attribute have a two-minute window (since their creation) during which they're included in top-level POST requests, and that behaviour can lead to abuse: https://medium.com/@renwa/bypass-samesite-cookies-default-to...
> [CORS] is about preventing the accidental reuse of implicit credentials.
What? No.