Live data from Hacker News

Developers don't understand CORS

fosterelli.co

351–360 of 366 posts

Re: Developers don't understand CORS

#351

Earlier quoted context omitted.

I was hoping someone would mention the warnings that capability people had raised about the CORS proposal. Every time capability security principles have been compromised it turns out badly.

I was curious to see if there was any record of this and I found some interesting discussions from '09 https://lists.w3.org/Archives/Public/public-webapps/2009AprJ... Very interesting to read this now.

Thanks for digging this up! The whole thread was quite long and involved a lot of head banging against my desk when I read it.

The whole pro-CORS argument essentially boiled down to "it's easier to understand when you've already internalized access lists". Capability folks then replying, "sure, but it doesn't help you understand the proper authorization contexts, and so doesn't solve the confused deputies, and in fact, hides some of them to bite you later". Basically, the same old arguments. Rinse, repeat.

Re: Developers don't understand CORS

#352

At this point I don't want to understand CORS. Put together a little script package this week, threw in some Vue and a Bootstrap and put it on our fileserver. Now the Font Awesome icons won't load due to CORS errors. I don't want to spin up a server for 500 lines of HTML/JS. I don't want to download the fonts, fiddle around in Bootstrap etc. CORS is broken or the web itself has become broken if we need integrity chec…

Base64 should allow you to do it. It's logical to limit remote font loading, even moreso than js. There used to be quite a few RCE bugs involving fonts on Windows and Adove.

Re: Developers don't understand CORS

#353

Earlier quoted context omitted.

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…

Thank you for the reply! I didn't realize this actually gets to another question I've had in another context, which is why can't a browser at least assume 192.168.0.0/16 etc. are private networks and block requests from nominally-public addresses from being sent to those? (Or do they do that already?) This should be possible without needing to detect anything at all, right?

There turn out to be a bunch of complications when one tries to do that, if the goal is to not break existing legitimate uses.

I haven't been following this closely, but for Firefox https://bugzilla.mozilla.org/show_bug.cgi?id=354493 is the relevant bug, with some (failed) attempts to do that.

Re: Developers don't understand CORS

#354

Earlier quoted context omitted.

But only one domain at a time. The lack of a way to specify multiple domains in a header makes it absurdly painful to actually implement when you want to make your content available to a specific set of domains. I’m personally at the point where I’d rather handle unnecessary request authentication than trying to do anything with CORS.

I'm curious, why was it painful? We just had a middleware do an Origin check and copy the header if it matches.

90+ microservices with 5+ environments. Mostly a matter of scaling a solution across a rather large surface area and across a number of languages and teams.

Re: Developers don't understand CORS

#355

Earlier quoted context omitted.

Thank you for the reply! I didn't realize this actually gets to another question I've had in another context, which is why can't a browser at least assume 192.168.0.0/16 etc. are private networks and block requests from nominally-public addresses from being sent to those? (Or do they do that already?) This should be possible without needing to detect anything at all, right?

There turn out to be a bunch of complications when one tries to do that, if the goal is to not break existing legitimate uses. I haven't been following this closely, but for Firefox https://bugzilla.mozilla.org/show_bug.cgi?id=354493 is the relevant bug, with some (failed) attempts to do that.

Interesting. It seems the "legitimate" uses are corporate? Seems like providing a group policy or config option to disable protection against this would be the sensible way to go, rather than increasing the attack surface of home users just because some corporate users do weird things. Although honestly major software vendors are already happy breaking so many things in the name of security that this one could just be another one on top...

Re: Developers don't understand CORS

#356
post #234
post #231

Earlier quoted context omitted.

I call it my intellectual immune system, but it might be more like a runaway process killer or an OOM-killer. It hates ugliness, and it hates complexity. I kind of appreciate its attempts to clean Javascript out of my brain. Even though it makes it frustrating to do front end tasks, I appreciate the good intentions. In the 2000s I learned Perl no less than three times. I was really impressed by what people could do w…

As an online discussion grows longer, the probability of an unrelated analogy involving computer science and software engineering approaches 1. I shall graciously accept this being called adtac's law out of sheer humility :P

More like: people rely on shared knowledge when communicating. This is Hacker News, after all.

Re: Developers don't understand CORS

#357

I absolutely hate the current same-origin-policy (SOP) we have and therefore CORS. In the end, CORS is a way to work around the problems the same origin policy creates. Yes, I know there are good reasons why we have it, but in my opinion, it is the wrong solution to that problem. I mean, the biggest problem the SOP solves is that some website could trick the browser into sending an authenticated request to your site/…

Not sure why you're getting downvoted. It's a valid point. I think it's because people intuitively think of access control as an answer to the question "Who are you?", which means your authentication credential needs to be sent with every request to a given site. The alternative solution is to use "capabilities" which are a way of accessing a given resource by the very fact that you possess a reference to it. E.g. th…

Thanks for the response. Yes indeed, there would be the cost of change. But if we want the web to be truly decentralized it doesn't make much to disallow any cross-origin interaction by default.

After all, cross-origin requests are a normal thing on the web. The problem is that browsers make credentials available to websites that shouldn't have control over them. It is like removing all doors from a house because otherwise, the stupid neighbor would give the keys (you gave him for watering your plants) to anybody that would ask.

Re: Developers don't understand CORS

#358

Earlier quoted context omitted.

Pretty sure some tools like NoScript already do that, but to protect against DNS rebinding (which can subvert the SOP), not as a protection against cross-origin requests coming from a public site to an internal one. https://en.wikipedia.org/wiki/DNS_rebinding > The NoScript extension for Firefox includes ABE, a firewall-like feature inside the browser which in its default configuration prevents attacks on the local n…

Yeah but why shouldn't the browser do this itself to provide the cross-origin protection?

I think just because they're afraid of breaking things? I'm honestly not sure what the rationale was for not implementing this. They do DNS pinning which helps mitigate DNS rebinding attacks, but I don't think they do anything specifically to restrict access to internally routable IPs.

They do block certain ports that are known to be problematic (25, 6667, 5222, etc)

Re: Developers don't understand CORS

#359

Earlier quoted context omitted.

Yeah but why shouldn't the browser do this itself to provide the cross-origin protection?

I think just because they're afraid of breaking things? I'm honestly not sure what the rationale was for not implementing this. They do DNS pinning which helps mitigate DNS rebinding attacks, but I don't think they do anything specifically to restrict access to internally routable IPs. They do block certain ports that are known to be problematic (25, 6667, 5222, etc)

It's so stupid. Makes me want to just fork the browsers and add blatantly obvious protections like this if I can find the time...

Re: Developers don't understand CORS

#360

Earlier quoted context omitted.

I think just because they're afraid of breaking things? I'm honestly not sure what the rationale was for not implementing this. They do DNS pinning which helps mitigate DNS rebinding attacks, but I don't think they do anything specifically to restrict access to internally routable IPs. They do block certain ports that are known to be problematic (25, 6667, 5222, etc)

It's so stupid. Makes me want to just fork the browsers and add blatantly obvious protections like this if I can find the time...

If you do that, I would recommend looking at writing an extension first to see if there's any way to do it without a fork (maybe using the same technique that things like ublock origin have)

https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...

Post reply on HN