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

91–100 of 392 posts

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

#91

Post by MajesticHobo2 »

LegionMammal978 wrote: post #76
tombakt wrote: post #69

Earlier quoted context omitted.

No, a preflight (OPTIONS) request is sent by the browser first prior to sending the request initiated by the application. I would be surprised if it is possible for the client browser to control this OPTIONS request more than just the URL. I am curious if anyone else has any input on this topic though. Maybe there is some side-channel timing that can be used to determine the existence of a device, but not so sure abo…

The idea is, the malicious actor would use a 'simple request' that doesn't need a preflight (basically, a GET or POST request with form data or plain text), and manage to construct a payload that exploits the target device. But I have yet to see a realistic example of such a payload (the paper I read about the idea only vaguely pointed at the existence of polyglot payloads).

There doesn't need to be any kind of "polyglot payload". Local network services and devices that accept only simple HTTP requests are extremely common. The request will go through and alter state, etc.; you just won't be able to read the response from the browser.

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

#92

Post by numpad0 »

Personally I had completely forgotten that anyone and anything can do this right now.

TLDR, IIUC, right now, random websites can try accessing contents on local IPs. You can try to blind load e.g. http://192.168.0.1/cgi-bin/login.cgi from JavaScript, iterating through a gigantic malicious list of such known useful URLs, then grep and send back whatever you want to share with advertisers or try POSTing backdoors to printer update page. No, we don't need that.

Of course, OTOH, many webapps today use localhost access to pass tokens and to talk to cooperating apps, but you only need access to 127.0.0.0/8 for that which is harder to abuse, so that range can be default exempted.

Disabling this, as proposed, does not affect your ability to open http://192.168.0.1/login.html, as that's just another "web" site. If JS on http://myNAS.local/search-local.html wants to access http://myLaptop.local:8000/myNasDesktopAppRemotingApi, only then you have to click some buttons to allow it.

Edit: uBlock Origin has filter for it[1]; was unchecked in mine.

1: https://news.ycombinator.com/item?id=44184799

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

#93

Post by jaywee »

ale42 wrote: post #60
kccqzy wrote: post #34

Earlier quoted context omitted.

The article spends a lot of effort defining the words "local" and "private" here. It then says: > Note that local -> local is not a local network request So your use case won't be affected.

The computer I use at work (and not only mine, many many of them) has a public IP address. Many internal services are on 10.0.0.0/8. How is this being taken into account?

Ideally, in an organization this should be a centrally pushed group policy defining CIDRs.

Like, at home, I have 10/8 and public IPv6 addresses.

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

#94

Post by kuschku »

michaelt wrote: post #44
ronsor wrote: post #3

Do note that since the removal of NPAPI plugins years ago, locally-installed software that intends to be used by one or more public websites has to run an HTTP server on localhost. It would be really annoying if this use case was made into an unreasonable hassle or killed entirely. (Alternatively, browser developers could've offered a real alternative, but it's a bit late for that now.)

Doesn't most software just register a protocol handler with the OS? Then a website can hand the browser a zoommtg:// link, which the browser opens with zoom ? Things like Jupyter Notebooks will presumably be unaffected by this, as they're not doing any cross-origin requests. And likewise, when a command line tool wants you to log in with oauth2 and returns you to a localhost URL, it's a simple redirect not a cross-or…

A common use case, whether for 3D printers, switches, routers, or NAS devices is that you've got a centrally hosted management UI that then sends requests directly to your local devices.

This allows you to use a single centrally hosted website as user interface, without the control traffic leaving your network. e.g. Plex uses this.

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

#95

Post by derefr »

paxys wrote: post #71
skybrian wrote: post #36

While this will help to block many websites that have no business making local connections at all, it's still very coarse-grained. Most websites that need this permission only need to access one local server. Granting them access to everything violates the principle of least privilege. Most users don't know what's running on localhost or on their local network, so they won't understand the risk.

> Most users don't know what's running on localhost or on their local network, so they won't understand the risk. Yes, which is why they also won't understand when the browser asks if you'd like to allow the site to visit http://localhost:3146 vs http://localhost:8089 . A sensible permission message ("allow this site to access resources on your local network") is better than technical mumbo jumbo which will make them…

In an ideal world, the browser could act as an mDNS client, discovering local services, so that it could then show the pretty name of the relevant service in the security prompt.

