It’s not that hard to understand… in the cors threat model an attacker gets one your users to take an action on your site by visiting their site.
It’s not that hard to understand… in the cors threat model an attacker gets one your users to take an action on your site by visiting their site.
> in the cors threat model an attacker gets one your users to take an action on your site by visiting their site
This is really oversimplifying things, incorrectly IMO, and that sentence makes it sound like you're confusing a CSRF vulnerability with CORS protections. Normally when you write a backend server you implement some sort of authentication and access control, and in that scenario the threat model that lets "an attacker gets one your users to take an action on your site by visiting their site" is a CSRF vulnerability, unrelated to CORS.
The scenario presented in TFA is actually a very special case, because the bug is with a webserver running on localhost that doesn't (apparently) implement access control - not something most web apps entail.
In fact, one of the parts that confuses a lot of people is that CORS rules only prevent the JavaScript web client from reading the response from a remote endpoint - if the endpoint is available on the public Internet then anyone can still make a request to it.
The other thing that is confusing about CORS is that browsers already let you load lots of resources from cross origin servers - you can load images (as TFA points out that Zoom did as a workaround), scripts, stylesheets, form submissions, etc. The one thing you can't do, unless the server implements the appropriate CORS headers, is make a cross origin fetch request from JavaScript.
All CORS does is allow for selective loosening of anti-CSRF controls. CORS is a mechanism for a service to tell a client “I’m CSRF-resistant” so that that the client doesn’t need to protect its user as tightly when interacting with that service.
Isn't CSRF about forging mutating requests? CORS doesn't block the underlying GET/POST request, the request still goes through and the server still needs to properly implement CSRF prevention. CORS just prevents javascript from reading the response.
CORS _additionally_ requires OPTIONS pre-flight to succeed, before allowing any kind of request outside of what can be achieved with a HTML form submit action. So it blocks PUT/PATCH/DELETE, specifying most Content-Type, and specifying nearly all other headers. But this is just blocking "non-standard complex requests that might confuse badly programmed pre-javascript-era servers".
It passes all standard requests that you could have made by: embedding the url as an image src, the target of a HTML form, endpoint for csp reports, etc. All still need to be checked methodically by the server for CSRF if it's going to take any mutating action due to the request.
CSRF can compromise the non-mutating path as well to exfiltrate data, but the mutating path and non-mutating are different, hence the OPTIONS preflight required prior to sending mutating requests.
The browser enforces the same-origin policy by preventing read on non-mutating (i.e. “simple”) request responses and preventing sending of mutating requests (i.e. non-“simple”). CORS provides a protocol for a service to loosen these controls.
> CORS doesn't block the underlying GET/POST request
It does block ALL requests for certain content types.
In the common cross origin case of a JSON API, CSRF beyond CORS is unnecessary.
> CORS rules only prevent the JavaScript web client from reading the response
To nitpick, it’s the same origin policy that does that.
> CORS rules only prevent the JavaScript web client from reading the response from a remote endpoint
Assuming the web client plays nicely. I commonly bypass CORS for playwright unit/E2E testing.
No? CORS is about preventing an unauthorized third party from _accessing_ data. That’s the meaning of “resource sharing.” If you want to prevent action-taking, there are other mechanisms. For example, using a header-based CSRF token if your auth scheme relies on cookies.
It’s easy to understand but most people don’t naturally think of ways people try to break in. Without thinking about that, the importance of security is low.
It isn’t a knowledge thing (though it could be), or a capability thing, or intelligence. It’s pure mindset.
Ask yourself: is the average person noticing holes in fences and trying random doorknobs… probably not.
But on the other hand, most security people don’t think of product or UX (but some might) so that’s why you have roles.
> Ask yourself: is the average person noticing holes in fences and trying random doorknobs… probably not.
Yes. Especially kids, and by extension, parents of kids. Also teenagers. And people without means. And clever competition. And people with above-average levels of curiosity. And yes, criminals too.
I'd describe it from a different perspective: most people assume their problems are obviously solvable through an available service, and if they aren't, then either they need to delegate it to specialists or the problem itself is invalid. The minority of people who are into solving problems themselves are, at a high level, hard to distinguish from small kids, teenagers, and criminals, because they all share the characteristic of straying from the journey down the sales funnel, as they're pursuing their own goals and are not interested in getting to the bottom of that funnel.