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

A proposal to restrict sites from accessing a users’ local network

github.com

Post reply on HN
Print view View original

181–190 of 392 posts

Re: A proposal to restrict sites from accessing a users’ local network

#181

Post by cwillu »

kmeisthax wrote: post #79
buildfocus wrote: post #63

Earlier quoted context omitted.

This is a misunderstanding. Local network devices are protected from random websites by CORS, and have been for many years. It's not perfect, but it's generally quite effective. The issue is that CORS gates access only on the consent of the target server. It must return headers that opt into receiving requests from the website. This proposal aims to tighten that, so that even if the website and the network device bot…

THE MYTH OF "CONSENSUAL" REQUESTS Client: I consent Server: I consent User: I DON'T! ISN'T THERE SOMEBODY YOU FORGOT TO ASK?

Does anyone remember when the user-agent was an agent of the user?

Re: A proposal to restrict sites from accessing a users’ local network

#183

Post by rerdavies »

donnachangstein wrote: post #120
rerdavies wrote: post #112

I worry that there are problems with Ipv6. Can anyone explain to me if there actually is a way to determine whether an IPv6 is site local? If not, the proposal is going to have problems on IPv6-only networks. I have an struggled with this issue in the past. I have an IoT application whose websever wants to reject any requests from a non-local address. After failing to find a way to distinguish IPv6 local addresses, I…

> Can anyone explain to me if there is any way to determine whether an inbound IPv6 address is "local"? No, because it's the antithesis of IPv6 which is supposed to be globally routable. The concept isn't supposed to exist. Not to mention Google can't even agree on the meaning of "local" - the article states they completely changed the meaning of "local" to be a redefinition of "private" halfway through brainstorming…

@donnachangstein:

The device is an IoT guitar pedal that runs on a Raspberry Pi. In performance, on stage, a Web UI runs on a phone or tablet over a hotspot connection on the PI, which is NOT internet connected (since there's no expectation that there's a Wi-Fi router or internet access at a public venue). OR the pi runs on a home wifi network, using a browser-hosted UI on a laptop or desktop. OR, I suppose over an away-from-home Wi-Fi connection at a studio or rehearsal space, I suppose.

It is not reasonable to expect my users to purchase domain names and certs for their $60 guitar pedal, which are not going to work anyway, if they are playing away from their home network. Nor is ACME provisioning an option because the device may be in use but unconnected to the internet for months at a time if users are using the Pi Hotspot at home.

