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

191–200 of 392 posts

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

#191

Post by rerdavies »

aaronmdjones wrote: post #186
JdeBP wrote: post #164

Earlier quoted context omitted.

Many years ago, before it was dropped, IP version 6 had a concept of "site local" addresses, which (if it had applied to version 4) would have encompassed the corporate intranet addresses that you are talking about. Routed within the corporate intranet; but not routed over corporate borders. Think of this proposal's definition of "local" (always a tricky adjective in networking, and reportedly the proposers here have…

fd00::/8 (within fc00::/7) is still reserved for this purpose (site-local IPv6 addressing). fc00::/8 (a network block for a registry of organisation-specific assignments for site-local use) is the idea that was abandoned. Roughly speaking, the following are analogs: 169.254/16 -> fe80::/64 (within fe80::/10) 10/8, 172.16/12, 192.168/16 -> a randomly-generated network (within fd00::/8) For example, a service I maintai…

So in my case, I guess I need to blame the unconfigurable cable router my ISP provided me with? Since there's no way to provide reservations for IPv6 addresses. :-/

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

#192

Post by maple3142 »

AshamedCaptain wrote: post #53

I do not understand. Doesn't same-origin prevent all of these issues? Why on earth would you extend some protection to resources based on IP address ranges? It seems like the most dubious criteria of all.

I think the problem is that some local server are not really designed to be as secure as a public server. For example, a local server having a stupid unauthenticated endpoint like "GET /exec?cmd=rm+-rf+/*", which is obviously exploitable and same-origin does not prevent that.

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

#193

Post by elric »

jeroenhd wrote: post #89
gostsamo wrote: post #13

What is so hard in blocking apps on android from listening on random ports without permission?

The same thing that makes blocking ports on iOS and macOS so hard: there's barely any firewall on these devices by default, and the ones users may find cause more problems than users will ever think they solve. Listening on a specific port is one of the most basic things software can possibly do. What's next, blocking apps from reading files? Plus, this is also about blocking your phone's browser from accessing your…

That doesn't seem right. Can't speak to macOS, but on Android every application is sandboxed. Restricting its capabilities is trivial. Android apps certainly ARE blocked from reading files, except for some files in its storage and files the user grants it access to.

Adding two Android permissions would fix this entire class of exploits: "run local network service", and "access local network services" (maybe with a whitelist).

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

#194

Post by elric »

Pxtl wrote: post #163

Honestly I think cross-site requests were a mistake. Tracking cookies, hacks, XSS attacks, etc. My relationship is with your site. If you want to outsource that to some other domain, do that on your servers, not in my browser.

The mistake was putting CORS on the server side. It should have been part of the browser. "Facebook.com wants to access foo.example.com: y/n?"

But then we would have had to educate users, and ad peddlers would have lost revenue.

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

#195

Post by elric »

AStonesThrow wrote: post #166
Pxtl wrote: post #163

Honestly I think cross-site requests were a mistake. Tracking cookies, hacks, XSS attacks, etc. My relationship is with your site. If you want to outsource that to some other domain, do that on your servers, not in my browser.

Cross-site requests have been built in to the design of the WWW since the beginning. The whole idea of hyperlinking from one place to another, and amalgamating media from multiple sites into a single page, is the essence of the World Wide Web that Tim Berners-Lee conceived at CERN, based on the HyperCard stacks and Gopher and Wais services that had preceded it. Of course it was only later that cookies and scripting a…

CORS != hyperlinks. CORS is about random websites in your browser accessing other domains without your say-so. Websites doing stuff behind your back does feel antithetical to Tim Berners Lee's ideals...

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

#196

Post by dgoldstein0 »

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…

I don't believe this is true? As others have pointed out, preflight options requests only happen for non simple requests. Cors response headers are still required to read a cross domain response, but that is still a huge window for a malicious site to try to send side effectful requests to your local network devices that have some badly implemented web server running.

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

#197

Post by dgoldstein0 »

nbadg wrote: post #70
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…

Or simply perform a timing attack as a way of exploring the local network, though I'm not sure if the browser implementation immediately returns after the request is made (ex fetch API is called) but before the response is received. Presumably it doesn't, which would expose it to timing attacks as a way of exploring the network.

Almost every js API for making requests is asynchronous so they do return after the request is made. The exception though is synchronous XHR calls, but I'm not sure if those are still supported

... Anyhow I think it doesn't matter because you can listen for the error/failure of most async requests. Cors errors are equivalent to network errors - the browser tells the js it got stays v code 0 with no further information - but the timing of that could lead to some sort of interference? Hard to say what that would be though. Maybe if you knew the target webserver was slow but would respond to certain requests, a slower failed local request could mean it actually reached a target device.

That said, why not just fire off simple http requests with your intended payload? Abusing the csrf vulnerabilities of local network devices seems far easier than trying to make something out of a timing attack here.

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

#198

Post by lyu07282 »

varenc wrote: post #171
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…

This tag: triggers a local network GET request without any CORS involvement.

Exactly you can also trigger forms for POST or DELETE etc. this is called CSRF if the endpoint doesn't validate some token in the request. CORS only protects against unauthorized xhr requests. All decades old OWASP basics really.

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

#199

Post by lucideer »

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.

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.

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

#200

Post by friendzis »

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…

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

False. CORS only gates non-simple requests (via options), simple requests are sent regardless of CORS config, there is no gating whatsoever.

Post reply on HN