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

Developers don't understand CORS

fosterelli.co

Post reply on HN
Print view View original

261–270 of 366 posts

Re: Developers don't understand CORS

#261

Post by mappu »

rezonant wrote: post #56
vbezhenar wrote: post #48

Earlier quoted context omitted.

I think that Chrome allows calling http://localhost from https domain. Other browsers should fix that instead of every application installing their custom certificates into trust store.

Installing trust store certificates for these purposes is asking for trouble. Sure, if the private key is unique per installation it theoretically should be fine, but in reality it can be hard to gather enough entropy to be satisfiably unpredictable, and it's very easy to get this wrong. It's worth noting that there isn't a solid way to limit your CA certificate in the trust-store to the domains you intend to use it…

> in reality it can be hard to gather enough entropy to be satisfiably unpredictable

I think this is a myth, especially on desktop/laptop PCs - a few hundred bytes of entropy at system boot initialize the kernel CSPRNG, which can then generate countless gigabytes of cryptographic-quality randomness on demand.

Re: Developers don't understand CORS

#262

Post by squiggleblaz »

tcheard wrote: post #137
abstractbarista wrote: post #129

Earlier quoted context omitted.

Thanks for this; it helped me. Very naively, I don't understand why evil.com origin was allowed to make any request to other domains using any cookies/session/identity of the browser/user in the first place. Why was this accepted standard? I was blown away when I first learned that a request made to xyz.com while in a browser tab showing abc.com would actually complete the request using my identity on xyz.com.

By default, under the same origin policy, a browser won't allow requests cross origin. But there are valid situations where you want a request from 1 domain to be made to other domains. This is where CORS comes in. CORS is a mechanism to loosen security, not increase it. It allows a server to say, these are the domains (outside my own domain) who can make requests. CORS headers should be set carefully so that you are…

> CORS is a mechanism to loosen security, not increase it.

Or we could call it CORB instead (Cross origin request blocking), and then we see it's a mechanism to tighten security. Since fundamentally, what we have is an agreement against major web browser vendors that blocks cross origin requests unless the web server authors have used CORS.

I mean, how many people have encountered a problem with CORS? Almost no-one, and those that have encountered a problem with CORB and solved it by enabling a shitty CORS that opened the doors. (At least, they're fixing security holes in software that was written by devs who encountered a CORB problem and fuxed it. But all CORS problems follow a CORB problem.)

If we called it by its true name, maybe it would help people understand what's happening. Names are important. If developers understand CORB, they will potentially understand CORS. But no-one can understand CORS till they've understood CORB.

Re: Developers don't understand CORS

#263

Post by systematical »

Thesis: Developers don't understand CORS. So I read it. All along the author does not attempt to explain CORS to me. I then Google CORS, and think I do understand it already, but this guy is telling me I don't, but completely fails at explaining why I don't. Maybe I don't understand CORs, but the author didn't help anyone with this piece. This received 508 upvotes...how?

Re: Developers don't understand CORS

#264

Post by EGreg »

leesec wrote: post #245
EGreg wrote: post #239

Earlier quoted context omitted.

How so? It's super easy to just download and put into any website. Look at the demo above. It took us about 3 months of work to get all the quirks out, but anyone can do it. A developer can grab our library but if you don't know how to code, it's just a widget you get off the Internet. And it works on YOUR WEBSITE. This isn't like Dropbox because there is no desktop app.

So you're wondering why people use something that just works over something that took you (assumedly someone technical) 3 months to get all the kinks out? How long do you think it would take a non technical team or company to get it up and running?

No. You’re just mistakenly comparing apples and trees on which apples grow.

It took us 3 months to turn WebRTC into something that “just works” on any website. The RESULT OF THAT is now available for anyone to use.

People can have it up and running in 5 minutes. On their own website.

Users have nothing to download. It just works, including on mobile web browsers.

Companies can also put it into their mobile apps.

So what is the downside again?

Re: Developers don't understand CORS

#265

Post by james_s_tayler »

WhitneyLand wrote: post #197
csours wrote: post #12

I certainly don't understand CORS. I've read about it several times and I don't remember what I read. It's like CORS has a teflon coating that prevents it from sticking in my mind. I know what CORS is for and why you need it, but I have no idea how, where, and when to use it.

This Teflon you're talking about, it's a thing. Not just with CORS, not just with you. For example, I've gotten decent at regular expressions a few times but have to keep relearning it. Adding insult to injury, I might relearn something from Stackoverflow, and realize afterwards I posted the answer! Not for trivial stuff. But a string of punctuation with capture groups or whatever, forget about it [1]. Any support fo…

Anki

Re: Developers don't understand CORS

#266

Post by james_s_tayler »

lacampbell wrote: post #260
justinclift wrote: post #205

Earlier quoted context omitted.

Javascript is like this with me. I have no idea why. Probably my having a super low opinion of it's whole ecosystem doesn't help. ;)

