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

221–230 of 366 posts

Re: Developers don't understand CORS

#221

Post by _bxg1 »

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.

I think my personal brain-fog when it comes to web security is that it isn't just protecting the server from malicious clients, or the client from malicious data, or the user from a malicious client, but all of the above and then some. The attack vectors point every-which-way and it can get confusing whom you're trying to guard against whom in a given case.

Re: Developers don't understand CORS

#222

Post by chrisfosterelli »

zenexer wrote: post #163
chrisfosterelli wrote: post #41

Earlier quoted context omitted.

This is discussed in the post text, but happy to elaborate here in more detail here! Here is the patch links from Firefox[0] and from Chrome[1] which they specify that active mixed content policies do not apply to the localhost, because the w3c specification was updated to specifically allow this behaviour[2]. You might have to use 127.0.0.1 directly. So yes, it is possible and not factually incorrect. If for some re…

I'm fairly certain that these patches didn't land until recently, at which point the design decisions were probably already made at Zoom. (I don't know much about Zoom, but that seems like a reasonable assumption.) Additionally, these changes aren't likely to apply to Firefox ESR or IE for a while. In Zoom's case, I highly doubt CORS on its own was a viable solution. Maybe in 2026, a decade after the patch, sure, but…

These are from years ago, and as mentioned there are two other alternatives discussed. There's no excuse to not checking origin at all. They could have even used the image hack and then checked the origin.

Re: Developers don't understand CORS

#223

Post by chrisfosterelli »

reda-alaoui wrote: post #188
chrisfosterelli wrote: post #41

Earlier quoted context omitted.

This is discussed in the post text, but happy to elaborate here in more detail here! Here is the patch links from Firefox[0] and from Chrome[1] which they specify that active mixed content policies do not apply to the localhost, because the w3c specification was updated to specifically allow this behaviour[2]. You might have to use 127.0.0.1 directly. So yes, it is possible and not factually incorrect. If for some re…

We tested this on Fifefox on April 2019. It is still blocked.

> If for some reason that doesn't work for your app, the post also mention two secure alternatives: the native client can install a self-signed cert, or you can use a browser extension with the native messaging API.

(Also you might want to verify you were using 127.0.0.1 and that you had the headers correct)

Re: Developers don't understand CORS

#224

Post by chpmrc »

untog wrote: post #96
chpmrc wrote: post #92

How does not allowing CORS make any sense if any other application running on my system can bypass it except the browser? The technique to bypass it is to have a proxy, either local, or remote. Wouldn't it make more sense to simply allow the browser to make any request the app wants?

Browsers are ubiquitous, and they run third party code. That would be a deadly combination for anyone hoping to launch a DDOS attack if CORS protections didn't exist.

The same could be said about operating systems. In fact when just replacing "Browsers" with "Operating systems" your sentence would still hold true.

Re: Developers don't understand CORS

#225

Post by chpmrc »

chpmrc wrote: post #92

How does not allowing CORS make any sense if any other application running on my system can bypass it except the browser? The technique to bypass it is to have a proxy, either local, or remote. Wouldn't it make more sense to simply allow the browser to make any request the app wants?

Even Cordova (which basically runs a web view on mobile) has a plugin to bypass CORS (https://hackernoon.com/a-practical-solution-for-cors-cross-o...). Are we entirely sure that the benefits of disallowing CORS by default outweigh the annoyances? Is there any study on this?

Re: Developers don't understand CORS

#226

Post by chrisfosterelli »

comex wrote: post #220
chrisfosterelli wrote: post #216

Earlier quoted context omitted.

The advice isn't wrong, but you did misunderstand it. The CORS header will definitively block the request to an AJAX REST API from going through, because it will be a POST request with an `application/json` Content-Type, which will trigger a preflight request. You're assuming the API will remain identical, just with new headers. I didn't advise this, what they have now is not a semantically RESTful API. What they hav…

You shouldn’t assume that a post titled “Developers don’t understand CORS” will only be read by people that understand all the intricacies of CORS. :) For everyone else, the need for a POST request [edit2: as well as a non-form Content-Type] may not be immediately apparent. (Edit: It’s true that a proper RESTful API shouldn’t be using GET for operations with side effects anyway, but that’s different from knowing that…

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.

Re: Developers don't understand CORS

#227

Post by anaphor »

arendtio wrote: post #145

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. the google drive feature where you can say "anyone with the link can {view,edit,comment,etc}".

The downside is obvious though: it would require everyone to adapt to this model, and rewrite all of their apps to use it instead of the session cookie model. Not gonna happen without a massive effort (see ipv6 rollout for an example of the effort required for something like this).

Re: Developers don't understand CORS

#228

Post by jrochkind1 »

chpmrc wrote: post #219
jrochkind1 wrote: post #155

Earlier quoted context omitted.

Yes. CORS is not so much a protection of your site against malicious user-agents; It is a protection of your site's users , using good non-malicious browsers, against malicious other JS on the web. I think this is one of the most basic misunderstood things about CORS. Once you understand that, you can start actually trying to understand the threat model... which is still pretty confusing, to me anyway. But until you…

If a native app can request any resource why shouldn't a web app be able to do that too? Does it matter whether that app runs in my browser, Electron (which can easily bypass CORS policies) or whatever other runtime? If it does then CORS restrictions should be put in place at the OS level, if it doesn't they should be removed altogether. There are a ton of other ways to make sure you don't "give your stuff" to unauth…

A web browser is different than a native app, because simply clicking a link can execute code from an untrusted party.

First of all, when you are using a web browser, if it wasn't for cross-browser request restrictions, code executing on one site (or web app) would be able to _use credentials stored in cookies_ by another site altogether. Because all these web apps exist in the same browser context. Native apps are all separate, code running in an Native App A can't say "make a request to facebook using the credentials the user already logged into in the facebook app." But Web App A could do exactly that with the credentials the user logged into on facebook.com -- if it wasn't for cross-browser request restrictions. Which then CORS let some sites carefully opt out of.

Secondly, when you download an app, you are trusting the developers of that app.

You navigate the web, you are trusting every single site you visit (to also not have their own code injection or other vulnerabilities to which web pages/apps are particularly vulnerable to), and most users have no idea what sites they are visiting, they are just clicking links.

What we really need a more clear explanation of the CORS threat model, with examples. I think we'd all be more clear about what it's for and why we need it if we understood it better.

It is definitely a developer UX issue, but it is sadly one that is baked into the web for legacy reasons.

Re: Developers don't understand CORS

#229

Post by untog »

chpmrc wrote: post #224
untog wrote: post #96

Earlier quoted context omitted.

Browsers are ubiquitous, and they run third party code. That would be a deadly combination for anyone hoping to launch a DDOS attack if CORS protections didn't exist.

The same could be said about operating systems. In fact when just replacing "Browsers" with "Operating systems" your sentence would still hold true.

Not really. Third party code that you haven't installed does not run in an operating system at the click of a button. It does in the browser.

By the logic you're outlining there's no reason to sandbox a browser at all, since it's no different to an operating system. Experience suggests that would not be wise.

Re: Developers don't understand CORS

#230

Post by jrochkind1 »

mderazon wrote: post #185
jrochkind1 wrote: post #164

Earlier quoted context omitted.

Hmmm.... never thought about this but now thinking about it... does anyone need CORS? Can server-enforced access controls on "Origin" substitute for CORS in all cases?

The server responsibility of CORS is also about making sure the browser accepts the cross origin request (in case it's a valid origin). If it won't send the correct headers back, the browser will drop the request Yes, the server can drop the request or return an error, but that's just half of it. If it wants the browser to accept the request, it has to explicitly say it by using the CORS headers.

Ah, right. But why not have browsers allow cross-origin requests, but let an individual server just deny it based on origin header?

I guess because we don't trust servers to do that, we need "don't allow by default, let the server opt-in" instead of "allow it by default, let the server opt-out", because too many servers would not opt out.

Post reply on HN