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

101–110 of 392 posts

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

#101

Post by kuschku »

michaelt wrote: post #97
kuschku wrote: post #94

Earlier quoted context omitted.

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.

That's not what I'm talking about.

A common example is this:

1. I visit ui.manufacturer.tld

2. I click "add device" and enter 192.168.0.230, repeating this for my other local devices.

3. The website ui.manufacturer.tld now shows me a dashboard with aggregate metrics from all my switches and routers, which it collects by fetch(...) ing data from all of them.

The manufacturers site is just a static page. It stores the list of devices and credentials to connect to them in localStorage.

None of the data ever leaves my network, but I can just bookmark ui.manufacturer.tld and control all of my devices at once.

This is a relatively neat approach providing the same comfort as cloud control, without the privacy nightmare.

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

#102

Post by mirashii »

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

You don't even need to be exploiting the target device, you might just be leaking data over that connection.

https://news.ycombinator.com/item?id=44169115

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

#103

Post by zbuttram »

planb wrote: post #47
grokkedit wrote: post #45

Earlier quoted context omitted.

problem is: without allowing it webUIs like synology won't work, since they require your browser to connect to the local network... as it is, it's not great

Why? I’d guess requests from a local network site to itself (maybe even to others on the same network) will be allowed.

With the proposal in the OP, I would think so yes. But the MacOS setting mentioned directly above is blanket per-app at the OS level.

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

#104

Post by cAtte_ »

spiffyk wrote: post #90
xp84 wrote: post #72

Earlier quoted context omitted.

#1 use case would be a password manager. It would be best if the browser plugin part can ping say, the 1password native app, which runs locally on your pc, and say "Yo I need a password for google.com" - then the native app springs into action, prompts for biometrics, locates the password or offers the user to choose, then returns it directly to the browser for filling. Sure you can make a fully cloud-reliant PW mana…

Browser extensions play by very different rules than websites already. The proposal is for the latter and I doubt it is going to affect the former, other than MAYBE an extra permanent permission.

you missed the point. password managers are one of the many use cases for this feature; that they just so happen to be mostly implemented as extensions does not mean that the feature is only useful for extensions

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

#105

Post by ameliaquining »

mystified5016 wrote: post #46
lucideer wrote: post #40

Earlier quoted context omitted.

> normal users could configure it themselves, just show a popup "this website wants to control local devices - allow/deny". MacOS currently does this (per app, not per site) & most users just click yes without a second thought. Doing it per site might create a little more apprehension, but I imagine not much.

I can't believe that anyone still thinks a popup permission modal offers any type of security. Windows UAC has shown quite definitively that users will always click through any modal in their way without thought or comprehension. Besides that, approximately zero laypersons will have even the slightest clue what this permission means, the risks involved, or why they might want to prevent it. All they know is that the…

I don't think anyone's under the impression that this is a perfect solution. But it's better than nothing, and the options are this, nothing, or a security barrier that can't be bypassed with a permission prompt. And it was determined that the latter would break too many existing sites that have legitimate (i.e., doing something the end user actively wants) reason to talk to local devices.

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

#106

Post by lilyball »

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?

Your computer's own IP address is completely irrelevant. What matters is the site hostname and the IP address it resolves to.

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

#108

Post by ameliaquining »

buildfocus wrote: post #63
mystifyingpoi wrote: post #10

I like this on the first glance. The idea of a random website probing arbitrary local IPs (or any IPs for that matter) with HTTP requests is insane. I wouldn't care if it breaks some enterprise apps or integrations - enterprises could reenable this "feature" via management tools, normal users could configure it themselves, just show a popup "this website wants to control local devices - allow/deny".

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…

Is this kind of attack actually in scope for this proposal? The explainer doesn't mention it.

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

#110

Post by paxys »

lucideer wrote: post #40
mystifyingpoi wrote: post #10

I like this on the first glance. The idea of a random website probing arbitrary local IPs (or any IPs for that matter) with HTTP requests is insane. I wouldn't care if it breaks some enterprise apps or integrations - enterprises could reenable this "feature" via management tools, normal users could configure it themselves, just show a popup "this website wants to control local devices - allow/deny".

> normal users could configure it themselves, just show a popup "this website wants to control local devices - allow/deny". MacOS currently does this (per app, not per site) & most users just click yes without a second thought. Doing it per site might create a little more apprehension, but I imagine not much.

People accept permission prompts from apps because they conciously downloaded the app and generally have an idea about the developer and what the app does. If a social media app asks for permission to your photos it's easy to understand why, same with a music streamer wanting to connect to your smart speaker.

A random website someone linked me to wanting to access my local network is a very different case. I'm absolutely not giving network or location or camera or any other sort of access to websites except in very extreme circumstances.

Post reply on HN