CORS is security theatre - like taking your shoes off at the airport. I've been blocked on a CORS issue for 2 weeks now. Please avoid if possible.
Feedback wanted: CORS for private networks (RFC1918)
41–50 of 54 posts
Re: Feedback wanted: CORS for private networks (RFC1918)
#42Fuck this. It increases the complexity of browsers and servers and erects yet another burden for makers. And for what? So orgs with broken infrastructure (and budgets for running it) and device manufacturers (with budgets of their own) can keep up their garbage practices instead of fixing them? And they can push their costs onto a deep-pocketed company like Google who's willing to subsidize them? Here's to hoping tha…
Huh? I think you may have a very incorrect idea about who is being burdened here. A major effect of these changes is to make it simpler for anyone ("makers" included) to securely implement devices which expose web services, by making web browsers refuse to allow external web sites to send arbitrary requests to those devices. Most network devices have no need to receive such requests. No action is necessary on their p…
> I think you may have a very incorrect idea about who is being burdened here
Convenient stance, but no. It's possible to have a decent grasp on the proposal (thanks) and to mean what was written in the comment you're responding to above.
Your response belongs to a class of responses that can be called "well, you can just…" responses. The problem with these is that they tend to diminish what the just part is out of some lack of awareness and failure to truly take stock. (HN's infamous Dropbox comment can be considered an instance of a "well, you can just…" response.) And in your case, apparent unawareness that the response can be just as easily applied in the opposite direction—orgs with staff setting up insecure private networks can just do things the right way; device manufacturers who have software engineers but cheap out and take shortcuts can just stop doing that and commence with doing the thing they're getting paid for. And it turns out those justs make a lot more sense than the one that says ordinary people should deal with an even more complicated and hostile landscape that raises the barrier to entry for pulling off small accomplishments _without_ funding—just because some folks wanted to be able to offload their job duties.
And there was no suggestion that implementing this is a "huge burden" for _existing_ browser vendors. The fact that you seque there from a point about how browsers "already implement complex CORS policies" shows your failure to grasp the point that was being made.
Re: Feedback wanted: CORS for private networks (RFC1918)
#43Requiring HTTPS for services on the private network seems rather extreme. How do you even do HTTPS on a private network not attached to some publicly-resolvable external domain without installing the root certificate on all devices?
The proposal does not attempt to force private network resources to use TLS. That would be an excellent outcome, but it's difficult to do in the status quo, and is a separate problem to address separately.
The proposal _does_ require pages that wish to request resources across a network boundary to be delivered securely, which therefore requires resources that wish to be accessible across network boundaries to be served securely (as they'd otherwise be blocked as mixed content). This places the burden upon those resources which wish to be included externally, which seems like the right place for it to land.
Re: Feedback wanted: CORS for private networks (RFC1918)
#44The example feedback goes a bit in that direction, but how would that interact with mixed content? Say, I have a server running on 192.168.1.1. The box is only accessible through its IP address, so I can't get a public certificate for it and therefore can't enable https. I cannot access the box from a http site due to the new restriction. I cannot access the box from a https site due to mixed content. So I cannot acc…
Correct. In the status quo, you will be best-served by looking at solutions similar to what Plex is shipping (https://blog.filippo.io/how-plex-is-doing-https-for-all-its-...). ACME's DNS-based challenges might even make this easier today than it was when that mechanism was designed.
Longer-term, it seems clear that it would be valuable to come up with ways in which we can teach browsers how to trust devices on a local network. Thus far, this hasn't been a heavy area of investment. I can imagine it becoming more important if we're able to ship restrictions like the ones described here, as they do make the capability to authenticate and encrypt communication channels to local devices more important.
Re: Feedback wanted: CORS for private networks (RFC1918)
#45I am thinking of use cases and I think one would be folding@home. Their Web client is hosted on their public website and it makes http calls to a localhost:port running on a background service. Is that correct or have I misunderstood?
Yes, but since they control the background service too, they can just update the service to make it respond to CORS requests.
The core assertion behind this proposal is that devices and services running on a local network can continue making themselves available to external networks if and only if they can update themselves to make that desired relationship explicit. If they can't update themselves, they also can't fix security bugs, and really must not be exposed to the web.
Re: Feedback wanted: CORS for private networks (RFC1918)
#46Assuming I'm running malware.com, I would make 192-168-0-1.router.malware.com resolve to 192.168.0.1 so the origin matches and I can prod the router as much as I'd like without crossing the origin.
The proposal talks about sites resolving to private/local addresses, so presumably, the browser would still apply the checks to all requests to that domain. The only thing that would not trigger CORS is if you somehow loaded a top-level document from that domain. (The address is in the browser's address bar) - however, a malicious website can't do that as this server is not under their control.
Correct. https://wicg.github.io/cors-rfc1918/#dns-rebinding describes this reasoning.
Re: Feedback wanted: CORS for private networks (RFC1918)
#47Question: This talks about public-to-private and private-to-local requests. Does the proposal also apply to private-to-private? E.g., if a page at 192.168.1.1 fetches a resource from 192.168.1.2, will that also trigger the new rules?
That's an open question (https://wicg.github.io/cors-rfc1918/#issue-207ba0b9). Feedback welcome!
Re: Feedback wanted: CORS for private networks (RFC1918)
#48Also I don't understand how this works with IPv6 initiative that wants every device have a public IP address. The same goes for IPv4 routers - on many of them you could use the public IP to do the drive-by attack.
IPv6 does indeed complicate things. I suspect we'll end up trying a few things before finding the right answer, starting with a) allowing network admins to configure IP ranges that correspond to the network they control, and b) examining the local network to infer a private range.
Happily(?), IPv4 networks are still pervasive, and this proposal seems clearly valuable in those environments.
Re: Feedback wanted: CORS for private networks (RFC1918)
#49Earlier quoted context omitted.
"Local", in this context, means localhost (i.e. the machine that the web browser is running on). It does not mean other machines on the private network. Generally speaking, this simply enforces that, if you are running a web server on your local machine, external web sites (either on your private network or on the Internet at large) cannot trigger requests to that web server.
Yes, but that would mean that a web page served from 192.168.1.1 wouldn't be able to talk with a deamon on localhost if I understand that correctly - unless the private site speaks https, has a domain on the public DNS with a valid cert, etc etc.
Correct. But that's a really weird use case, and one which deserves some attention to security. The local network can contain untrusted devices (or devices which can be subverted into behaving in untrustworthy ways), after all; it's no more appropriate to allow one of them to access a daemon running on localhost than it would be to allow an arbitrary web site to do so.
Re: Feedback wanted: CORS for private networks (RFC1918)
#50This change can't come soon enough. My only objection is that the rollout is way too slow, and the first step is only a baby step. What we have now is essential a 0day situation. Unfortunately a lot of commenters completely misunderstand the proposal, as well as the attacks it is designed to mitigate. Here's a good paper describing the issue, "Attacking the internal network from the public Internet using a browser as…
> The "HTTPS" part of Google's proposal is a bit of a red herring, as I said, only a baby step.
It's in there for the same reason that risky APIs like geolocation require HTTPS -- so that injecting content into an insecure HTTP transaction cannot allow an attacker to hijack a trusted HTTP site's permissions.