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

Feedback wanted: CORS for private networks (RFC1918)

web.dev

Post reply on HN
Print view View original

21–30 of 54 posts

Re: Feedback wanted: CORS for private networks (RFC1918)

#21

Post by AntonyGarand »

xg15 wrote: post #3

The 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…

Depending on what interactions you want, only the origin host would require https.

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.

Re: Feedback wanted: CORS for private networks (RFC1918)

#22

Post by zeroimpl »

cratermoon wrote: post #11
janci wrote: post #6

I 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.

But what about those vulnerabilities is specific to being on a private network? If we can find a public website with the same vulnerability, will we start enforcing stricter CORS requirements everywhere?

Re: Feedback wanted: CORS for private networks (RFC1918)

#23

Post by zeroimpl »

TimWolla wrote: post #4
xg15 wrote: post #3

The 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…

> 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 closes, then the AJAX request gets retried and succeeds.

While this works for an internal application, it would be unacceptable for any consumer product.

Re: Feedback wanted: CORS for private networks (RFC1918)

#25

Post by mook »

bawolff wrote: post #13
lilyball wrote: post #7

Requiring 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?

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 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.

Re: Feedback wanted: CORS for private networks (RFC1918)

#26

Post by nickphx »

lilyball wrote: post #7

Requiring 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?

That's not how I understood it. "Make sure the website making requests to a private network is served over HTTPS."

My understanding of it is the site making the call to the resource on the 'private' network, must be served via HTTPS.

Re: Feedback wanted: CORS for private networks (RFC1918)

#27

Post by duskwuff »

pwdisswordfish4 wrote: post #5

Fuck 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 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.

Re: Feedback wanted: CORS for private networks (RFC1918)

#28

Post by duskwuff »

AntonyGarand wrote: post #20
bawolff wrote: post #14

Earlier quoted context omitted.

I just read the proposal. I do not see where it says that internal services will require https. 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.

It does mention private to local requests will be affected, which is implying the private network host must be served via https > Requests from a private network to a local network https://web.dev/cors-rfc1918-feedback/#what-kinds-of-request...

"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.

Re: Feedback wanted: CORS for private networks (RFC1918)

#29

Post by xg15 »

cratermoon wrote: post #10
pwdisswordfish4 wrote: post #5

Fuck 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…

It's probably wrong to consider any 'private' network to be secure any more. With zero-trust principles in mind, you wouldn't necessarily believe every device or system on your network is trusted, so you ensure that what is able to send and receive traffic on your network has other mechanisms in place for trust and authenticity.

I mean, you have to hand it to them that the point of this change is to strengthen the security of "everything in LAN is trusted" networks: Using the browser as a gateway to access internal services is one of the most important ways to break into local networks.

Re: Feedback wanted: CORS for private networks (RFC1918)

#30

Post by xg15 »

duskwuff wrote: post #28
AntonyGarand wrote: post #20

Earlier quoted context omitted.

It does mention private to local requests will be affected, which is implying the private network host must be served via https > Requests from a private network to a local network https://web.dev/cors-rfc1918-feedback/#what-kinds-of-request...

"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.
Post reply on HN