Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Developers don't understand CORS (2019)

fosterelli.co

Post reply on HN
Print view View original

131–140 of 285 posts

Re: Developers don't understand CORS (2019)

#131

Post by Sophira »

muvlon wrote: post #39

Even TFA seemingly doesn't understand CORS. Or at least misreprents it grossly: > The webserver listening in on localhost:19421 should implement a REST API and set a Access-Control-Allow-Origin header with the value https://zoom.us . This will ensure that only Javascript running on the zoom.us domain can talk to the localhost webserver. No, that does not do that. JavaScript from any other website can still talk to lo…

My understanding was that "preventing otherwise disallowed HTTP requests" was the entire point of the preflight OPTIONS request, and that CORS will do nothing if the request would otherwise be allowed.

For example, a POST request with a Content-Type of "text/json" would not be allowed to be sent to third-party hosts without an OPTIONS preflight, but one with a Content-Type of "multipart/form-data" would be allowed and wouldn't be stopped by CORS at all, even to third-party hosts.

(And, of course, if your endpoint just assumes JSON without strictly checking the Content-Type, then congratulations, you've just allowed any website to POST to you, with no user action required.)

Re: Developers don't understand CORS (2019)

#132

Post by cyphar »

bazoom42 wrote: post #114
sureglymop wrote: post #103

Earlier quoted context omitted.

Could you go the full mile and explain that very specific kind of attack?

Example: I post “fungame.com” on Show HN, you visit it, and in the background the JavaScript calls Facebook on your behalf (using your Facebook authentication cookie) and adds me as friend. By default such cross-domain requests from JavaScript are disallowed, but CORS allows it if the server specifically opt-in. But the check happen in the browser, since the purpose is to protect the user of the browser. There are so…

> Example: I post “fungame.com” on Show HN, you visit it, and in the background the JavaScript calls Facebook on your behalf (using your Facebook authentication cookie) and adds me as friend.

Isn't that what CSRF protections are for, not CORS? There are other (very old) ways to trick a user into doing a POST that wouldn't be blocked by CORS -- and as you say, GET and some POST requests can always be sent but you don't see the response.

My understanding is that the actual protection that it gives in this scenario is that the "fungame.com" JavaScript cannot read your friends list or your list of private messages (basically, blocking GET data that should not be shared to random sites, as it would violate user privacy). You still need CSRF protections regardless of CORS.

Re: Developers don't understand CORS (2019)

#133

Post by xg15 »

Sophira wrote: post #131
muvlon wrote: post #39

Even TFA seemingly doesn't understand CORS. Or at least misreprents it grossly: > The webserver listening in on localhost:19421 should implement a REST API and set a Access-Control-Allow-Origin header with the value https://zoom.us . This will ensure that only Javascript running on the zoom.us domain can talk to the localhost webserver. No, that does not do that. JavaScript from any other website can still talk to lo…

My understanding was that "preventing otherwise disallowed HTTP requests" was the entire point of the preflight OPTIONS request, and that CORS will do nothing if the request would otherwise be allowed. For example, a POST request with a Content-Type of "text/json" would not be allowed to be sent to third-party hosts without an OPTIONS preflight, but one with a Content-Type of "multipart/form-data" would be allowed an…

> (And, of course, if your endpoint just assumes JSON without strictly checking the Content-Type, then congratulations, you've just allowed any website to POST to you, with no user action required.)

Is that so? Neither urlencoded forms nor multipart/form-data are valid JSON on the wire, so while other websites could send requests, wouldn't they just hit a parse error?

Re: Developers don't understand CORS (2019)

#134

Post by inigyou »

koolala wrote: post #104
inigyou wrote: post #87

Earlier quoted context omitted.

Your cookies are sent.

Then why wasn't credentialless a simple fix to solve that. Not sending cookies isn't hard.

Because that would break things. You couldn't stay logged into HN without cookies. Cookies aren't just for credentials, imagine hotlinking to an image and getting a different language version because your language cookie wasn't sent.

Re: Developers don't understand CORS (2019)

#136

Post by RagingCactus »

xg15 wrote: post #133
Sophira wrote: post #131

Earlier quoted context omitted.

My understanding was that "preventing otherwise disallowed HTTP requests" was the entire point of the preflight OPTIONS request, and that CORS will do nothing if the request would otherwise be allowed. For example, a POST request with a Content-Type of "text/json" would not be allowed to be sent to third-party hosts without an OPTIONS preflight, but one with a Content-Type of "multipart/form-data" would be allowed an…

> (And, of course, if your endpoint just assumes JSON without strictly checking the Content-Type, then congratulations, you've just allowed any website to POST to you, with no user action required.) Is that so? Neither urlencoded forms nor multipart/form-data are valid JSON on the wire, so while other websites could send requests, wouldn't they just hit a parse error?

You can massage a text/plain form into valid JSON. text/plain is also one of the allowed default types. It works if the server doesn't check the content-type.

Source: I've done that successfully in multiple pentests.

Edit: lazy LLM generated example:
That gives you

  {"key":"value", "ignore":"="}
The trick is to stuff the = character you cannot control into an irrelevant value.

Re: Developers don't understand CORS (2019)

#137

Post by 1dom »

mparnisari wrote: post #40

I'm one of them. CORS is THE topic that I have to get a refresher for periodically. It's like I forget about it, it never sticks. I'm a backend developer so I never encounter any cors issues. Maybe that's why? I seem to forget things that I don't use on a day to day basis, so.

I feel the same. Unfortunately, I've had to deal with CORS in a few situations where the request is "we need to get this thing from this server, but we can't change the servers CORS or CSP", which, in technical security speak is "we have this security system in place, we need to circumvent it".

Ultimately, it almost always depends on the server only being accessed via an untampered browser request.

The Zoom exploit was able to happen because CORS and CSP are so easy to get around on the client side, so Zoom did it. Sure, Zoom were bad/lazy/silly for doing it, but I feel we're bad as a community for still having this model.

Re: Developers don't understand CORS (2019)

#138

Post by Sophira »

xg15 wrote: post #133
Sophira wrote: post #131

Earlier quoted context omitted.

My understanding was that "preventing otherwise disallowed HTTP requests" was the entire point of the preflight OPTIONS request, and that CORS will do nothing if the request would otherwise be allowed. For example, a POST request with a Content-Type of "text/json" would not be allowed to be sent to third-party hosts without an OPTIONS preflight, but one with a Content-Type of "multipart/form-data" would be allowed an…

> (And, of course, if your endpoint just assumes JSON without strictly checking the Content-Type, then congratulations, you've just allowed any website to POST to you, with no user action required.) Is that so? Neither urlencoded forms nor multipart/form-data are valid JSON on the wire, so while other websites could send requests, wouldn't they just hit a parse error?

If your web application specifically parses data based on the Content-Type that it advertises itself to be, then yes, the webapp would hit a parse error. But there are many applications that don't do that.

An attacker might use JavaScript to set a "multipart/form-data" Content-Type (thereby bypassing the otherwise required OPTIONS preflight), but send JSON in the request body. Unless your web application specifically parses the body based on the Content-Type (web servers don't do this for you), then you wouldn't detect that.

Re: Developers don't understand CORS (2019)

#139

Post by koolala »

inigyou wrote: post #134
koolala wrote: post #104

Earlier quoted context omitted.

Then why wasn't credentialless a simple fix to solve that. Not sending cookies isn't hard.

Because that would break things. You couldn't stay logged into HN without cookies. Cookies aren't just for credentials, imagine hotlinking to an image and getting a different language version because your language cookie wasn't sent.

I thought we were talking about cross origin requests. I've not encountered content worth hotlinking that can't work on first load without cookies. That seems like a slim hypothetical that doesn't justify banning the ability entirely. You don't attach cookies just to wget something from a server.

Re: Developers don't understand CORS (2019)

#140

Post by 1dom »

zdc1 wrote: post #57
physix wrote: post #24

> Developer's don't understand CORS Count me in!

Even the HN comments here are a sea of confusion and contradiction. It's stunning and makes me wonder whether CORS is a bad solution, or if it's solving a hard problem.

Your first sentence is the proof that CORS is a bad solution.

HN is supposed to be full of people who need to know, use and depend on CORS and CSP. We might all just be idiots, but we're the idiots who are supposed to use this tool, and we can't explain it or agree on it.

If a tool can't be used or understood by the primary users, IMO it's by definition a bad tool/solution. It's easy to see why - it's security that depends on a browser, something we're traditionally told never to depend on for security.

Post reply on HN