Feedback wanted: CORS for private networks (RFC1918)
web.dev
web.dev
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 part; these changes will make those devices stop receiving those requests.
The few network devices that do need to receive those requests can opt in to receiving them by responding to a CORS probe (an OPTIONS HTTP request) with a specific HTTP header. This is not complicated to implement.
Web browsers already implement complex CORS policies. Adding this is not a huge burden upon them, and may actually obviate the need for other more complex defenses.
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.
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 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 have your infrastructure be using proper domains and things. For your neighbor's network behind his router… not so much. Nothing that requires TLS does.
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.
That said, regardless of what one does, i wouldn't reccomend putting too much faith in security by obscurity.
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.
My reading is that public websites making an ajax request to http://10.0.0.12 will need to be https. I'm not sure how that protects against anything, but it also doesn't affect the internal services themselves.
> Requests from a private network to a local network
https://web.dev/cors-rfc1918-feedback/#what-kinds-of-request...
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.
My understanding of it is the site making the call to the resource on the 'private' network, must be served via HTTPS.
There's nothing preventing you from creating another DNS zone.
How to do it? self-signed certs and distribute your own CA and install it across devices that are authorized to be on your network.
This is an unreasonable ask for the vast majority of users.
> 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.
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 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.
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 closes, then the AJAX request gets retried and succeeds.
While this works for an internal application, it would be unacceptable for any consumer product.
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.
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.
If you need passive mixed content, I believe it is and will remain supported by browsers for some time.
If you need active mixed content though you probably will need a workaround via passive content instead.
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.
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.
Happily(?), IPv4 networks are still pervasive, and this proposal seems clearly valuable in those environments.
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.
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?
I guess this still wouldn't protect against attacks on non http(s) services. So things like https://samy.pl/slipstream/ still work?