[tlb]

There's no uniform criteria for "local network". I can create a local device at any address I want. These days most are within 192.168 and 172.17 and 10., but not all.

As an example of legitimate use, Ubiquiti routers have a web app at ubiquiti.com that opens connections to manage your local routers. It's all authenticated with cookies. It seems like a good design.

[amarshall]

> There's no uniform criteria for "local network". I can create a local device at any address I want.

Certain subnets are always private [1], and thus may safely treated as “local”. But, of course, non-private addresses could also be local, but that’s less common in a non-enterprise setting.

[1] https://en.wikipedia.org/wiki/Private_network

[nojvek]

This isn't a local network issue though, this is a cross origin issue that Browsers definitely need to patch.

A script from the internet should not be allowed to interface with a script from local network (localhost, local intranet e.t.c)

The browser should have strict sandboxes. This is like when you load a site over https, browsers scream at you if you load a http resource saying it's insecure.

[tlb]

Cross-origin is based on the domain name. It offers no protection against an attacker poking your local IP addresses.

You can have multiple IPs for a domain name, so if I set "hack.tlb.org" to include both a server I control and 192.168.1.1, I can repeatedly do fetches from "hack.tlb.org" until one of them gets your router instead of my server. And they're in the "same origin" for CORS purposes.

[magicalhippo]

Plex is another example.

You log into app.plex.com, which will connect to yourserver.account.plex.local or something like that, which resolves to an IP on your LAN. Your server will then feed the web page app with data, without going via your WAN link.

[r00fus]

Thanks - I had no idea that Ubiquiti webapp existed! How about those internal-by-spec ranges + localhost as "security popup/alert" in major browsers? Or default deny with a popup to allow?

I really struggle to see why "legitimate use" that's a minority of all use cases should forbid a consensus from cordoning off a major attack surface with an affordance for that legitimate usage.

[fiddlerwoaroof]

It isn’t really a “major attack surface” and it would be better to configure routers to rewrite DNS responses within the subnet that they control by default than to add an arbitrary set of rules to browsers, breaking all sorts of developer tools and other useful functionality.

Also, legitimate services on the local network have tools like CORS and CSPs as well as standard anti-XSS and anti-CSRF techniques to use to defend themselves.

[r00fus]

Wait, which is easier/more feasible - adding security to browsers which restricts a fringe usage, or corralling all the router manufacturers to update their software to rewrite DNS responses? Wouldn't it result in the same outcome anyway?

Based on history I know which group I would expect to implement first.

[hacker_newz]

Yes there is - RFC1918.

[sascha_sl]

This is categorically false, unless you mean "I can point a domain name to a private IP range".

[tlb]

I'm not sure which part you think is false?

Some larger companies use public IP addresses for everyone's desktop, but they're still behind a firewall. So these are "local" in the sense of behind their firewall, despite being "publicly" routable addresses.

An attacker can create a domain name pointing to any IP, including 127.0.0.1 and 192.168.1.1. So browsers won't gain any security by looking at the domain name.