Hacker News Reader

Comment by darthwalsh | Hacker News Reader

Is there a way to prevent websites from the broader Internet from making network requests to my local network? I can't imagine why this should be allowed by default.

(Not to suggest bringing back IE's Local Intranet Zone permission...)

View on HN

They generally can't, because of CORS. The only reason this "hack" works is because the timing of the rejection is different between non-resolving domain request and resolving-but-rejected request. But if you run something on https://192.168.2.1 it can't be accessed from a web app running on https://my-own-domain.com unless the service running at 192.168.2.1 allows the "Origin" my-own-domain.com.

Technically they can make the request. The server will receive and respond to the request. CORS is applied by the browser which prevents the response from being read. This is why CORS doesn't prevent a request from mutating something on a server. A CSRF token does.

Is that true? There’s a preflight request that checks with the server as to what’s allowed and then the browser issues the original request if it’s ok, right?

"Simple requests" are not preflighted, such as those that do not set any headers (among other qualifications).

https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simpl...

(Aside, is MDN's href linking broken for everyone or just me?)

It should be noted chrome is changing this behaviour for local networks - https://wicg.github.io/private-network-access/

Re: your aside, the link works for me. I'm taken directly to the "Simple requests" section.

link works for me

"Simple" requests are sent without a OPTIONS preflight check. It's because old style forms could always do a cross-origin request, so you have to protect against it anyway.

For the full definition of what is a "simple" request: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simpl...

EDIT: Lol @ jakear making an almost identical response with the same Mozilla link.

Not only forms, img and link tags supported cross origin sources too, with no user action required.

There are plenty of browser implementations in things like SmartTVs that don’t implement CORS and other security related features correctly.

First of all, you could probably do a timing attack on CORS response, you'd just have to deal with how much they're cached.

Depends on the resource request. For example, <img> can be used to load remote resources without CORS, since the image data isn't shared with JS (trying to read it via a canvas marks it "tainted", and errors read requests). Meltdown/Spectre breaks this barrier down, which led to the introduction of COOP/COEP headers that require CORS on remote requests and would break this attack—except that you can ask the browser to send requests without cookies, re-introducing this timing attack.

And none of this helps you if the server in question isn't actually a HTTP server, but something else (that only ever expected to be exposed on localhost). Depending on the exact syntax it expects, it's plausible that a HTTP request (even a CORS request) might be misinterpreted to do something nefarious.

Unless of course the service has no CORS headers and https://192-168-2-1.my-own-domain.com doesn’t resolve to 192.168.2.1.

But you could DDoS something on the internal network.

Brave recently added a feature requiring permission to access the local network:

https://brave.com/privacy-updates/27-localhost-permission/

On HN: https://news.ycombinator.com/item?id=36574775

A common abuser of this is the Discord desktop app, which listens on a local port.

When your browser navigates to a Discord channel's join page, it sends a request to localhost via this port and sends the channel ID to the client. This lets the app pop open a native 'Join Channel' experience.

I discovered this when I noticed how this behavior worked even in incognito mode and my browser was signed out of Discord.

Not. Cool. We need to massively improve sandboxing - of all applications - in the desktop world.

Why is this such a big deal? Have it as an option to disable, sure, but it makes handling auth between the desktop and browser so much easier.

> I discovered this when I noticed how this behavior worked even in incognito mode and my browser was signed out of Discord.

That is exactly what is nice about the feature, not having to be logged in on the browser, I love it.

Why in the world have people flagged this comment?

uBlock Origin static filter:

    ||local^$all

This will block all requests to .local, even from .local itself. If you want to allow foo.local to talk to itself, say because you run a webserver on it, you'll have to add additional overrides for each such domain:

    @@||foo.local^$domain=foo.local,all

... or if you trust your .local entirely to allow any foo.local to talk to any bar.local, you can add one override for all of .local:

    @@||local^$domain=local,all

This essentially blocks all .local domains from the browser user gen or not

To avoid confusion, this is not about an internet server making requests to your local network, but your local web browser making those requests. Although, the javascript executed in the browser can be loaded from an internet server, of course.

Yes. Change the client. For example, I'm using one that does not auto-load resources, does not run Javascript and does not perform DNS prefetching. There is no way for the website (cf. user) to make network requests.

This experiment is of course limited to users who do not change defaults, since any MacOS user can easily change their hostname to anything they want, and that is quite easy to do, even for people who do not read HN. The "real name" might not be real if the user has changed the default. Is there any reliable way for the website to distinguish "real" from "fake" names in MacOS hostnames.

uBlock Origin ships with a (default disabled) “Block Outsider Intrusion into LAN” blocklist, it has some default exclusions though. https://github.com/uBlockOrigin/uAssets/blob/01eba0c1445c881...

And, indeed, when I run the PoC from the article, all the requests are blocked by uB0.

https://developer.chrome.com/blog/private-network-access-pre... is one idea being actively worked on in this area

>This content is outdated and no longer accurate. New material available.

The "new material" is https://developer.chrome.com/blog/private-network-access-upd... and changed from restricting all "public websites" to only restricting non-HTTPS sites.

It does at least say:

>Restricting private network requests to secure contexts is only the first step in launching Private Network Access.

... so maybe it'll become better later.

My WiFi access points allow me to configure networks so that no devices on it are allowed to make requests to the local network. I haven't done this with networks used by my PCs, though, just for televisions and IoT devices.

iOS already has a Local Network Access permission, it's probably only a matter of time until it appears in macOS as well.

Reply on news.ycombinator.com