321–330 of 366 posts
Apparently to work around some bug in Microsoft ISS server. But this has also greatly increased the performance hit from CORS under some common usage scenarios, which is sad.
http://lists.w3.org/Archives/Public/public-appformats/2008Ma...
Earlier quoted context omitted.
Is my take on this also generally correct? That it wouldn't have been a problem had cookies and such been designed to take into account the origin properly (and hence why it's unintuitive and catches people off-guard)?
If cookies were scoped to the (source, target) pair, then that would remove one of the main motivations for CORS, yes: evil.com would not be able to get any information from bank.com by making your browser make the request that they could not get by doing the request server-side. There's a second problem CORS kinda tries to solve, which is the ambient authority problem: services that run behind firewalls and assume t…
To be that guy... forget CORS. All localhost servers have a pinned public key. The zoom.us site has the private key. It passes along a signed request. The local server then validates the signature! How is that so hard? Oh wait, I just described CSRF!! Zoom, here is your egg. Now promptly smash it on your face; thank you.
1. Attacker installs zoom.
2. Attacker starts to join meeting foo.
3. zoom.us creates a signed request saying "join meeting foo" and gives it to Attaker.
4. Attacker takes that signed request and sends it from attacker.com to localhost inside Victim's browser.
5. Victim's zoom native app gets the request, validates the signature, and joins the meeting.
I think it can be modified to be safe if there's a key exchange between zoom.us and the native app, and zoom.us signs the key exchange with its private key. But this seems hugely overkill compared to a simple Origin check, or even compared to a traditional XSRF token (via a cookie on localhost).
How does not allowing CORS make any sense if any other application running on my system can bypass it except the browser? The technique to bypass it is to have a proxy, either local, or remote. Wouldn't it make more sense to simply allow the browser to make any request the app wants?
CORS is useless, unnecessary, insecure, and essentially only serves to annoy developers. Par for the course for all web tech from the last 20 years. Another turd in the tower of shit that is JavaScript.
Now that we've established that by default a.com cannot read a response from b.com , CORS allows b.com to relax this restriction so that a.com can read from b.com . This allows one website to communicate back and forth to the server of a different website, making certain APIs easier. I don't consider that useless.
Earlier quoted context omitted.
> Someone could follow the advice in the article and still be vulnerable. This applies to any advice that is not an actual reference implementation in code. There's only a state-changing GET handler because they chose to work around CORS and you can't POST for images. Implemented properly this CORS approach does protect against CSRF without the need for an explicit token. I've written more about this before, with con…
>There's only a state-changing GET handler because they chose to work around CORS and you can't POST for images. I'm not sure of that. There's tons of stuff in existence that has state changing GET handlers that don't have the goal of working around CORS, check out the HN upvote button. It's conceivable to me that if Zoom managed to send a CORS response header, they might have used an XHR with GET (considering GET is…
I find in most discussions of CORS, developers don't understand the _threat model_ it is meant to be guarding against. I'm not sure I do, I get confused, although I think I have in the past. I think better docs are needed, I haven't found really good educational materials that begin with the big picture (threat model, what are we actually trying to do here, what things are we trying to guard against, what things are…
E.g. "lets restrict access-control to our API endpoints so it only responds to requests from our website". This is a valid use case, but it's meant to protect a web browser user. An evil website won't be able to request their profile data from our API, and CORS makes it possible to relax this protection to allow our other web property on a different domain access to this information. If someone wants to scrape the API, they can just use cURL and not care about CORS at all.
Earlier quoted context omitted.
application/x-www-form-urlencoded and multipart/form-data POSTs predate CORS. They have to be whitelisted, or large swaths of the existing web would be broken.
These things keep coming up... but how large a swath is it really? Then again, only with TLS 1.3 do we get rid of RC4!! Except when downgrading to 1.2, 1.1, 1.0, ssl3 (is that even around?)