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

151–160 of 285 posts

Re: Developers don't understand CORS (2019)

#151

Post by xg15 »

Sophira wrote: post #138
xg15 wrote: post #133

Earlier quoted context omitted.

> (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…

Well, if your endpoint expects JSON, then at some point it will have to parse it. Even if it completely ignores the content-type header and simply always passes the request body to the JSON parser, the parser would throw.

(But I was wrong, there are ways to produce request bodies that are valid JSON even if the browser forces you into a different format, as the sibling comment demonstrated)

Re: Developers don't understand CORS (2019)

#152

Post by confidantlake »

mrweasel wrote: post #62
encomiast wrote: post #7

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…

We had a project were the same developer wrote the frontend and backend and still managed to get CORS wrong. As the operations people we rewrote them correctly in the load balancer... well I assume correctly, at least the application now works. CORS is really hard to wrap your head around, but sadly there's also a ton of developers that not only fail understand the threat model that CORS guards against, they also don…

> they also don't understand webdevelopment in general, especially the http protocol. I find that somewhat strange, because they also can't do native application

Why would that be strange? Someone who is bad at thing A is likely also bab at closely related thing B.

Re: Developers don't understand CORS (2019)

#154

Post by xg15 »

Beltiras wrote: post #149
xg15 wrote: post #119

Earlier quoted context omitted.

> (ignoring preflight requests for now and assuming we're talking just about "safe" Methods) You can't ignore those because they constitute the bulk of CORS' security model. Yes, you're technically right that CORS cannot prevent other websites from making any request to your server - this would be impossible, since the browser somehow has to get the CORS headers in the first place. However what CORS absolutely lets y…

Every ad GET is doing a lot of things that violate that edict.

Yes, but if ads do it, that would at worst make the ad server vulnerable, not your server.

Re: Developers don't understand CORS (2019)

#155

Post by muvlon »

stymaar wrote: post #142
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…

I don't understand why this is the most upvoted comment. OP is right, and you are wrong. > The requests happen in any case, and you must ensure in your backend that they don't cause any adverse effects. GET requests will be sent, but they are supposed to be idempotent so if your server is implemented in a sensible way, it cannot cause any adverse effect, and reading the response is all that matters for GET requests.…

We are saying the same things, just expressing them in different terms. Yes, only idempotent methods and "safe" POST requests don't need preflight. And I'm saying you need to make sure in your server implementation that those are actually safe. The article states that the CORS header will prevent random other websites from talking to localhost at all, which is just wrong.

Re: Developers don't understand CORS (2019)

#156

Post by Beltiras »

xg15 wrote: post #154
Beltiras wrote: post #149

Earlier quoted context omitted.

Every ad GET is doing a lot of things that violate that edict.

Yes, but if ads do it, that would at worst make the ad server vulnerable, not your server.

You apparently understand less than me. The little I do understand is that CORS is protection for a site's user, not the site.

Re: Developers don't understand CORS (2019)

#157

Post by bazoom42 »

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…

“Can still talk to, but cant read the response” is a bit too simplied. You can’t post a json payload for example, which is how a JavaScript client would usually talk to a backend. You can only post using form data encoding, since this is already possible using a plain html form without any JavaScript. Anything beyound that, like json/xml payloads or methods other than post and get are blocked by default.

Re: Developers don't understand CORS (2019)

#158

Post by ksbd-pls-finish »

stymaar wrote: post #142
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…

I don't understand why this is the most upvoted comment. OP is right, and you are wrong. > The requests happen in any case, and you must ensure in your backend that they don't cause any adverse effects. GET requests will be sent, but they are supposed to be idempotent so if your server is implemented in a sensible way, it cannot cause any adverse effect, and reading the response is all that matters for GET requests.…

>GET requests will be sent, but they are supposed to be idempotent so if your server is implemented in a sensible way, it cannot cause any adverse effect, and reading the response is all that matters for GET requests.

Just my first thought as a security engineer, but sounds like a perfect opportunity to execute a timing attack to me. For example, vheck which users exist (by measuring response time for /api/users?name=john) etc

Re: Developers don't understand CORS (2019)

#159

Post by TeMPOraL »

xg15 wrote: post #150
RagingCactus wrote: post #136

Earlier quoted context omitted.

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.

Ouch! Ok, I wasn't aware text/plain was also one of the whitelisted values and lets you do that. That looks pretty bad indeed.

Or good, depending on who you are. I find CORS to be pain in my butt by effectively preventing ad-hoc client-side browser tools from being able to use most APIs, and forcing me to do bullshit make-work involving a server side component and certificates just to work around this + HTTPS, at which point I may as well just have my "backend" shell out to `curl`, which happily doesn't care about any of that nonsense.

Re: Developers don't understand CORS (2019)

#160

Post by TeMPOraL »

xg15 wrote: post #151
Sophira wrote: post #138

Earlier quoted context omitted.

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…

Well, if your endpoint expects JSON, then at some point it will have to parse it. Even if it completely ignores the content-type header and simply always passes the request body to the JSON parser, the parser would throw. (But I was wrong, there are ways to produce request bodies that are valid JSON even if the browser forces you into a different format, as the sibling comment demonstrated)

Obviously JSON is a subset of text/plain, so I don't know what people were expecting? For text/plain to mean "plaintext, excluding any string that could possibly parse as any of the other named formats that have a plaintext representation"?

Are people using JSON parser as proxy for access control? "Payload successfully parsed as JSON, therefore you are allowed to use this endpoint"?

Post reply on HN