I can't use password authentication to get access to the Pi Web server, because I can't use HTTPS to conceal the password, and browsers disable access to javascript crypto APIs on non non-HTTPS pages (not that I'd really trust myself to write javascript code to obtain auth tokens from the pi server anyway), so doing auth over an HTTP connection doesn't really strike me as a serious option either..

Nor is it reasonable to expect my non-technical users to spend hours configuring their networks. It's an IoT device that should be just drop and play (maybe with a one-time device setup that takes place on the Pi).

There is absolutely NO way I am going to expose the server to the open internet without HTTPS and password authentication. The server provides a complex API to the client over which effects are configured and controlled. Way too much surface area to allow anyone of the internet to poke around in. So it uses IP/4 isolation, which is the best I can figure out given the circumstances. It's not like I havem't given the problem serious consideration. I just don't see a solution.

The use case is not hugely different from an IoT toothbrush. But standards organizations have chosen to leave both my (hypothetical) toothbrush and my application utterly defenseless when it comes to security. Is it any surprise that IoT toothbrushes have security problems?

How would YOU see https working on a device like that?

> ".local" is reserved for mDNS and is in the RFC, though this is frequently and widely ignored.

Yes. That was my point. It is currently widely ignored.

Re: A proposal to restrict sites from accessing a users’ local network

#185

Post by eternityforest »

I really hope this gets implemented, and more importantly, I really hope they have the ability to access an HTTP local site from an HTTPS domain.

There are so many excellent home automation and media/entertainment use cases for something like this.

Re: A proposal to restrict sites from accessing a users’ local network

#186

Post by aaronmdjones »

JdeBP wrote: post #164
profmonocle wrote: post #31

Assuming that RFC1918 addresses mean "local" network is wrong. It means "private". Many large enterprises use RFC1918 for private, internal web sites. One internal site I spend hours a day using has a 10.x.x.x IP address. The servers for that site are on the other side of the country and are many network hops away. It's a big company, our corporate network is very very large. A better definition of "local IP" would b…

Many years ago, before it was dropped, IP version 6 had a concept of "site local" addresses, which (if it had applied to version 4) would have encompassed the corporate intranet addresses that you are talking about. Routed within the corporate intranet; but not routed over corporate borders. Think of this proposal's definition of "local" (always a tricky adjective in networking, and reportedly the proposers here have…

fd00::/8 (within fc00::/7) is still reserved for this purpose (site-local IPv6 addressing).

fc00::/8 (a network block for a registry of organisation-specific assignments for site-local use) is the idea that was abandoned.

Roughly speaking, the following are analogs:

169.254/16 -> fe80::/64 (within fe80::/10)

10/8, 172.16/12, 192.168/16 -> a randomly-generated network (within fd00::/8)

For example, a service I maintain that consists of several machines in a partial WireGuard mesh uses fda2:daf7:a7d4:c4fb::/64 for its peers. The recommendation is no larger than a /48, so a /64 is fine (and I only need the one network, anyway).

fc00::/7 is not globally routable.

Re: A proposal to restrict sites from accessing a users’ local network

#187

Post by rerdavies »

donnachangstein wrote: post #131
ryanisnan wrote: post #129

Earlier quoted context omitted.

It's very useful to have this additional information in something like a network address. I agree, you shouldn't rely on it, but IPv6 hasn't clicked with me yet, and the whole "globally routable" concept is one of the reasons. I hear that, and think, no, I don't agree.

Globally routable doesn't mean you don't have firewalls in between filtering and blocking traffic. You can be globally routable but drop all incoming traffic at what you define as a perimeter. E.g. the WAN interface of a typical home network. The concept is frequently misunderstood in that IPv4 consumer SOHO "routers" often combine a NAT and routing function with a firewall, but the functions are separate.

It is widely understood that my SOHO router provides NAT for IPV4, and routing+firewall (but no NAT) for IPV6. And provides absolutely no configuability for the IpV6 firewall (which would be extremely difficult anyway) because all of the IPV6 addresses allocated to devices on my home network are impermanent and short-lived.

Re: A proposal to restrict sites from accessing a users’ local network

#188

Post by londons_explore »

Aeolun wrote: post #121
buildfocus wrote: post #63

Earlier quoted context omitted.

This is a misunderstanding. Local network devices are protected from random websites by CORS, and have been for many years. It's not perfect, but it's generally quite effective. The issue is that CORS gates access only on the consent of the target server. It must return headers that opt into receiving requests from the website. This proposal aims to tighten that, so that even if the website and the network device bot…

How would Facebook do that? They scan all likely local ranges for what could be your phone, and have a web server running on the phone? That seems more like a problem of allowing the phone app to start something like that and keep it running in the background.

Webrtc allows you to find the local ranges.

Typically there are only 256 IP's, so a scan of them all is almost instant.

Re: A proposal to restrict sites from accessing a users’ local network

#189

Post by rerdavies »

zajio1am wrote: post #56

This seems like a silly solution, considering we are in the middle of IPv6 transition, where local networks use public addresses.

Whatever happened to IPv6 site-local and link local address ranges (address ranges that were specifically defined as address ranges that would not cross router or WAN boundaries? They were in the original IPv6 standards, but don't seem to be implemented or supported. Or at least they aren't implemented or supported by my completely uconfigurable home cable router povided by my ISP.

Re: A proposal to restrict sites from accessing a users’ local network

#190

Post by thaumasiotes »

paxys wrote: post #84

It's crazy to me that this has always been the default behavior for web browsers. A public website being able to silently access your entire filesystem would be an absurd security hole. Yet all local network services are considered fair game for XHR, and security is left to the server itself. If you are developer and run your company's webapp on your dev machine for testing (with loose or non-existent security defaul…

> Does every one of them have the correct CORS configuration?

I would guess it's closer to 0% than 0.1%.

Post reply on HN