21–30 of 285 posts
I log in to social.net. I click on scam.org and change sites. I'm on scam.org and it triggers a request to social.net/friends.
No cookies are sent, no JWT. I'm not logged in and get a "Needs login" HTTP error. Nothing bad happens.
I thought that's how it works without CORS already.
I bet there's an awful lot of servers out there that will happily take CORS requests from any host because someone didn't understand why their second domain couldn't talk to the same API.
Count me in!
I still don't understand the threat model and, obviously, it's not explained here either. I log in to social.net. I click on scam.org and change sites. I'm on scam.org and it triggers a request to social.net/friends. No cookies are sent, no JWT. I'm not logged in and get a "Needs login" HTTP error. Nothing bad happens. I thought that's how it works without CORS already.
I still don't understand the threat model and, obviously, it's not explained here either. I log in to social.net. I click on scam.org and change sites. I'm on scam.org and it triggers a request to social.net/friends. No cookies are sent, no JWT. I'm not logged in and get a "Needs login" HTTP error. Nothing bad happens. I thought that's how it works without CORS already.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Coo...
It's not just CORS that's hard to understand. Many (most?) developers don't really understand the threat model. And even when it's explained it hard to see why it's a big deal. Part of this is that backend developers usually have to configure CORS and it's not an access privilege protection. From the point of view of the backend it doesn't seem to matter. Bad guys can't get it. From the point of view of the front-end…
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.
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.
contractors, "specialists", etc. who never took the time to read how CORS works and how simply you can handle a list of allowable sites, etc.
it's only complicated until you take the 5-10 minutes to properly understand what happens where. if you don't know, go do it now.