[HN Gopher] A proposal to restrict sites from accessing a users'...
___________________________________________________________________
A proposal to restrict sites from accessing a users' local network
Author : doener
Score : 192 points
Date : 2025-06-04 18:15 UTC (4 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| sroussey wrote:
| I guess this would help Meta's sneaking identification code
| sharing between native apps and websites with their sdk on them
| from communicating serendipitously through localhost,
| particularly on Android.
|
| [0]
| https://www.theregister.com/2025/06/03/meta_pauses_android_t...
| ronsor wrote:
| 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.)
| RagingCactus wrote:
| I don't believe this is true, as
| https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...
| exists. It does need an extension to be installed, but I think
| that's fair in your comparison with NPAPI.
| michaelt wrote:
| Doesn't most software just register a protocol handler with the
| OS? Then a website can hand the browser a _zoommtg: //_ link,
| which the browser opens with _zoom_ ?
|
| Things like Jupyter Notebooks will presumably be unaffected by
| this, as they're not doing any cross-origin requests.
|
| And likewise, when a command line tool wants you to log in with
| oauth2 and returns you to a localhost URL, it's a simple
| redirect not a cross-origin request, so should likewise be
| allowed?
| ronsor wrote:
| 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.
| fn-mote wrote:
| 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.
| xp84 wrote:
| #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.
| spiffyk wrote:
| Browser _extensions_ play by very different rules than
| _websites_ already. The proposal is for the latter and I
| doubt it is going to affect the former, other than MAYBE
| an extra permanent permission.
| cAtte_ wrote:
| you missed the point. password managers are one of the
| many use cases for this feature; that they just so happen
| to be mostly implemented as extensions does not mean that
| the feature is only useful for extensions
| minitech wrote:
| Extensions can already use a better mechanism for this
| (https://developer.mozilla.org/en-US/docs/Mozilla/Add-
| ons/Web...) than starting a local web server.
| kuschku wrote:
| 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.
| michaelt wrote:
| I don't think this proposal will stop you visiting the
| management UI for devices like switches and NASes on the
| local network. You'll be able to visit http://192.168.0.1
| and it'll work just fine?
|
| This is just about blocking cross-origin requests from
| other websites. I probably don't want every ad network
| iframe being able to talk to my router's admin UI.
| kuschku wrote:
| That's not what I'm talking about.
|
| A common example is this:
|
| 1. I visit ui.manufacturer.tld
|
| 2. I click "add device" and enter 192.168.0.230,
| repeating this for my other local devices.
|
| 3. The website ui.manufacturer.tld now shows me a
| dashboard with aggregate metrics from all my switches and
| routers, which it collects by fetch(...) ing data from
| all of them.
|
| The manufacturers site is just a static page. It stores
| the list of devices and credentials to connect to them in
| localStorage.
|
| None of the data ever leaves my network, but I can just
| bookmark ui.manufacturer.tld and control all of my
| devices at once.
|
| This is a relatively neat approach providing the same
| comfort as cloud control, without the privacy nightmare.
| hypercube33 wrote:
| Windows Admin center but it's only local which I rather
| hate
| ImPostingOnHN wrote:
| _> 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)
| IshKebab wrote:
| It would be amazing if that _method_ of communicating with a
| local app was killed entirely, because it 's been a very very
| common source of security vulnerabilities.
| zelon88 wrote:
| I understand the idea behind it and am still kinda chewing on the
| scope of it all. It will probably break some enterprise
| applications and cause some help desk or group policy/profile
| headaches for some.
|
| It would be nice to know when a site is probing the local
| network. But by the same token, here is Google once again putting
| barriers on self sufficiency and using them to promote their PaaS
| goals.
|
| They'll gladly narc on your self hosted application doing what
| it's supposed to do, but what about the 23 separate calls to
| Google CDN, ads, fonts, ect that every website has your browser
| make?
|
| I tend to believe the this particular functionality is no longer
| of any use to Google, which is why they want to deprecate it to
| raise the barrier of entry for others.
| iforgotpassword wrote:
| Idk, I like the idea of my browser warning me when a random
| website I visit tries to talk to my network. if there's a
| legitimate reason I can still click yes. This is orthogonal to
| any ads and data collection.
| Henchman21 wrote:
| I have this today from macOS. To me it feels more appropriate
| to have the OS attempt to secure running applications.
| happyopossum wrote:
| No you don't - you get a single permission prompt for the
| entire browser. You definitely don't get any permission-
| site permission options from the OS
| Henchman21 wrote:
| Ah I misunderstood, thank you
| Henchman21 wrote:
| I agree that any newly proposed standards for the web coming
| from Google should be met with a skeptical eye -- they aren't
| good stewards IMO and are usually self-serving.
|
| I'd be interested in hearing what the folks at Ladybird think
| of this proposal.
| foota wrote:
| The alternative proposal sounds much nicer, but unfortunately was
| paused due to concerns about devices not being able to support
| it.
|
| I guess once this is added maybe the proposed device opt in
| mechanism could be used for applications to cooperatively support
| access without a permission prompt?
| mystifyingpoi wrote:
| 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 wrote:
| This is a perfect example of Chesterton's Fence in action.
|
| > I wouldn't care if it breaks some enterprise apps or
| integrations
|
| Please stay away from any web browser code.
| zaptheimpaler wrote:
| 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.
| duskwuff wrote:
| Or probing your local network for vulnerable HTTP servers,
| like insecure routers or web cameras. localhost is just the
| tip of the iceberg.
| donnachangstein wrote:
| Can 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.
| mystifyingpoi wrote:
| Not 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 wrote:
| > 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 wrote:
| > 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 wrote:
| 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.
| kulahan wrote:
| 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.
| Aeolun wrote:
| It 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.
| Wobbles42 wrote:
| 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.
| lucideer wrote:
| > _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 wrote:
| 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
| planb wrote:
| Why? I'd guess requests from a local network site to itself
| (maybe even to others on the same network) will be allowed.
| zbuttram wrote:
| With the proposal in the OP, I would think so yes. But
| the MacOS setting mentioned directly above is blanket
| per-app at the OS level.
| jay_kyburz wrote:
| This proposal is for websites outside your network
| contacting inside your network. I assume local IPs will
| still work.
| Marsymars wrote:
| Note that the proposal also covers loopbacks, so domain
| names for local access would also still work.
| mystified5016 wrote:
| 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.
| xp84 wrote:
| 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 tech works cannot completely
| protect themselves from any possible attacker, while also
| having sophisticated networked features. Nobody has
| provided a decent alternative other than some kind of fully
| bubble-wrapped limited account using Group Policies, to ban
| all those perms from even being asked for.
| ameliaquining wrote:
| I don't think anyone's under the impression that this is a
| perfect solution. But it's better than nothing, and the
| options are this, nothing, or a security barrier that can't
| be bypassed with a permission prompt. And it was determined
| that the latter would break too many existing sites that
| have legitimate (i.e., doing something the end user
| actively wants) reason to talk to local devices.
| paxys wrote:
| 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.
| poincaredisk wrote:
| "Please accept the [tech word salad] popup to verify your
| identity"
|
| Maybe this won't fool you, but it would trick 90% of
| internet users. (And even if it was 20% instead of 90%,
| that's still way too much.)
| mastazi wrote:
| 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.
| Aeolun wrote:
| As a counter example, I think all these dialogs are
| annoying as hell and click yes to almost everything. If I'm
| installing the app I have pre-vetted it to ensure it's
| marginally trustworthy.
| buildfocus wrote:
| 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 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 wrote:
| 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.
| tombakt wrote:
| 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 about
| actually crafting and delivering a malicious payload.
| LegionMammal978 wrote:
| 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).
| kbolino wrote:
| 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...
| MajesticHobo2 wrote:
| There doesn't need to be any kind of "polyglot payload".
| Local network services and devices that accept _only_
| simple HTTP requests are extremely common. The request
| will go through and alter state, etc.; you just won 't be
| able to read the response from the browser.
| mirashii wrote:
| You don't even need to be exploiting the target device,
| you might just be leaking data over that connection.
|
| https://news.ycombinator.com/item?id=44169115
| freeone3000 wrote:
| Oh, you can only send _arbitrary text_ or _form
| submissions_. That's SO MUCH.
| drexlspivey wrote:
| It can send a json-rpc request to your bitcoin node and
| empty your wallet
| layer8 wrote:
| There is a limited, but potentially effective, attack
| surface via URL parameters.
| nbadg wrote:
| 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.
| hsbauauvhabzb wrote:
| CORS prevents the site from accessing the response body. In
| some scenarios, a website could, for example, blindly attempt
| to authenticate to your router and modify settings by
| guessing your router bran/model and password
| IshKebab wrote:
| 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).
| ameliaquining wrote:
| Is this kind of attack actually in scope for this proposal?
| The explainer doesn't mention it.
| Aeolun wrote:
| 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.
| AStonesThrow wrote:
| Chris Siebenmann weighs in with thoughts on:
|
| Browers[sic] can't feasibly stop web pages from talking to
| private (local) IP addresses (2019)
|
| https://utcc.utoronto.ca/~cks/space/blog/web/BrowsersAndLoca...
| kccqzy wrote:
| 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 massive hack.
|
| If I were the decision maker I would break that use case.
| (Chrome probably wouldn't though.)
| parliament32 wrote:
| > 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.
| kccqzy wrote:
| > 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.
| kuschku wrote:
| I'm surprised you've never seen this before.
|
| Especially for universities it's very common to have the same
| hostname resolve to different servers, and provide different
| results, depending on whether you're inside the university
| network or not.
|
| Some sites may require login if you're accessing them from
| the internet, but are freely accessible from the intranet.
|
| Others may provide read-write access from inside, but limited
| read-only access from the outside.
|
| Similar situations with split-horizon DNS are also common in
| corporate intranets or for people hosting Plex servers.
|
| Ultimately all these issues are caused by NAT and would
| disappear if we switched to IPv6, but that would also
| circumvent the OP proposal.
| gostsamo wrote:
| What is so hard in blocking apps on android from listening on
| random ports without permission?
| zb3 wrote:
| It's not only about android, it's about exploiting local
| services too..
| jeroenhd wrote:
| 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 printer, your router, or that docker container
| you're running without a password.
| pacifika wrote:
| Internet Explorer solved this with their zoning system right?
|
| https://learn.microsoft.com/en-us/previous-versions/troubles...
| donnachangstein wrote:
| Ironically, Chrome partially supported and utilized IE security
| zones on Windows, though it was not well documented.
| pacifika wrote:
| Oh yeah forgot about that, amazing.
| nailer wrote:
| Honestly I just assumed a modern equivalent existed. That it
| doesn't is ridiculous. Local network should be a special
| permission like the camera or microphone.
| hulitu wrote:
| > A proposal to restrict sites from accessing a users' local
| network
|
| A proposal to treat webbrowsers as malware ? Why would a
| webbrowser connect to a socket/internet ?
| loumf wrote:
| The proposal is directed at the websites in the browser (using
| JS, embedded images or whatever), not the code that implements
| the browser.
| AdmiralAsshat wrote:
| uBlock / uMatrix does this by default, I believe.
|
| I often see sites like Paypal trying to probe 127.0.0.1. For my
| "security", I'm sure...
| potholereseller wrote:
| It appears to not have been enabled by default on my instance
| of uBlock; it seems a specific filter list is used to implement
| this [0]; that filter was un-checked; I have no idea why. The
| contents of that filter list are here [1]; notice that there
| are exceptions for certain services, so be sure to read through
| the exceptions before enabling it.
|
| [0] Filter Lists -> Privacy -> Block Outsider Intrusion into
| Lan
|
| [1] <https://github.com/uBlockOrigin/uAssets/blob/master/filter
| s/...>
| profmonocle wrote:
| Assuming that RFC1918 addresses mean "local" network is wrong. It
| means "private". Many large enterprises use RFC1918 for private,
| internal web sites.
|
| One internal site I spend hours a day using has a 10.x.x.x IP
| address. The servers for that site are on the other side of the
| country and are many network hops away. It's a big company, our
| corporate network is very very large.
|
| A better definition of "local IP" would be whether the IP is in
| the same _subnet_ as the client, i.e. look up the client 's own
| IP and subnet mask and determine if a packet to a given IP would
| need to be routed through the default gateway.
| kccqzy wrote:
| The article spends a lot of effort defining the words "local"
| and "private" here. It then says:
|
| > Note that local -> local is not a local network request
|
| So your use case won't be affected.
| ale42 wrote:
| The computer I use at work (and not only mine, many many of
| them) has a public IP address. Many internal services are on
| 10.0.0.0/8. How is this being taken into account?
| kccqzy wrote:
| As far as I understand that doesn't matter. What matters is
| the frame's origin and the request.
| jaywee wrote:
| Ideally, in an organization this should be a centrally
| pushed group policy defining CIDRs.
|
| Like, at home, I have 10/8 and public IPv6 addresses.
| numpad0 wrote:
| 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 are all private
| addresses per RFC1918 and documents superseding it(5735?).
| If it's like 66.249.73.128/27 or 164.13.12.34/12, those are
| "global" IP.
|
| 1: https://www.rfc-editor.org/rfc/rfc1918
|
| 2: https://www.rfc-editor.org/rfc/rfc5735
|
| 3: https://en.wikipedia.org/wiki/Private_network
| lilyball wrote:
| Your computer's own IP address is completely irrelevant.
| What matters is the site hostname and the IP address it
| resolves to.
| xp84 wrote:
| Is it a gross generalization to say that if you're visiting a
| site whose name resolves to a private IP address, it's a part
| of the same organizational entity as your computer is?
|
| The proposal here would consider that site local and thus
| allowed to talk to local. What are the implications? Your
| employer whose VPN you're on, or whose physical facility you're
| located in, can get some access to the LAN where you are.
|
| In the case where you're a remote worker and the LAN is your
| private home, I bet that the employer already has the ability
| to scan your LAN anyway, since most employers who are allowing
| you onto their VPN do so only from computers they own, manage,
| and control completely.
| skybrian wrote:
| 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.
| nine_k wrote:
| A comprehensive implementation would be a firewall. Which
| CIDRs, which ports, etc.
|
| I wish there were an API to build such a firewall, e.g. as a
| part of a browser extension, but also a simple default UI
| allowing to give access to a particular machine (e.g. router),
| to the LAN, to a VPN, based on the routing table, or to
| "private networks" in general, in the sense Windows ascribes to
| that. Also access to localhost separately. The site could ask
| one of these categories explicitly.
| paxys wrote:
| > 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.
| xp84 wrote:
| 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."
| derefr wrote:
| 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.
| hello_computer wrote:
| just the fact that this comes from google is a hard pass for me.
| they sell so many adwords scams that they clearly do not give a
| damn about security. "security" from google is just another one
| of their trojan horses.
| fn-mote wrote:
| Don't post shallow dismissals. The same company runs Project
| Zero, which has a major positive security impact.
|
| [1]: https://googleprojectzero.blogspot.com/
| themikesanto wrote:
| Google loves wreaking havoc on web standards. Is there really
| anything anyone can do about it at this point? The number of us
| using alternative browsers are a drop in the bucket when compared
| to Chrome's market share.
| nickcw wrote:
| This has the potential to break rclone's oauth mechanism as it
| relies on setting the redirect URL to localhost so when the oauth
| is done rclone (which is running on your computer) gets called.
|
| I guess if the permissions dialog is sensibly worded then the
| user will allow it.
|
| I think this is probably a sensible proposal but I'm sure it will
| break stuff people are relying on.
| 0xCMP wrote:
| IIUC this should not break redirects. This only affects: (1)
| fetch/xmlhttprequests (2) resources linked to AND loaded on a
| page (e.g. images, js, css, etc.)
|
| As noted in another comment this doesn't work unless the server
| responding provides proper CORS headers allowing the content to
| be loaded by the browser in that context: so for any request to
| work the server is either wide open (cors: *) or are
| cooperating with the requesting code (cors: website.co). The
| changes prevent communication without user authorization.
| AshamedCaptain wrote:
| 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.
| fn-mote wrote:
| I think you're mistaken about this.
|
| Use case 1 in the document and the discussion made it clear to
| me.
| AshamedCaptain wrote:
| Browsers allow launching HTTP requests to localhost in the
| same way they allow my-malicious-website.com to launch HTTP
| requests to say mail.google.com . They can _request_ a
| resource but that's about it -- everything else, even many
| things you would expect to be able to do with the downloaded
| resource, are blocked by the same origin policy. [1] Heck, we
| have a million problems already where file:/// websites
| cannot access resources from http://localhost , and
| viceversa.
|
| So what's the attack vector exactly? Why it would be able to
| attack a local device but not attack your Gmail account (
| with your browser happily sending your auth cookies) or
| file:///etc/passwd ?
|
| The only attack I can imagine is that _the mere fact_ of a
| webserver existing on your local IP is a disclosure of
| information for someone, but ... what's the attack scenario
| here again? The only thing they know is you run a webserver,
| and maybe they can check if you serve something at a
| specified location.
|
| Does this even allow identifying the router model you use?
| Because I can think of a bazillion better ways to do it --
| including the simple "just assume is the default router of
| the specific ISP from that address".
|
| [1] https://developer.mozilla.org/en-
| US/docs/Web/Security/Same-o...
|
| In fact, [1] literally says
|
| > [Same-origin policy] prevents a malicious website on the
| Internet from running JS in a browser to read data from [...]
| a company intranet (which is protected from direct access by
| the attacker by not having a public IP address) and relaying
| that data to the attacker.
| zajio1am wrote:
| This seems like a silly solution, considering we are in the
| middle of IPv6 transition, where local networks use public
| addresses.
| jeroenhd wrote:
| Even IPv6 has local devices. Determining whether that's a /64
| or a /56 network may need some work, but the concept isn't all
| that different. Plus, you have ::1 and fe80::, of course.
| mbreese wrote:
| Even in this case, it could be useful to limit the access
| websites have to local servers within your subnet (/64, etc),
| which might be a better way to define the "local" network.
|
| (And then corporate/enterprise managed Chrome installs could
| have specific subnets added to the allow list)
| parliament32 wrote:
| Won't this break every local-device oauth flow?
| owebmaster wrote:
| I propose restricting android apps, not websites.
| jeroenhd wrote:
| Android apps need UDP port binding to function. You can't do
| QUIC without UDP. Of course you can (should) restrict localhost
| bound ports to the namespaces of individual apps, but there is
| no easy solution to this problem at the moment.
|
| If you rely on users having to click "yes", then you're just
| making phones harder to use because everyone still using
| Facebook or Instagram will just click whatever buttons make the
| app work.
|
| On the other hand, I have yet to come up with a good reason why
| arbitrary websites need to set up direct connections to devices
| within the local network.
|
| There's the IPv6 argument against the proposed measures, which
| requires work to determine if an address is local or global,
| but that's also much more difficult to enumerate than the IPv4
| space that some websites try to scan. That doesn't mean IPv4
| address shouldn't be protected at all, either. Even with an
| IPv6-shaped hole, blocking local networks (both IPv4 and local
| IPv6) by default makes sense for websites originating from
| outside.
|
| IE did something very similar to this decades ago. They also
| had a system for displaying details about websites' privacy
| policies and data sharing. It's almost disheartening to see
| we're trying to come up with solutions to these problems again.
| thesdev wrote:
| 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"?
| IshKebab wrote:
| It should be "from accessing a user's local network", or "from
| accessing users' local networks".
| paxys wrote:
| It's crazy to me that this has always been the default behavior
| for web browsers. A public website being able to silently access
| your entire filesystem would be an absurd security hole. Yet all
| local network services are considered fair game for XHR, and
| security is left to the server itself. If you are developer and
| run your company's webapp on your dev machine for testing (with
| loose or non-existent security defaults), facebook.com or
| google.com or literally anyone else could be accessing it right
| now. Heck think of everything people deploy unauthed on their
| home network because they trust their router's firewall. Does
| every one of them have the correct CORS configuration?
| numpad0 wrote:
| 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 printer update page. No, we don't need
| that.
|
| Of course, OTOH, many webapps today use localhost access to pass
| tokens and to talk to cooperating apps, but you only need access
| to 127.0.0.0/8 for that which is harder to abuse, so that range
| can be default exempted.
|
| Disabling this, as proposed, does not affect your ability to open
| http://192.168.0.1/login.html, as that's just another "web" site.
| If JS on http://myNAS.local/search-local.html wants to access
| http://myLaptop.local:8000/myNasDesktopAppRemotingApi, only then
| you have to click some buttons to allow it.
|
| Edit: uBlock Origin has filter for it[1]; was unchecked in mine.
|
| 1: https://news.ycombinator.com/item?id=44184799
| gnarbarian wrote:
| I don't like the implications of this. say you want to host a
| game that has a lan play component. that would be illegal.
| rerdavies wrote:
| I worry that there are problems with Ipv6. Can anyone explain to
| me if there actually is a way to determine whether an IPv6 is
| site local? If not, the proposal is going to have problems on
| IPv6-only networks.
|
| I have an struggled with this issue in the past. I have an IoT
| application whose websever wants to reject any requests from a
| non-local address. After failing to find a way to distinguish
| IPv6 local addresses, I ended up redirecting IPv6 requests to the
| local IPv4 address. And that was the end of that.
|
| I feel like I would be in a better position to raise concerns if
| I could confirm that my understanding is correct: that there is
| no practical way for an application to determine whether an IPv6
| address is link- or site-local.
|
| I did experiment with IPv6 "link local" addresses, but these seem
| to be something else altogether different (for use by routers
| rather than general applications),and don't seem to work for
| regular application use.
|
| There is some wiggle room provided by including .local address as
| local servers. But implementation of .local domains seems to be
| inconsistent across various OSs at present. Raspberry PI OS, for
| example, will do mDNS resolution of "some_address" but not of
| "someaddress.local"; Ubuntu 24.04 will resolve
| "someaddress.local", but not "someaddress". And neither will
| resolve "someaddress.local." (which I think was recommended at
| one point, but is now deprecated and non-functional). Which does
| seems like an issue worth raising.
| donnachangstein wrote:
| > Can anyone explain to me if there is any way to determine
| whether an inbound IPv6 address is "local"?
|
| No, because it's the antithesis of IPv6 which is supposed to be
| globally routable. The concept isn't supposed to exist.
|
| Not to mention Google can't even agree on the meaning of
| "local" - the article states they completely changed the
| meaning of "local" to be a redefinition of "private" halfway
| through brainstorming this garbage.
|
| Creating a nonstandard, arbitrary security boundary based on
| CIDR subnets as an HTTP extension is completely bonkers.
|
| As for your application, you're going about it all wrong. Just
| assume your application is public-facing and design your
| security with that in mind. Too many applications make this
| mistake and design saloon-door security into their "local only"
| application which results in overreaction such as the insanity
| that is the topic of discussion here.
___________________________________________________________________
(page generated 2025-06-04 23:00 UTC)