In the world we live in, of course, almost nothing on your average LAN has an associated mDNS service advertisement.

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

#96

Post by xp84 »

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…

Is it a gross generalization to say that if you're visiting a site whose name resolves to a private IP address, it's a part of the same organizational entity as your computer is?

The proposal here would consider that site local and thus allowed to talk to local. What are the implications? Your employer whose VPN you're on, or whose physical facility you're located in, can get some access to the LAN where you are.

In the case where you're a remote worker and the LAN is your private home, I bet that the employer already has the ability to scan your LAN anyway, since most employers who are allowing you onto their VPN do so only from computers they own, manage, and control completely.

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

#97

Post by michaelt »

kuschku wrote: post #94
michaelt wrote: post #44

Earlier quoted context omitted.

Doesn't most software just register a protocol handler with the OS? Then a website can hand the browser a zoommtg:// link, which the browser opens with zoom ? Things like Jupyter Notebooks will presumably be unaffected by this, as they're not doing any cross-origin requests. And likewise, when a command line tool wants you to log in with oauth2 and returns you to a localhost URL, it's a simple redirect not a cross-or…

A common use case, whether for 3D printers, switches, routers, or NAS devices is that you've got a centrally hosted management UI that then sends requests directly to your local devices. This allows you to use a single centrally hosted website as user interface, without the control traffic leaving your network. e.g. Plex uses this.

I don't think this proposal will stop you visiting the management UI for devices like switches and NASes on the local network. You'll be able to visit http://192.168.0.1 and it'll work just fine?

This is just about blocking cross-origin requests from other websites. I probably don't want every ad network iframe being able to talk to my router's admin UI.

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

#98

Post by hypercube33 »

kuschku wrote: post #94
michaelt wrote: post #44

Earlier quoted context omitted.

Doesn't most software just register a protocol handler with the OS? Then a website can hand the browser a zoommtg:// link, which the browser opens with zoom ? Things like Jupyter Notebooks will presumably be unaffected by this, as they're not doing any cross-origin requests. And likewise, when a command line tool wants you to log in with oauth2 and returns you to a localhost URL, it's a simple redirect not a cross-or…

A common use case, whether for 3D printers, switches, routers, or NAS devices is that you've got a centrally hosted management UI that then sends requests directly to your local devices. This allows you to use a single centrally hosted website as user interface, without the control traffic leaving your network. e.g. Plex uses this.

Windows Admin center but it's only local which I rather hate

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

#99

Post by kuschku »

kccqzy wrote: post #37
AStonesThrow wrote: post #11

Chris Siebenmann weighs in with thoughts on: Browers[sic] can't feasibly stop web pages from talking to private (local) IP addresses (2019) https://utcc.utoronto.ca/~cks/space/blog/web/BrowsersAndLoca...

The split horizon DNS model mentioned in that article is to me insane. Your DNS responses should not change based on what network you are connected to. It breaks so many things. For one, caching breaks because DNS caching is simplistic and is only cached with a TTL: no way to tell your OS to associate a DNS cached response to a network. I understand why some companies want this, but doing it on the DNS level is a mas…

I'm surprised you've never seen this before.

Especially for universities it's very common to have the same hostname resolve to different servers, and provide different results, depending on whether you're inside the university network or not.

Some sites may require login if you're accessing them from the internet, but are freely accessible from the intranet.

Others may provide read-write access from inside, but limited read-only access from the outside.

Similar situations with split-horizon DNS are also common in corporate intranets or for people hosting Plex servers.

Ultimately all these issues are caused by NAT and would disappear if we switched to IPv6, but that would also circumvent the OP proposal.

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

#100

Post by numpad0 »

ale42 wrote: post #60
kccqzy wrote: post #34

Earlier quoted context omitted.

The article spends a lot of effort defining the words "local" and "private" here. It then says: > Note that local -> local is not a local network request So your use case won't be affected.

The computer I use at work (and not only mine, many many of them) has a public IP address. Many internal services are on 10.0.0.0/8. How is this being taken into account?

10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 are all private addresses per RFC1918 and documents superseding it(5735?). If it's like 66.249.73.128/27 or 164.13.12.34/12, those are "global" IP.

1: https://www.rfc-editor.org/rfc/rfc1918

2: https://www.rfc-editor.org/rfc/rfc5735

3: https://en.wikipedia.org/wiki/Private_network

Post reply on HN