I think it's 100% because you don't like Javascript. You resent having to learn it. I feel the exact same way about Git, I've never been able to stomach it, I'm bewildered as to why the entire programming community have decided it's the one VCS to rule them all, and I resent having to grok its UI. The Javascript ecosystem is huge. It's also the wild west, completely non-curated, open to anyone, and you have to treat…

Git is amazing, beautiful piece of software.

But... sigh I feel exactly how you feel about Git about Vim. It's the one editor everyone has decided despite it's arcane and bizarre UX that you aren't a real programmer if you don't know.

Refuse to learn it. Absolutely refuse.

I think everyone has one of those things.

Re: Developers don't understand CORS

#267

Post by squiggleblaz »

Animats wrote: post #241

One of the side effects of CORS is that you can't display most off-site images through WebGL. Displaying an off-site image through is allowed. Otherwise ads would break. But you can't bring the same image into the WebGL system. I hit this trying to display map tiles. The map tiles are on a server that doesn't send any CORS headers. A simple 2D display of the map works fine. But using a 3D library that allows rapid mo…

The statement is false. CORS - cross origin request sharing - only adds permission. CORS could allow you to display off-site images through WebGL, but it cannot prevent it.

CORB - cross origin request blocking - is what prevents you from doing it.

This sounds pedantic, but it seems that till people understand that browsers implement CORB unless a server implements CORS (or in whitelisted/legacy circumstances), they cannot understand their problems or the solutions. This is largely the fault of browser vendors, who seem to act as if everyone understand CORB and their only task is to educate you about CORS.

Re: Developers don't understand CORS

#268

Post by jjeaff »

xyzzy_plugh wrote: post #139
abstractbarista wrote: post #129

Earlier quoted context omitted.

Thanks for this; it helped me. Very naively, I don't understand why evil.com origin was allowed to make any request to other domains using any cookies/session/identity of the browser/user in the first place. Why was this accepted standard? I was blown away when I first learned that a request made to xyz.com while in a browser tab showing abc.com would actually complete the request using my identity on xyz.com.

The alternatives are grim. As an extreme example, if I were to stream video to your browser from my website, evil.com, I would have to either host or proxy those streams through my server. Instead, I can just point your browser to a video from youtube.com or something. If youtube.com then decides you need to log-in (or be logged-in) to verify your age (as they do), then that is between your browser and youtube.com to…

A tangent, but YouTube actually does not require login to verify age on embedded videos.

Re: Developers don't understand CORS

#269

Post by heyoni »

spydum wrote: post #256
chrisfosterelli wrote: post #226

Earlier quoted context omitted.

Haha true! It's tricky to find a balance between a short post that nails home a point and a complete guide that hits all the nuances. I definitely intended the former here but I think this is good evidence there is room for the later.

i think the tragedy of web security is that, it's become too complicated to provide simple guidance to developers who are feature-focused. They don't want to become experts in security-header-machinery and crazy amount of domain knowledge needed, but there aren't many other options. Just look at all the security options a dev has to contend with: HSTS CORS (with it's myriad of headers.. ACAO, ACAH, ACAC, etc.) CSRF X…

Honestly, I think the real issue is being able to see exactly what the machines are doing when they talk to each other. And I don't mean diagrams either.

I just went through this when setting up an nginx reverse proxy to a gunicorn web server. Once I was able to see all the X- headers and how wsgi was setting up its environment against that, it all became very clear to me what was happening and why each piece was necessary.

I think the same would apply to being able to see exactly what happens with preflight requests. PS: non-interactive diagrams don't fill that gap.

Post reply on HN