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

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 evil task, including making an outbound connection to the attacker's server. Of course, the webpage would not be able to discover whether it was successful, but that may not be important.

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

CORS doesn’t protect you from anything. Quite the opposite: it _allows_ cross origin communication (provided you follow the spec). The same origin policy is what protects you.

I made a CTF challenge 3 years ago that proves why local devices are not so protected. exploitv99 bypasses PNA with timing as the other commentor points out.

https://github.com/adc/ctf-midnightsun2022quals-writeups/tre...

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

How would Facebook do that? They scan all likely local ranges for what could be your phone, and have a web server running on the phone? That seems more like a problem of allowing the phone app to start something like that and keep it running in the background.

Do you have a link talking about those Facebook's recent tricks? I think I missed that story, and would love to read an analysis about it

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

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.

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.

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

> Is there even a use case for this for which there isn’t already a better solution?

I deal with a third-party hosted webapp that enables extra when a webserver hosted on localhost is present. The local webserver exposes an API allowing the application to interact more closely with the host OS (think locally-attached devices and servers on the local network). If the locally-installed webserver isn't present the hosted app hides the extra functionality.

Limiting browser access to the localhost subnet (127.0.0.1/8) would be fine to me, as a sysadmin, so long as I have the option to enable it for applications where it's desired.

>That presents an entirely new threat model for which we don’t have a solution.

What attack do you think doesn't have a solution? CSRF attacks? The solution is CSRF tokens, or checking the Origin header, same as how non-local-network sites protect against CSRF. DNS rebinding attacks? The solution is checking the Host header.

>for which we don’t have a solution

It's called ZTA, Zero Trust Architecture. Devices shouldn't assume the LAN is secure.

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.

People accept permission prompts from apps because they conciously downloaded the app and generally have an idea about the developer and what the app does. If a social media app asks for permission to your photos it's easy to understand why, same with a music streamer wanting to connect to your smart speaker.

A random website someone linked me to wanting to access my local network is a very different case. I'm absolutely not giving network or location or camera or any other sort of access to websites except in very extreme circumstances.

And annoyingly, for some reason it does not remember this decision properly. Chrome asks me about local access every few weeks, it seems.

Yes, as a Chromecast user, please do give me a break from the prompts, macOS – or maybe just show them for Airplay with equal frequency and see how your users like that.

problem is: without allowing it webUIs like synology won't work, since they require your browser to connect to the local network... as it is, it's not great

I can't believe that anyone still thinks a popup permission modal offers any type of security. Windows UAC has shown quite definitively that users will always click through any modal in their way without thought or comprehension.

Besides that, approximately zero laypersons will have even the slightest clue what this permission means, the risks involved, or why they might want to prevent it. All they know is that the website they want is not working, and the website tells them to enable this or that permission. They will all blindly enable it every single time.

>edit: localhost won't be restricted:

It will be restricted. This proposal isn't completely blocking all localhost and local IPs. Rather, it's preventing public sites from communicating with localhost and local IPs. E.g:

* If evil.com makes a request to a local address it'll get blocked.

* If evil.com makes a request to a localhost address it'll get blocked.

* If a local address makes a request to a localhost address it'll get blocked.

* If a local address makes a request to a local address, it'll be allowed.

* If a local address makes a request to evil.com it'll be allowed.

* If localhost makes a request to a localhost address it'll be allowed.

* If localhost makes a request to a local address, it'll be allowed.

* If localhost makes a request to evil.com it'll be allowed.

I agree fully with him. I don’t care what part of your job gets harder, or what software breaks if you can’t make it work without unnecessarily invading my privacy. You could tell me it’s going to shut down the internet for 6 months and I still wouldn’t care.

You’ll have to come up with a really strong defense for why this shouldn’t happen in order to convince most users.

I'm sure it will require some work, but this is the price of security. The idea that any website I visit can start pinging/exploiting some random unsecured testing web server I have running on localhost:8080 is a massive security risk.

I do understand this sentiment, but isn't the tension here that security improvements by their very nature are designed to break things? Specifically the things we might consider "bad", but really that definition gets a bit squishy at the edges.

This attitude kept IE6 in production well after its natural life should have concluded.

I’m sorry but this proposal is absolutely monumentally important.

The fact that I have to rely on random extensions to accomplish this is unacceptable.

Yeah. I'd like it too. I can't use my bank's app, because it wants some weird permissions like an access to contacts, I refuse to give them, because I see no use in it for me, and it refuses to work.

Also for the camera, just feed them random noise or a user-selectable image/video

In iOS you can share a subset of your contacts. This is functionally equivalent and works as you described for WhatsApp.

GrapheneOS has this feature (save for faking GPS) fwiw

Apps are not allowed to force you to share your contacts on iOS, report any apps that are asking you to do so as it’s a violation of the App Store TOS.

Does that UI actually let you choose? IME it just tells me what orgs & repos will be shared, with no option to choose.

All of them.

