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

171–180 of 285 posts

Re: Developers don't understand CORS (2019)

#171

Post by masklinn »

rnotaro wrote: post #168
masklinn wrote: post #144

Earlier quoted context omitted.

That’s… not what cors does? CORS will only block browser-mediated “non-simple” requests, they don’t prevent other systems from accessing it as long as they don’t use a browser (or disable CORS in a headless browser).

I'm pretty sure they understand that since they wrote that the resources will need to be proxied. They just want to prevent hotlinking/leeching.

SOP does not prevent hotlinking in the first place, a hotlink is simple request (the most simple if anything), CORS isn’t going to be in the path at all.

Re: Developers don't understand CORS (2019)

#172

Post by TeMPOraL »

Finbel wrote: post #90
ghoshbishakh wrote: post #74

Earlier quoted context omitted.

100% - although it is stunning to see since most LLMs get CORS questions right (which is surprising since they trained on all sorts of incorrect data).

Maybe it’s like that trick where if a thousand people guess the amount of beans in a jar almost all of them will be wrong but their average will be very close to, if not, correct.

Possibly, but at a semantic level.

Re: Developers don't understand CORS (2019)

#173

Post by TeMPOraL »

stephbook wrote: post #68
mrweasel wrote: post #62

Earlier quoted context omitted.

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…

> I assume correctly, at least the application now works. That's like saying the lock works because people can enter the building. What about keeping the bad guys out, which is the whole point?

> That's like saying the lock works because people can enter the building. What about keeping the bad guys out, which is the whole point?

You can keep all the "bad guys" out by putting a brick wall in place of every entrance and window. That will achieve 100% of the security goal, and even ops people might breathe a sigh of relief - until the stakeholders who commissioned the buildings get wind of it, that is.

Beyond that, locks aren't about "keeping bad guys out", but about giving owners a degree of control over who can access what and when. "Keeping bad guys out" is a subset of it, possibly a small one, unless you're happy defining "bad guys" as "people whose goals are at odds with the owner's business model".

Re: Developers don't understand CORS (2019)

#174

Post by bazoom42 »

cyphar wrote: post #132
bazoom42 wrote: post #114

Earlier quoted context omitted.

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

Yes, the original CSRF attack using a plain html form does not even require JavaScript. CORS does not address this scenario.

But cross-domain post is only allowed if the payload is form data encoded. A Json payload from JavaScript would be blocked by default, as would other methods beyond get and post. Therefore you usually don’t have to worry about CSRF for a JavaScript API.

CORS is a a way to enable cross-domain calls from JavaScript without introducing the CSRF issue.

Re: Developers don't understand CORS (2019)

#175

Post by TeMPOraL »

harrall wrote: post #20
yaur wrote: post #18

Earlier quoted context omitted.

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

> 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.

Re: Developers don't understand CORS (2019)

#176

Post by simonw »

To understand CORS, you have to understand the Same Origin Policy.

If you find CORS difficult to understand, particularly the question of "why do we need this?", I suggest starting here: https://developer.mozilla.org/en-US/docs/Web/Security/Defens...

I've tried using the Same Origin Policy as an interview question in the past, but it's not a good question because the majority of candidates aren't familiar with it, so you learn very little by bringing it up.

Re: Developers don't understand CORS (2019)

#177

Post by JimDabell »

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.

This is not correct. Safety and idempotency are two different concepts. Safety is when a request does not result in a state change. Idempotency is when the outcome is the same whether you make the request once or several times.

GET is defined to be both safe and idempotent. Clients can make GET requests without explicit human intent driving them because they are safe, not because they are idempotent.

DELETE is not defined to be safe but it is defined to be idempotent. This means you need human intent to drive it, but clients can retry as much as they like because whether you ask to delete a resource one time or a hundred times, the result is still the same – the resource is deleted. Obviously making DELETE requests can result in adverse effects even though it is idempotent.

POST is neither safe nor idempotent, however it’s subject to some unintuitive rules when it comes to things like cross-origin requests for historical reasons.

Re: Developers don't understand CORS (2019)

#178

Post by Sophira »

TeMPOraL wrote: post #165
xg15 wrote: post #162

Earlier quoted context omitted.

I mean, it still relies on a vulnerable configuration (not checking the content type) For adhoc dev tools, you could also just disable CORS: https://berkkaraal.com/notes/other/chrome-disable-cors/

> I mean, it still relies on a vulnerable configuration (not checking the content type) Unless I'm misunderstanding the claim, that's not "vulnerable configuration", but extreme lunacy - basically treating parsing outcome as access control. "Did the payload parse correctly as JSON? No -> go away; Yes -> oh that must mean you're supposed to be here". I'm at a loss of words that this is even a problem in practice. > Fo…

Regarding the first part, it's easier than you might think to have a false sense of security.

I've seen a web application that did, in fact, check the Content-Type header to make sure that "application/json" was there - but it didn't check that the header value started with that. That meant that setting the header to "multipart/form-data; boundary=application/json" was enough to bypass a CORS preflight!

Re: Developers don't understand CORS (2019)

#179

Post by embedding-shape »

simonw wrote: post #176

To understand CORS, you have to understand the Same Origin Policy. If you find CORS difficult to understand, particularly the question of "why do we need this?", I suggest starting here: https://developer.mozilla.org/en-US/docs/Web/Security/Defens... I've tried using the Same Origin Policy as an interview question in the past, but it's not a good question because the majority of candidates aren't familiar with it, so…

> I've tried using the Same Origin Policy as an interview question in the past, but it's not a good question because the majority of candidates aren't familiar with it, so you learn very little by bringing it up.

For hiring frontend developers, I've found it to be an excellent question, as surely if you've been developing web apps, you essentially must have come across it at some point. If you haven't, I'd be asking more questions about how typically you'd communicate with a backend and so on. Some people have hit the issues related to CORS, worked around it the quickest possible way then forgot all about it, rather than understanding what's going on, also a useful signal for some roles.

Bit less good for backend roles, as not everyone has worked closely with a frontend team which tends to be the people hitting issues around CORS.

Re: Developers don't understand CORS (2019)

#180

Post by RagingCactus »

TeMPOraL wrote: post #165
xg15 wrote: post #162

Earlier quoted context omitted.

I mean, it still relies on a vulnerable configuration (not checking the content type) For adhoc dev tools, you could also just disable CORS: https://berkkaraal.com/notes/other/chrome-disable-cors/

> I mean, it still relies on a vulnerable configuration (not checking the content type) Unless I'm misunderstanding the claim, that's not "vulnerable configuration", but extreme lunacy - basically treating parsing outcome as access control. "Did the payload parse correctly as JSON? No -> go away; Yes -> oh that must mean you're supposed to be here". I'm at a loss of words that this is even a problem in practice. > Fo…

This is fundamentally a CSRF issue and framing CSRF as an access control issue often yields to wrong conclusions. With CSRF you might face the situation that the request has a valid session cookie, but is actually created by an attacker coercing the victim's browser into sending a request unbeknownst to the victim.

This case gets more and more complicated with browser defenses such as SameSite cookies or fetch headers you can use to mitigate this case, but let's ignore that for now.

To drive my point home, similar to how ensuring the content-type is set correctly on your JSON endpoint prevents CSRF, it's actually also a very real defense to require a custom header to be set, e.g.

  I-Promise-To-Not-Be-Malicious: true
Requiring this header will prevent CSRF because browsers won't allow you to set that cross-origin (unless of course you allow anyone to set it via CORS)
Post reply on HN