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

#261

Post by Thorrez » Thu, Jun 05, 2025, 1:12 PM UTC

jm4 wrote: post #148

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 sounds crazy to me. Why should websites ever have access to the local network? That presents an entirely new threat model for which we don’t have a solution. Is there even a use case for this for which there isn’t already a better solution?

>Why should websites ever have access to the local network?

It's just the default. So far, browsers haven't really given different IP ranges different security.

evil.com is allowed to make requests to bank.com . Similarly, evil.com is allowed to make requests to foo.com even if foo.com DNS resolves to 127.0.0.1 .

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

#262

Post by kevincox » Thu, Jun 05, 2025, 1:15 PM UTC

xp84 wrote: post #77

paxys wrote: post #71

Earlier quoted context omitted.

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

Either way they'll click "yes" as long as the attacker site properly primes them for it. For instance, on the phishing site they clicked on from an email, they'll first be prompted like: "Chase need to verify your Local Network identity to keep your account details safe. Please ensure that you click "Yes" on the following screen to confirm your identity and access account." Yes, that's meaningless gibberish but most…

This is true, but you can only protect people from themselves so far. At some point you gotta let them do what they want to do. I don't want to live in a world where Google decides what we are and aren't allowed to do.

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

#263

Post by Thorrez » Thu, Jun 05, 2025, 1:17 PM UTC

socalgal2 wrote: post #153

I wish they'd (Apple/Micrsoft/Google/...) would do similar things for USB and Bluetooth. Lately, every app I install, wants bluetooth access to scan all my bluetooth devices. I don't want that. At most, I want the app to have to declare in their manifest some specific device IDs (short list) that their app is allowed to connect to and have the OS limit their connections to only those devices. For for example the Bose…

Are you talking about web apps, mobile apps, desktop apps, or browser extensions?

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

#264

Post by klabb3 » Thu, Jun 05, 2025, 1:18 PM UTC

graemep wrote: post #209

moktonar wrote: post #179

The web is currently just “controlled code execution” on your device. This will never work if not done properly. We need a real “web 3.0” where web apps can run natively and containerized, but done correctly, where they are properly sandboxed. This will bring performance and security.

The underlying problem is that we are trying to run untrusted code safel, with very few restrictions on its capabilities.

Disagree. Untrusted code was thought to be a meaningful term 20-30 years ago when you ran desktop OSs with big name software like Microsoft Word and Adobe, and games. What happened in reality is that this fence had false positives (ie Meta being one of your main adversaries) and an enormous amount of false negatives (all indie or small devs that would have their apps classified as viruses).

The model we need isn’t a boolean form of trust, but rather capabilities and permissions on a per-app, per-site or per-vendor basis. We already know this, but it’s incredibly tricky to design, retrofit and explain. Mobile OSs did a lot here, even if they are nowhere near perfect. For instance, they allow apps (by default even) to have private data that isn’t accessible from other apps on the same device.

Whether the code runs in an app or on a website isn’t actually important. There is no fundamental reason for the web to be constrained except user expectations and the design of permission systems.

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

#265

Post by chuckadams » Thu, Jun 05, 2025, 1:24 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).

Some devices don't bother to limit the size of the GET, which can enable a DOS attack at least, a buffer overflow at worst. But I think the most typical vector is a form-data POST, which isn't CSRF-protected because "it's on localhost so it's safe, right?"

I've been that sloppy with dev servers too. Usually not listening on port 80 but that's hardly Ft Knox.

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

#266

Post by sidewndr46 » Thu, Jun 05, 2025, 1:32 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…

This is also a misunderstanding. CORS only applies to the Layer 7 communication. The rest you can figure out from the timing of that.

Significant components of the browser, such as Websockets have no such restrictions at all

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

#267

Post by chuckadams » Thu, Jun 05, 2025, 1:33 PM UTC

rafram wrote: post #156

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…

You’re forgetting { mode: 'no-cors' }, which makes the response opaque (no way to read the data) but completely bypasses the CORS preflight request and header checks.

Thankfully no-cors also restricts most headers, including setting content-type to anything but the built-in form types. So while CSRF doesn't even need a click because of no-cors, it's still not possible to do csrf with a json-only api. Just be sure the server is actually set up to restrict the content type -- most frameworks will "helpfully" accept and convert form-data by default.

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

#268

Post by jbverschoor » Thu, Jun 05, 2025, 1:39 PM UTC

anthk wrote: post #208

grrowl wrote: post #206

Earlier quoted context omitted.

I remember back in the day you could embed http://someothersite.com/forum/ucp.php?mode=logout "> in your forum signature and screw with everyone's sessions across the web

It's essentially the same, as many apps use HTTP server + html client instead of something native or with another IPC.

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

#269

Post by chuckadams » Thu, Jun 05, 2025, 1:42 PM UTC

Thorrez wrote: post #261

jm4 wrote: post #148

Earlier quoted context omitted.

This sounds crazy to me. Why should websites ever have access to the local network? That presents an entirely new threat model for which we don’t have a solution. Is there even a use case for this for which there isn’t already a better solution?

>Why should websites ever have access to the local network? It's just the default. So far, browsers haven't really given different IP ranges different security. evil.com is allowed to make requests to bank.com . Similarly, evil.com is allowed to make requests to foo.com even if foo.com DNS resolves to 127.0.0.1 .

> It's just the default. So far, browsers haven't really given different IP ranges different security.

I remember having "zone" settings in Internet Explorer 20 years ago, and ISTR it did IP ranges as well as domains. Don't think it did anything about cross-zone security though.

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

#270

Post by ImPostingOnHN » Thu, Jun 05, 2025, 1:44 PM UTC

rhdunn wrote: post #235

ImPostingOnHN wrote: post #73

Earlier quoted context omitted.

> locally-installed software that intends to be used by one or more public websites has to run an HTTP server on localhost if that software runs with a pull approach, instead of a push one, the server becomes unnecessary bonus: then you won't have websites grossly probing local networks that aren't theirs (ew)

It's harder to run html and xml files with xslt by just opening them in a web browser (things like nunit test run output). To view these properly now -- to get the css, xslt, images, etc. to load -- you now typically have to run a web server at that file path. Note: this is why the viewers for these tools will spin up a local web server. With local LLMs and AI it is now common to have different servers for different…

I'm not sure any of that is necessary for what we're talking about: locally-installed software that intends to be used by one or more public websites.

For instance, my interaction with local LLMs involves 0 web browsers, and there's no reason facebook.com needs to make calls to my locally-running LLM.

Running HTML/XML files in the browser should be easier, but at the moment it already has the issues you speak of. It might make sense, IMO, for browsers to allow requests to localhost from websites also running on localhost.