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

301–310 of 392 posts

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

#301

Post by mixmastamyk »

lucideer wrote: post #199
mastazi wrote: post #117

Earlier quoted context omitted.

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.

I have no statistics but I wouldn't consider older parents the typical case here. My parents never click yes on anything but my young colleagues in non engineering roles in my office do. And I'd say even a decent % of the engineering colleagues do too - especially the vibe coders. And they all spend a lot more time on they computer then my parents.

Interesting parallel between the older-parents who (may have finally learned to) deny and young folks, supposed digital-natives a majority of which who don’t really understand how computers work.

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

#302

Post by vel0city »

rerdavies wrote: post #187
donnachangstein wrote: post #131

Earlier quoted context omitted.

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.

You can make those IPv6 IP addresses permanent and long-lived. They don't need to be short-lived addresses.

Also, I've seen lots of home firewalls which will identify a device based on MAC address for match criteria and let you set firewall rules based on those, so even if their IPv6 address does change often it still matches the traffic.

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

#303

Post by James_K »

sidewndr46 wrote: post #266
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…

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

Won't the browser still append the "Origin" field to WebSocket requests, allowing servers to reject them?

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

#304

Post by necovek »

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?

Not a local network, but localhost example: due to the lousy private certificate capability APIs in web browsers, this is commonly used for signing with electronic IDs for countries issuing smartcard certificates for their citizens (common in Europe). Basically, a web page would contact a web server hosted on localhost which was integrated with PKCS library locally, providing a signing and encryption API.

One of the solutions in the market was open source up to a point (Nowina NexU), but it seems it's gone from GitHub

For local network, you can imagine similar use cases — keep something inside the local network (eg. an API to an input device; imagine it being a scanner), but enable server-side function (eg. OCR) from their web page. With ZeroConf and DHCP domain name extensions, it can be a pretty seamless option for developers to consider.

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

#305

Post by afiori »

sidewndr46 wrote: post #266
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…

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

A WebSocket starts as a normal http request, so it is subject to cors if the initial request was (eg if it was a post)

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

#306

Post by rafram »

jonchurch_ wrote: post #284
rafram wrote: post #278

Earlier quoted context omitted.

That’s just not that big of a restriction. Anecdotally, very few JSON APIs I’ve worked with have bothered to check the request Content-Type. (“Minimal” web frameworks without built-in security middleware have been very harmful in this respect.) People don’t know about this attack vector and don’t design their backends to prevent it.

I agree that it is not a robust safety net. But in the instance you’re citing, thats a misconfigured server. What framework allows you to setup a misconfigured parser out of the box? I dont mean that as a challenge, but as a server framework maintainer Im genuinely curious. In express we would definitely allow people to opt into this, but you have to explicitly make the choice to go and configure body-parser.json to…

SvelteKit for sure, and any other JS framework that uses the built-in Request class (which doesn’t check the Content-Type when you call json()).

I don’t know the exact frameworks, but I consume a lot of random undocumented backend APIs (web scraper work) and 95% of the time they’re fine with JSON requests with Content-Type: text/plain.

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

#307

Post by rerdavies »

rerdavies wrote: post #130
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…

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…

[edit]: I was wrong. Just tested that a moment ago. It turns out NOT to be true. My web server during normal operation is current NOT getting OPTIONS requests at all.

Wondering whether I triggered CORS requests when I was struggling with IPv6 problems. Or maybe it triggers when I redirect index.html requests from IPv6 to IPv4 addresses. Or maybe I got caught by the earlier roll out of version one of this propposal? There was definitely a time while I was developing pipedal when none of my images displayed because my web server wasn't doing CORS. But. Whatever my excuse might be, I was wrong. :-/

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

#308

Post by thayne »

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…

It depends. GET requests are assumed not to have side effects, so often don't have a preflight request (although there are cases where it does). But of course, not all sites follow those semantics, and it wouldn't surprise me if printer or router firmware used GETs to do something dangerous.

Also, form submission famously doesn't require CORS.

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

#309

Post by mixmastamyk »

derefr wrote: post #95
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…

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.

They don’t? Every time I install an OS I turn that stuff off, because I don’t fully understand it. Or is avahi et al another thing?
Post reply on HN