A proposal to restrict sites from accessing a users’ local network • Hacker News Board

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

#121

Post by Aeolun » Wed, Jun 04, 2025, 10:51 PM UTC

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…

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.

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

#122

Post by Aeolun » Wed, Jun 04, 2025, 10:53 PM UTC

mastazi wrote: post #117

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.

Do we have any evidence that most users just click yes? My parents who are non-technical click no by default to everything, sometimes they ask for my assistance when something doesn't work and often it's because they denied some permission that is essential for an app to work e.g. maybe they denied access to the microphone to an audio call app. Unless we have statistics, I don't think we can make assumptions.

As a counter example, I think all these dialogs are annoying as hell and click yes to almost everything. If I’m installing the app I have pre-vetted it to ensure it’s marginally trustworthy.

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

#123

Post by layer8 » Wed, Jun 04, 2025, 10:54 PM UTC

tombakt wrote: post #69

xp84 wrote: post #64

Earlier quoted context omitted.

Doesn't CORS just restrict whether the webpage JS context gets to see the response of the target request? The request itself happens anyway, right? So the attack vector that I can imagine is that JS on the browser can issue a specially crafted request to a vulnerable printer or whatever that triggers arbitrary code execution on that other device. That code might be sufficient to cause the printer to carry out your ev…

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…

There is a limited, but potentially effective, attack surface via URL parameters.

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

#124

Post by drexlspivey » Wed, Jun 04, 2025, 10:54 PM UTC

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

It can send a json-rpc request to your bitcoin node and empty your wallet

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

#125

Post by Aeolun » Wed, Jun 04, 2025, 10:55 PM UTC

kulahan wrote: post #28

donnachangstein wrote: post #12

Earlier quoted context omitted.

[flagged]

I agree fully with him. I don’t care what part of your job gets harder, or what software breaks if you can’t make it work without unnecessarily invading my privacy. You could tell me it’s going to shut down the internet for 6 months and I still wouldn’t care. You’ll have to come up with a really strong defense for why this shouldn’t happen in order to convince most users.

It just means I run a persistent client on your device that is permanently connected to the mothership, instead of only when you have your browser open.

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

#126

Post by [deleted] » Wed, Jun 04, 2025, 10:57 PM UTC

hsbauauvhabzb wrote: post #65

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…

CORS prevents the site from accessing the response body. In some scenarios, a website could, for example, blindly attempt to authenticate to your router and modify settings by guessing your router bran/model and password

[deleted]

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

#127

Post by donnachangstein » Wed, Jun 04, 2025, 10:59 PM UTC

xp84 wrote: post #66

mystified5016 wrote: post #46

Earlier quoted context omitted.

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…

This is so true. The modern Mac is a sea of Allow/Don't Allow prompts, mixed with the slightly more infantilizing alternative of the "Block" / "Open System Preferences" where you have to prove you know what you're doing by manually browsing for the app to grant the permission to, to add it to the list of ones with whatever permission. They're just two different approaches with the same flaw: People with no clue how t…

> The modern Mac is a sea of Allow/Don't Allow prompts

Remember when they used to mock this as part of their marketing?

https://www.youtube.com/watch?v=DUPxkzV1RTc

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

#128

Post by otherayden » Wed, Jun 04, 2025, 11:01 PM UTC

This seems like such a no-brainer, I’m shocked this isn’t already something sites need explicit permission to do

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

#129

Post by ryanisnan » Wed, Jun 04, 2025, 11:01 PM UTC

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…

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.

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

#130

Post by rerdavies » Wed, Jun 04, 2025, 11:03 PM UTC

tombakt wrote: post #69

xp84 wrote: post #64

Earlier quoted context omitted.

Doesn't CORS just restrict whether the webpage JS context gets to see the response of the target request? The request itself happens anyway, right? So the attack vector that I can imagine is that JS on the browser can issue a specially crafted request to a vulnerable printer or whatever that triggers arbitrary code execution on that other device. That code might be sufficient to cause the printer to carry out your ev…

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…

I can confirm that local websites that don't implement CORS via the OPTIONS request cannot be browsed with mainstream browsers. Does nothing to prevent non-browser applications running on the local network from accessing your website.

As far as I can tell, the only thing this proposal does that CORS does not already do is provide some level of enterprise configuration control to guard against the scenario where your users are using compromised internet sites that can ping around your internal network for agents running on compromised desktops. Maybe? I don't get it.

If somebody would fix the "no https for local connections" issue, then IoT websites could use authenticated logins to fix both problems. Non-https websites also have no access to browser crypto APIs so roll-your-own auth (the horror) isn't an option either. Fustrating!