9 ms·
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
by mystifyingpoi 1y ago
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".
- donnachangstein 1y ago[flagged]
- zaptheimpaler 1y agoI'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.
- donnachangstein 1y ago[flagged]
- hollerith 1y agoThe whole browser is a massive security leak. What genius thought it was a good idea for the web page I visit in the morning to get the weather forecast to be able to run arbitrary code and to communicate with arbitrary hosts on my local network?
- duskwuff 1y agoOr probing your local network for vulnerable HTTP servers, like insecure routers or web cameras. localhost is just the tip of the iceberg.
- donnachangstein 1y agoCan you define "local network"? Probably not. Most large enterprises own publicly-routable IP space for internal use. Internal doesn't mean 192.168.0.0/24. foo.corp.example.com could resolve to 9.10.11.12 and still be local. What about IPv6? It's a nonsense argument fraught with corner cases.
- eschaton 1y agoIt should not even be able to communicate with the local network at all, it’s a goddamn web page. It should be restricted to just communicate with the server that hosts it and that’s it.
- mystifyingpoi 1y agoNot to be snarky, but that's a good example of "perfect being the enemy of good". You are totally right that there are corner cases, sure. But that doesn't stop us from tackling the low hanging fruit first. Which is, as you say, localhost and LAN (if present).
- duskwuff 1y ago> Can you define "local network"? Sure - a destination is "local" if your machine has a route to that IP which isn't via a gateway. If your network is large enough that it consists of multiple routed network segments, and you don't have any ACLs between those segments, then yeah, you won't be fully protected by this browser feature. But you aren't protected right now either, so nothing's getting worse, it's just not getting better for your specific use case.
- donnachangstein 1y ago> Sure - a destination is "local" if your machine has a route to that IP which isn't via a gateway. Fantastic. Well, Google doesn't agree The proposal defines it along RFC1918 address space boundaries. The spitballing back and forth in the GitHub issues about which imaginary TLDs they will or won't also consider "local" is absolutely horrifying.
- aaomidi 1y agoI’m sorry but this proposal is absolutely monumentally important. The fact that I have to rely on random extensions to accomplish this is unacceptable.
- kulahan 1y agoI 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.
- donnachangstein 1y ago[flagged]
- GlacierFox 1y agoI like your "you've been *** my ass for 35 years, please feel free to keep doing it for all eternity" attitude.
- Aeolun 1y agoIt just means I run a persistent client on your device that is permanently connected to the mothership, instead of only when you have your browser open.
- kulahan 1y agoI’m so glad most people don’t truly consider software devs to be real engineers, because this is a perfect example of why that word deserves so much more respect than this field gives it.
- Wobbles42 1y agoI 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.
- protocolture 1y agoThis attitude kept IE6 in production well after its natural life should have concluded.
- lucideer 1y ago> 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.
- grokkedit 1y agoproblem 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
- planb 1y agoWhy? I’d guess requests from a local network site to itself (maybe even to others on the same network) will be allowed.
- jay_kyburz 1y agoThis proposal is for websites outside your network contacting inside your network. I assume local IPs will still work.
- Marsymars 1y agoNote that the proposal also covers loopbacks, so domain names for local access would also still work.
- buildfocus 1y agoThis 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 both actively want to communicate, the user's permission is also explicitly requested. Historically we assumed server & website agreement was sufficient, but Facebook's recent tricks where websites secretly talked to apps on your phone have broken that assumption - websites might be in cahoots with local network servers to work against your interests.
- xp84 1y agoDoesn'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.
- tombakt 1y agoNo, 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 about actually crafting and delivering a malicious payload.
- rafram 1y agoYou’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.
- jm4 1y agoThis 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?
- loaph 1y agoI've used https://pairdrop.net/ 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.
- A4ET8a8uTh0_v2 1y agoSame use case, but I remember getting approval prompts ( though come to think of it, those were not mandated, but application specific prompts to ensure you consciously choose to share/receive items ). To your point, there are valid use cases for it, but some tightening would likely be beneficial.
- charcircuit 1y ago>for which we don’t have a solution It's called ZTA, Zero Trust Architecture. Devices shouldn't assume the LAN is secure.
- Thorrez 1y ago>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.
- broguinn 1y agoThis Web Security lecture by Feross Aboukhadijeh has a great example of Zoom's zero-day from 2019 that allowed anyone to force you to join a zoom meeting (and even cause arbitrary code execution), using a local server: https://www.youtube.com/watch?v=wLgcb4jZwGM&list=PL1y1iaEtjSYiiSGVlL1cHsXN_kvJOOhu-&index=17 https://www.youtube.com/watch?v=wLgcb4jZwGM&list=PL1y1iaEtjS... It's not clear to me from Google's proposal if it also restricts access to localhost, or just your local network - it'd be great if it were both, as we clearly can't rely on third parties to lock down their local servers sufficiently! edit: localhost won't be restricted: "Note that local -> local is not a local network request, as well as loopback -> anything. (See "cross-origin requests" below for a discussion on potentially expanding this definition in the future.)"
- Thorrez 1y ago>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.
- broguinn 1y agoAhh, thanks for clarifying! It's the origin being compared, not the context - of course.
- deleted 1y ago[deleted]