Live data from Hacker News

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

github.com

151–160 of 392 posts

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

#151
post #92

Personally I had completely forgotten that anyone and anything can do this right now. TLDR, IIUC, right now, random websites can try accessing contents on local IPs. You can try to blind load e.g. http://192.168.0.1/cgi-bin/login.cgi from JavaScript, iterating through a gigantic malicious list of such known useful URLs, then grep and send back whatever you want to share with advertisers or try POSTing backdoors to pr…

> so that range can be default exempted

I disagree. I know it’s done, but I don’t think that makes it safe or smart.

Require the user to OK it and require the server to send a header with the one _exact_ port it will access. Require that the local server _must_ use CORS and allow that server.

No website not loaded from localhost should ever be allowed to just hit random local/private IPs and ports without explicit permission.

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

#152

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…

I think this can be circumvented by DNS rebinding, though your requests won't have the authentication cookies for the target, so you would still need some kind of exploit (or a completely unprotected target).

How? The browser would still have to resolve it to a final IP right?

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

#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 App should only be able to see Bose devices, nothing else. The CVS (pharmacy app) should only be able to connect to CVS devices, whatever those are. All I know is the app asked for permission. I denied it.

I might even prefer if it had to register the device ids and then the user would be prompted, the same way camera access/gps access is prompted. Via the OS, it might see a device that the CVS.app registered for in its manifest. The OS would popup "CVS app would like to connect to device ABC? Just this once, only when the app is running, always" (similar to the way iOS handles location)

By id, I mean some prefix that a company registers for its devices. bose.xxx, app's manifest says it wants to connect to "bose.*" and OS filters.

Similarly for USB and maybe local network devices. Come up with an id scheme, have the OS prevent apps form connecting to anything not that id. Effectively, don't let apps browser the network, usb, bluetooth.

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

#154

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…

Like the github 3rd party application integration. "ABC would like to see your repositories, which ones do you want to share?"

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

#155
post #66

Earlier quoted context omitted.

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

Windows Vista would spawn a permissions prompt when users did something as innocuous as creating a shortcut on their desktop.

Microsoft deserved to be mocked for that implementation.

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

#156
post #69
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…

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.

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

#157

Earlier quoted context omitted.

> 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

Windows Vista would spawn a permissions prompt when users did something as innocuous as creating a shortcut on their desktop. Microsoft deserved to be mocked for that implementation.

I once encountered malware on my roommate’s Windows 98 system. It was a worm designed to rewrite every image file as a VBS script that would replicate and re-infect every possible file whenever it was clicked or executed. It hid the VBS extensions and masqueraded as the original images.

Creation of a shortcut on Windows is not necessarily innocuous. It was a common first vector to drop malware as users were accustomed to installing software that did the same thing. A Windows shortcut can hide an arbitrary pathname, arbitrary command-line arguments, a custom icon, and more; these can be modified at any time.

So whether it was a mistake for UAC to be overzealous or obstructionist, or Microsoft was already being mocked for poor security, perhaps they weren’t wrong to raise awareness about such maneuvers.

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

#158

Why can browsers do the kinds of things they do at all? Why does a web browser need USB or Bluetooth support? They don’t.0 Browsers should not be the universal platform. They’ve become the universal attack vector.

With WebUSB, you can program a microcontroller without needing to install local software. With Web Bluetooth, you can wirelessly capture data from + send commands to that microcontroller. As a developer, these standards prevent you from needing to maintain separate implementations for Windows/macOS/Linux/Android. As a user, they let you grant and revoke sandbox permissions in a granular way, including fully removing…

I’m ok with needing non-browser software for those things.

> Browsers provide a great cross-platform sandbox and make it much easier to develop secure software across all platforms.

Sure, until advertising companies find ways around and through those sandboxes because browser authors want the browsers be capable of more, in the name of a cross platform solution. The more a browser can do, the more surface area the sandbox has. (An advertising company makes the most popular browser, by the way.)

> What other platform (outside of web browsers) is a good alternative for securely developing cross-platform software that interacts with hardware?

There isn’t one, other than maybe video game engines, but it doesn’t matter. OS vendors need to work to make cross-platform software possible; it’s their fault we need a cross-platform solution at all. Every OS is a construct, and they were constructed to be different for arbitrary reasons.

A good app-permission model in the browser is much more likely to happen, but I don’t see that really happening, either. “Too inconvenient for users [and our own in-house advertisers/malware authors]” will be the reason.

MacOS handles permissions pretty well, but it could do better. If something wants local network permission, the user gets prompted. If the user says no, those network requests fail. Same with filesystem access. Linux will never have anything like this, nor will Windows, but it’s what security looks like, probably.

Users will say yes to those prompts ultimately, because as soon as users have the ability to say “no” on all platforms, sites will simply gate site functionality behind the granting of those permissions because the authors of those sites want that data so badly.

The only thing that is really going to stop behavior like this is law, and that is NEVER going to happen in the US.

So, short of laws, browsers themselves must stop doing stupid crap like allowing local network access from sites that aren’t on the local network, and nonsense stuff like WebUSB. We need to give up on the idea that anyone can be safe on a platform when we want that platform to be able to do anything. Browsers must have boundaries.

Operating systems should be the police, probably, and not browsers. Web stuff is already slow as hell, and browsers should be less capable, not more capable for both security reasons and speed reasons.

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

#159

Earlier quoted context omitted.

Windows Vista would spawn a permissions prompt when users did something as innocuous as creating a shortcut on their desktop. Microsoft deserved to be mocked for that implementation.

I once encountered malware on my roommate’s Windows 98 system. It was a worm designed to rewrite every image file as a VBS script that would replicate and re-infect every possible file whenever it was clicked or executed. It hid the VBS extensions and masqueraded as the original images. Creation of a shortcut on Windows is not necessarily innocuous. It was a common first vector to drop malware as users were accustome…

A user creating a shortcut manually is not something that requires a permissions prompt.

If you want to teach users to ignore security prompts, then completely pointless nagging is how you do it.

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

#160
post #148

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?

I've used https://pairdrop.net/ before to share files between devices on the same LAN. It obviously wouldn't have to be a website, but it's pretty convenient since all my devices I wanted to share files on already have a browser.
Post reply on HN