No, simple requests [1] - such as a GET request, or a POST request with text/plain Content-Type - don't trigger a CORS preflight. The request is made, and the browser may block the requesting JS code from seeing the response if the necessary CORS response header is missing. But by that point the request had already been made. So if your local service has a GET endpoint like http://localhost:8080/launch_rockets, or a POST endpoint, that doesn't strictly validate the body Content-Type, then any website can trigger it.

[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/COR...

Oh yeah forgot about that, amazing.

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

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.

On a phone at least, it should be "do you want to allow website A to connect to app B."

(It's harder to do for the rest of the local network, though.)

> I wish there were an API to build such a firewall, e.g. as a part of a browser extension,

There was in Manifest V2, and it still exists in Firefox.

https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...

That's the API Chrome removed with Manifest V3. You can still log all web requests, but you can't block them dynamically anymore.

I think something like Tailscale is the way to go here.

It's very useful to have this additional information in something like a network address. I agree, you shouldn't rely on it, but IPv6 hasn't clicked with me yet, and the whole "globally routable" concept is one of the reasons. I hear that, and think, no, I don't agree.

@donnachangstein:

The device is an IoT guitar pedal that runs on a Raspberry Pi. In performance, on stage, a Web UI runs on a phone or tablet over a hotspot connection on the PI, which is NOT internet connected (since there's no expectation that there's a Wi-Fi router or internet access at a public venue). OR the pi runs on a home wifi network, using a browser-hosted UI on a laptop or desktop. OR, I suppose over an away-from-home Wi-Fi connection at a studio or rehearsal space, I suppose.

It is not reasonable to expect my users to purchase domain names and certs for their $60 guitar pedal, which are not going to work anyway, if they are playing away from their home network. Nor is ACME provisioning an option because the device may be in use but unconnected to the internet for months at a time if users are using the Pi Hotspot at home.

I can't use password authentication to get access to the Pi Web server, because I can't use HTTPS to conceal the password, and browsers disable access to javascript crypto APIs on non non-HTTPS pages (not that I'd really trust myself to write javascript code to obtain auth tokens from the pi server anyway), so doing auth over an HTTP connection doesn't really strike me as a serious option either..

Nor is it reasonable to expect my non-technical users to spend hours configuring their networks. It's an IoT device that should be just drop and play (maybe with a one-time device setup that takes place on the Pi).

There is absolutely NO way I am going to expose the server to the open internet without HTTPS and password authentication. The server provides a complex API to the client over which effects are configured and controlled. Way too much surface area to allow anyone of the internet to poke around in. So it uses IP/4 isolation, which is the best I can figure out given the circumstances. It's not like I havem't given the problem serious consideration. I just don't see a solution.

The use case is not hugely different from an IoT toothbrush. But standards organizations have chosen to leave both my (hypothetical) toothbrush and my application utterly defenseless when it comes to security. Is it any surprise that IoT toothbrushes have security problems?

How would YOU see https working on a device like that?

> ".local" is reserved for mDNS and is in the RFC, though this is frequently and widely ignored.

Yes. That was my point. It is currently widely ignored.

> can't even agree on the meaning of "local"

Well, who can agree on this? Local network, private network, intranet, Tailscale and VPN, Tor? IPv6 ULA, NAT/CGNAT, SOCKS, transparent proxy? What resources are "local" to me and what resources are "remote"?

This is quite a thorny and sometimes philosophical question. Web developers are working at the OSI Layer 6-7 / TCP/IP Application Layer.

https://en.wikipedia.org/wiki/OSI_model#Comparison_with_TCP/...

Now even cookies and things like CSRF were trying to differentiate "servers" and "origins" and "resources" along the lines of the DNS hierarchy. But this has been fraught with complication, because DNS was not intended to delineate such things, and can't do so cleanly 100% of the time.

Now these proposals are trying to reach even lower in the OSI model - Layer 3, Layer 2. If you're asking "what is on my LAN" or "what is a private network", that is not something that HTTPS or web services are supposed to know. Are you going to ask them to delve into your routing table or test the network interfaces? HTTPS was never supposed to know about your netmask or your next-hop router.

So this is only one reason that there is no elegant solution for the problem. And it has been foundational to the way the web was designed: "given a uniform locator, find this resource wherever it may be, whenever I request it." That was a simpler proposition when the Web was used to publish interesting and encyclopedic information, rather than deliver applications and access sensitive systems.

A common use case, whether for 3D printers, switches, routers, or NAS devices is that you've got a centrally hosted management UI that then sends requests directly to your local devices.

This allows you to use a single centrally hosted website as user interface, without the control traffic leaving your network. e.g. Plex uses this.

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.

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 tasks (LLM, TTS, ASR, etc.) running together where they need to communicate to be able to create services like local assistants. I don't want to have to jump through hoops of running these through SSL (including getting a verified self-signed cert.), etc. just to be able to run a local web service.

> Googlers present a solution no one is asking for,

I'm asking for it. Random web sites have no business poking around my internal network.