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

271–280 of 285 posts

Re: Developers don't understand CORS (2019)

#271

Post by confidantlake »

mrweasel wrote: post #201
confidantlake wrote: post #152

Earlier quoted context omitted.

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

Okay, but these are developers that can't do frontend, can't do backend, can't do native, can't do embedded, or at least none of them very well.... so what kind of developer are they really, other than a bad one?

A bad one.

Re: Developers don't understand CORS (2019)

#272

Post by krackers »

himata4113 wrote: post #76

It was pretty amusing reading the comment section so I'll chime in: SOP protects you (the browser) from leaking information to websites that should not be able to access that information and CORS allows you to weaken it. Example: SOP stops example.com from fetching the list of subscriptions on youtube.com. But CORS allows example.com to access youtube.com/public/*. This is also not the sole use-case, it also stops yo…

To understand the threat model you need to understand historical decisions browsers made, such as when cookies are sent, and the distinction between actually sending the request versus allowing client-side JS to read back request content. The decisions are just really counterintuitive and often build on legacy precedent.

I think the nature of threat model has also changed over time. Now that samesite cookies are the default, API requests made with the user's credentials shouldn't be an issue, but there is still value in preventing cross-origin reads to do things like preventing random webpages from scanning intranet (there are probably still timing side-channels though). I guess the limitation against non-simple post/get is also marginally beneficial for preventing ddos.

Re: Developers don't understand CORS (2019)

#273

Post by naishoya »

It's security theatre all the way from top to bottom: extra effort for devs and users alike, no real comprehension of any of the threat models at any level of interaction from the original design - which makes it fit right in with the rest of the entire java and advertising me-cosystem.

It's truly confusing to see businesses with real PII, financial, and technical risks choose not to simply disable java for all websites on work systems' browsers; bake settings and other restrictions into immutable VM templates. From these run ephemoral/disposable, per-application suite VM's to enable the office workers to use the tools required for their jobs.

If a worker wants user-upload and FB utility they are free to use their own devices (phones) when they are on break.

If a role has specific need for a specific site that requires special refinements/relaxation or the security policies then that can have it's own templateVM and this allows granular control of which VM instances have access to which other instances' clipboard and if it is one-way or bi-directional.

These techniques aren't novel, aren't actually that difficult, and are actually in-use in many workplaces. Even on legacy systems this has been possible with Windows environments which require full Office utility - since the XP era with 'Embedded' tools like WindowsCE Every reboot spawns a completely clean; custom configured clone of the 'official' image; and if too much changes - that clone evaporates and restarts from read-only image.

All the rest of this ''back-end, front-end, let some people in, keep others out, filter by structure but not by content,'' ... it's just such an exhausting topic to even read about, and i wonder what kind of kool-aid everyone drinks to get them to pretend any of that is actually for any purpose than to allow FAANG/MANGOS/SPAM tech-bro cults to suck up all the user activity meta+data from the free garbage they are peddling.

I need either more coffee, or less Uisge beatha bhon Hosh.

Re: Developers don't understand CORS (2019)

#274

Post by J-Kuhn »

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

You can do GET & POST requests without preflight.

The logic behind this is: It was possible to do this before the introduction of those APIs anyway - but you could not read the response.

You could send a GET request by, for example, embedding an image. And you could send a POST request by submitting a form - even if the form did only consist of hidden elements.

Those are called "simple requests": https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/COR...

It is expected from web application that they can correctly handle those requests, even when they were sent from a different origin (for example, blocking them by using a CSRF token).

It was however not expected that existing web applications could handle non-simple requests - as the ability to do so was restricted either to command line tools or required other user interaction/configuration. This is where the preflight request comes in - send an OPTIONS to check if the other side is okay with that kind of request.

But what CORS do is: It can make the response available to the requesting script - the request did already happen if it didn't require a preflight.

Re: Developers don't understand CORS (2019)

#275

Post by dataflow »

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

You're confusing "idempotent" with "pure", I think.

Re: Developers don't understand CORS (2019)

#276

Post by torginus »

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…

It's easy to get wrong, and CORS is not well suited to today's cloud-native microservice era, when your code calls into a million and one different api endpoints hosted by various means.

It used to be that there was a webserver which handled requests, and a static site server, which served the assets, sitting behind a LB connected to the HTTP address.

It made zero sense to do anything cross origin, and it was automatically suspicious. Nowadays, there's N services, all potentially talking to each other, making CORS very difficult to get right.

And more often than not, they are hosted on generic 'api aggregator' endpoints, which make it very hard to get CORS to do anything meaningful with regards to security.

Also, considering you can URL encode stuff, the part saying CORS prevents the exfiltration of data is not true, it just imposes an inconvenience tax.

Re: Developers don't understand CORS (2019)

#277

Post by trick-or-treat »

vachina wrote: post #120
trick-or-treat wrote: post #53

Earlier quoted context omitted.

I think you're confused. The only thing blocked would be client side fetch. You need to find another way to protect everything else.

> The only thing blocked would be client side fetch. Exactly what I need. My API is public I just don’t want someone other than my own website to consume it. Is it that hard to understand?

cors is not about protecting your assets, you dummy. It's about protecting the rest of us FROM your assets.

Re: Developers don't understand CORS (2019)

#278

Post by Izkata »

JimDabell wrote: post #241
embedding-shape wrote: post #181

Earlier quoted context omitted.

Back in the day when I started web development, websites making their own requests after they loaded wasn't a thing. Eventually, XMLHttpRequest appeared, which let JS do HTTP requests at (page) runtime, and the whole "AJAX movement" kicked off. Initially, you could literally hit any website with any sort of request, so your website.com could make requests to bank.com, and the browser happily obliged. Of course, this…

> Initially, you could literally hit any website with any sort of request, so your website.com could make requests to bank.com, and the browser happily obliged. Of course, this opens up a whole host of issues, so browsers started limiting websites to just being allowed to make requests to the same Origin. I think that’s overstating it a bit. JavaScript was introduced in Netscape 2.0 and the SOP was introduced pretty…

Looks like that largely affected things loaded by tags, and either it was opt-in or didn't affect XMLHTTPRequest/fetch. The big change where we had to start dealing with cross-origin security didn't happen until the 2010s with CORS.

Re: Developers don't understand CORS (2019)

#279

Post by Izkata »

JimDabell wrote: post #242
kittywantsbacon wrote: post #61

[flagged]

I think perhaps it’s generational. If you were a web developer before CORS existed, then you understand that cross-domain requests were forbidden all along and CORS was created to bypass this security. Therefore to do the thing you want to do, you need to enable CORS. No problem, that’s pretty easy. If you only picked up web development after CORS existed, then you try to make a cross-origin request; the browser unde…

> If you were a web developer before CORS existed, then you understand that cross-domain requests were forbidden all along

They weren't though. We had to adjust in the 2010s so existing code wouldn't break. It was something like, Chrome set a deadline after which it would be forcing the same-origin security by default, where it was off or optional before.

Post reply on HN