4 ms·

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 n

by tlb 7y ago

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.

sascha_sl 7y ago
This is categorically false, unless you mean "I can point a domain name to a private IP range".
- tlb 7y ago
  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.
r00fus 7y ago
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 7y ago
  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 7y ago
    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.
amarshall 7y ago
> 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 https://en.wikipedia.org/wiki/Private_network
- nojvek 7y ago
  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 7y ago
    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 7y ago
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.
hacker_newz 7y ago
Yes there is - RFC1918.

by tlb 7y ago

sascha_sl 7y ago

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

tlb 7y ago
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.

r00fus 7y ago

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

amarshall 7y ago

> 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 https://en.wikipedia.org/wiki/Private_network

nojvek 7y ago
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 7y ago
  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 7y ago

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.

hacker_newz 7y ago

Yes there is - RFC1918.