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

71–80 of 392 posts

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

#71

Post by paxys »

skybrian wrote: post #36

While this will help to block many websites that have no business making local connections at all, it's still very coarse-grained. Most websites that need this permission only need to access one local server. Granting them access to everything violates the principle of least privilege. Most users don't know what's running on localhost or on their local network, so they won't understand the risk.

> 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 just click "yes" in confusion.

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

#72

Post by xp84 »

fn-mote wrote: post #54
ronsor wrote: post #49

Earlier quoted context omitted.

That works if you want to launch an application from a website, but it doesn't work if you want to actively communicate with an application from a website.

This needs more detail to make it clear what you are wishing for that will not happen. It seems like you're thinking of a specific application, or at least use-case. Can you elaborate? Once you're launching an application, it seems like the application can negotiate with the external site directly if it wants.

#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 manager, which has to have your key stored in the browser and fetch your vault from the server, but a lot of us like having that information never have to leave our computers.

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

#73

Post by ImPostingOnHN »

ronsor wrote: post #3

Do note that since the removal of NPAPI plugins years ago, locally-installed software that intends to be used by one or more public websites has to run an HTTP server on localhost. It would be really annoying if this use case was made into an unreasonable hassle or killed entirely. (Alternatively, browser developers could've offered a real alternative, but it's a bit late for that now.)

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

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

#74

Post by kccqzy »

parliament32 wrote: post #57
kccqzy wrote: post #37

Earlier quoted context omitted.

The split horizon DNS model mentioned in that article is to me insane. Your DNS responses should not change based on what network you are connected to. It breaks so many things. For one, caching breaks because DNS caching is simplistic and is only cached with a TTL: no way to tell your OS to associate a DNS cached response to a network. I understand why some companies want this, but doing it on the DNS level is a mas…

> Your DNS responses should not change based on what network you are connected to. GeoDNS and similar are very broadly used by services you definitely use every day. Your DNS responses change all the time depending on what network you're connecting from. Further: why would I want my private hosts to be resolvable outside my networks? Of course DNS responses should change depending on what network you're on.

> but if you're inside our network perimeter and you look up their name, you get a private IP address and you have to use this IP address to talk to them

In the linked article using the wrong DNS results in inaccessibility. GeoDNS is merely a performance concern. Big difference.

> why would I want my private hosts

Inaccessibility is different. We are talking about accessible hosts requiring different IP addresses to be accessed in different networks.

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

#75

Post by [deleted] »

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…

[deleted]

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

#76

Post by LegionMammal978 »

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…

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

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

#77

Post by xp84 »

paxys wrote: post #71
skybrian wrote: post #36

While this will help to block many websites that have no business making local connections at all, it's still very coarse-grained. Most websites that need this permission only need to access one local server. Granting them access to everything violates the principle of least privilege. Most users don't know what's running on localhost or on their local network, so they won't understand the risk.

> 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 people would say:

• "Not sure what that means..."

• "I DO want to access my account, though."

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

#78

Post by IshKebab »

thesdev wrote: post #68

Off-topic: Is the placement of the apostrophe right in the title? Should it be "a users' local network" (current version) or "a user's local network"?

It should be "from accessing a user's local network", or "from accessing users' local networks".

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

#79

Post by kmeisthax »

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 MYTH OF "CONSENSUAL" REQUESTS

Client: I consent

Server: I consent

User: I DON'T!

ISN'T THERE SOMEBODY YOU FORGOT TO ASK?

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

#80

Post by kbolino »

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

Here's a formal definition of such simple requests, which may be more expansive than one might expect: https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/COR...
Post reply on HN