Question: 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?
Feedback wanted: CORS for private networks (RFC1918)
31–40 of 54 posts
Re: Feedback wanted: CORS for private networks (RFC1918)
#32Earlier quoted context omitted.
Just because your domain is public doesn't mean your DNS is public as well. You can use a cert signed by a public CA in a private network just fine so long as you're using the right DNS setup.
Except that a lot of places have .local (which is terrible, I know, but still lots of places have it), or .lan. A public CA won't create certs for those.
Just because your internal domain for your computers ends in .local does not mean your internal websites need to end in .local.
There's nothing preventing you from creating another DNS zone.
Re: Feedback wanted: CORS for private networks (RFC1918)
#33Earlier quoted context omitted.
> So I cannot access the box anymore at all? My understanding is that you can access it directly. But you can't embed e.g. images or JavaScript from that server within a website running on a public IP address. I consider that a good thing.
You cannot make an AJAX call from an HTTPS site to a HTTP site on a local IP address. One of the internal web applications I develop (which is hosted over HTTPS itself) has to workaround this by doing the connection from the browser to the local IP address over HTTPS, but upon detecting HTTPS cert errors it opens a popup and walks the user through the process of adding an exception to connect anyways. Once that popup…
You cannot make an AJAX call from an HTTPS site to a HTTP site on a local IP address.
This was sort of my point - because with the new rules in place, I cannot make an AJAX call from a HTTP site to an internal address either.
Re: Feedback wanted: CORS for private networks (RFC1918)
#34Assuming 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.
Re: Feedback wanted: CORS for private networks (RFC1918)
#35I don't get it. What's wrong with normal CORS? They do work for private networks. Also I don't think browsers are the right place to do this kind of protection.
It says right there in the proposal > status quo CORS protections don’t protect against the kinds of attacks discussed here as they rely only on CORS-safelisted methods and CORS-safelisted request-headers. No preflight is triggered, and the attacker doesn’t actually care about reading the response, as the request itself is the CSRF attack.
Ok, this will protect old unpatched vulnerable devices. But what will prevent a negligent manufacturer that uses HTTP GET without CSFR protection to apply configuration to the device from just adding the CORS opt-in header everywhere? I mean it would be the simplest solution for them.
Re: Feedback wanted: CORS for private networks (RFC1918)
#36Fuck 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…
The whole DNS rebinding thing makes this very complicated to implement correctly in browsers. (I.e. the public/private status of a domain name can change in time under attacker control)
Re: Feedback wanted: CORS for private networks (RFC1918)
#37Also 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.
Re: Feedback wanted: CORS for private networks (RFC1918)
#38Earlier quoted context omitted.
If you are running a private intranet type thing, installing your own root certs seems fairly reasonable to me. You could also just have the dns be public. No reason why private networks can't be in public dns. If you are really paranoid use wildcard certs, and only have top domain be in the public dns.
How the heck would I go about installing my own root cert into my TV? My fridge? (I'm picking devices here that could actually run browsers.) How the heck would I have my DNS be public, if I don't have a domain? Getting one means a cost (some amount for the registration, plus whatever you consider costs to avoid your information in the registry getting leaked) For large corporations, yes it totally makes sense to hav…
In the context of this proposal, i'm not sure why your routers and stuff would need one, it seems like only corporate stuff would be affected.
That said, for a router, it would be vendors responsibility to set this all up. It seems possible but annoying to do this in a secure but privacy preserving way.
Re: Feedback wanted: CORS for private networks (RFC1918)
#39I can't fathom why anyone would be up in arms against preventing random websites from accessing servers running on localhost or inside home networks. This is not about "web bloat," as some people are suggesting, but rather closing a gaping security hole that should never have existed from the start.
Re: Feedback wanted: CORS for private networks (RFC1918)
#40This 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 a proxy": https://www.forcepoint.com/sites/default/files/resources/fil...
The "HTTPS" part of Google's proposal is a bit of a red herring, as I said, only a baby step. It does not mean that your local services have to be https. It just means that public http sites can't make requests to local IP addresses.