Hacker News Reader

Comment by tomxor | Hacker News Reader

> The major browsers I've tested — Safari, Chrome, Firefox — all allow web pages to send requests not only to localhost but also to any IP address on your Local Area Network! Can you believe that? I'm both astonished and horrified.

I'm sorry but WtF who is this guy, every web developer will know this, and every developer should expect it since it's just an extension of basic networking knowledge applied to web browsers. It's not horrifying, it's basics, a great many things have depended on this fact to function for a very long time.

Yes functionality can work against you when abused, no this is not a special case.

View on HN

This is Hacker News. We all know this. That's not the point. The point is: is it reasonable in 2019 that websites you visit can make requests to devices on your local network? To be honest I'm not sure. But I sure think it's a relevant discussion to have.

How is the browser supposed to reason about "local"?

127.0.0.1/localhost are kind of obvious no?

https://en.wikipedia.org/wiki/Private_network

What if your DHCP doesn't give you a private IP address? When I was at the University of Michigan, my personal laptop always received a public IP address. Or if I'm in a pure-IPv6 setup, using prefix delegation/SLAAC? This problem is a lot harder than "just use the RFC1918 list of reserved private IP ranges".

Fixing the issue for people on properly configured networks is already an improvement worth doing.

The UMich network isn't "improperly configured". NAT-less networks have been around since the beginning of the Internet, and IPv6 networks don't use NAT (unless they're accessing IPv4-only targets, but that's CGNAT). I think you'll find a great deal of university/research settings have networks configured without NAT. If you can come up with a solution that works in all cases, I'd love to hear it.

There are 3 well defined private network ranges, 1 loopback range and a few other random things. It's not silly to ask whether an address outside of them should be able to initiate connections to them. (In the context of a browser running on that network that is)

So, when a company decides to run internal services for its non-technical employees on its internal network, now they have to make sure that all the user’s devices on the LAN (including BYOD devices) are configured properly?

Cool, so make it drivable via policy files like e.g. client cert pinning in Chrome. Industry has solved these problems, making excuses for fixing it is not good at this point.

I don't see how that use case is affected. Could you post a specific example you think would be broken?

I would suggest that all requests must require a DNS lookup. No requests directly to IP addresses, full stop.

This prevents LAN enumeration from random websites. This is not a big deal for most home networks, but I shudder to think of the damage one could do in a standard corporate network.

It doesn't help with routers with well-known config URLs.

Yes, I realize that this will break a bunch of stuff.

(Edit: OK, DNS rebinding mostly breaks this proposal. Let me think about this harder.)

How would this help at all? You could just have your domain return LAN various LAN ips for different domains... there are already a ton of domains that return 127.0.0.1 for you. It would be trivial to make your own to do every possible IP.... something like 127.0.0.1.myfakedomain.com, where it dynamically extracts the IP and returns it.

Bogons?

> How is the browser supposed to reason about "local"?

That isn't even the issue. It's that there is nothing inherently wrong or unusual with mixing local and internet requests.

Look at IFPS -- it runs a webserver on localhost which you can request content from by using content hashes. There is nothing wrong with a website on the internet which anticipates that you to have IFPS installed and uses it to request page elements. It can even use javascript to detect that you have it and use a different (e.g. slower or more expensive) source for the content if you don't, or show a message explaining how to install it.

Or you have a company with some internal servers where some of them have public addresses (or public IPv6 addresses) while some don't, but they arbitrarily access resources on the others because they're all managed by the same people.

This isn't a browser problem. Browsers are supposed to work this way.

Yes, exactly. This should be a top-level comment. The uninformed delirium over intentional and useful browser features moves us in a slow crawl towards a sad husk of what the Web used to be in the name of 'security'.

The web has changed. It has become a vastly more hostile environment. In my view, the appropriate way of acknowledging this change is to prioritize security over features. Whether a feature is useful or not is no longer the primary consideration.

A denial of service doesn't improve security. All you do is get users to mash whatever knobs they can find until it starts working again regardless of the implications, or disable updates so they can keep using the old version that works instead of the new version that doesn't.

You need to fix the things that are broken instead of breaking the things that are working.

How does prioritizing security equate to "denial of service"? A securely designed system can be user friendly.

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.

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

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.

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.

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.

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.

> 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

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.

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.

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.

Yes there is - RFC1918.

1: not everyone is a software developer here and 2: not everyone is a web developer. I've barely done front end stuff and do almost exclusively backend stuff so I didn't know that.

So does that mean any tab I have open on my computer can try and talk to my local development mysql server and my local development web server? That's crazy. Wasn't there also an article in the past year about how a bunch of IOT devices run unsecure on LAN because they assume they are secure?

Totally agree. I don't think it makes sense for an arbitrary website to send requests against shitty IOT devices in someone's home, for example. Yes, you could argue that mom should be putting her IOT devices on a VLAN, but come on. The obvious, ethical solution is for the browsers to implement this layer of protection and make it obvious to the users when an access is attempted.

Websites I visit should not be allowed to make ANY fucking requests. FULL STOP.

How do you load an image in a browser without making a request?

So web browsers are user agents, i.e. they act on your behalf. This is great because we can avoid heated arguments about what websites "should" or "shouldn't" be able to do as it's ultimately up to the user.

I assume you've already setup the relevant browser settings and extensions to enforce a user-defined CSP that blocks all further requests? If so, then great, your browser won't make any requests when you visit sites. And my browser will (apart from what I've blocked with other more selective extensions). We're both happy.

So, goodbye CDNs, AJAX, DNS load balancing, most websocket applications, third party image and script hosts, and so on?

Thats not what I am saying(or maybe it is): sites shouldnt be able to access OTHER machines on my network at all.

The correct method is fixing the CSRF in your insecure software in LAN, not restricting other developers.

Is there a legitimate reason why 'other developers' might want to access services on my LAN?

There are legitimate reasons why other developers might want to access stuff on their LANs.

There are. Let them set a setting or confirm on a popup. The vast majority of web users do not want this.

Similarly, there are legitimate reasons why I might want to access a service with an invalid SSL cert. They're rare and should be discouraged for general users.

Vast majority of users don't want CSRF-able software either. Let's first discourage such garbage software before making workarounds. In addition to that, those workarounds most likely will not eliminate all the possible issues and buggy software still gets exploited.

Not every TCP server speaks CSRF.

This isn't about 'garbage software'; it's about the expectation that a local LAN is not exposed to the Internet and therefore does not need the same security controls that an Internet-facing network does.

Browsers making requests on the LAN breaks this expectation.

Before someone says "but I don't expect that", well, why do you even have a firewall? With the notable exception of Google/BeyondCorp, practically every LAN in the world expects to trust its members. Having untrusted code in browsers able to send requests on the LAN violates that expectation.

a) You can't establish a plain TCP connection with arbitrary content using a browser.

b) Excepting LAN to be always secure, or okay to keep unsecured is a terrible assumption that has been proven wrong numerous times, it is time to trash that assumption once and for all.

Implementing CSRF doesn’t stop an outside party from finding out that you have (for example) an AppleTV inside your network. The device will still return a HTTP status code. You could legit spy on end users this way. A real boon for ad tech, too.

Such specific detections could be countered by Apple, it serves no good adtech purpose if they can determine some small amount of devices existing on a LAN.

In general though, this isn't be a problem on proper IPv6 LANs and instead of buggy and cumbersome workarounds being built into browsers we should just switch.

Counterpoint: Is it reasonable in 2019 to treat networks with clients connected to the internet as "trusted" for security purposes?

Yes it is reasonable, but it should be subject to CORS rules as any address.

It’s interesting you say this. I work as a web developer, I consider myself to be more or less well versed in security, and it would have never occurred to me that websites can make requests to devices inside the standard private blocks of addresses. I think it stands to reason that these requests should be blocked in the same way requests to the file:// protocol are blocked.

> I'm sorry but WtF who is this guy

Can you please make your substantive points without making things personal?

https://news.ycombinator.com/newsguidelines.html

This is not ad hominem, this is me calling out a person's shallow criticism of a technical detail with no attempt to understand the history and background of one of the most unobscure features of networking, and the audacity to proclaim to the world how shocking and terrible it is.

It's essentially 2nd order ignorance, it's not personal, it's relevant to the validity of their argument.

Users need to follow the site guidelines regardless of how ignorant someone else is or how strongly you disagree. Maybe you don't owe the author better, but you owe this community better if you want to post here.

The online calling-out and shaming culture is particularly unwanted on HN. It has a degrading effect on the community.

> a great many things have depended on this fact to function for a very long time

Such as? Breaking "website makes a call to local (localhost or RFC1918) web server" would be a feature; any use of this is an abuse. It'd take a transition period and some careful opt-outs, but any kind of call to a local web server should require the same kind of special privileges a browser extension needs, at the very least.

It's a bug. Calling it out is the right thing to do. If you're complaining that the author should have known about it already, then you're just mocking someone for not already knowing a particular fact; that shouldn't stop them from writing up a report on it and trying to get it fixed.

EDIT: please note that I'm talking about calls from Internet origins to localhost/RFC1918 origins here, not calls from one Internet origin to another or one localhost/RFC1918 origin to another.

This is not a bug. It is a feature. It's called a cross-origin request and numerous websites depend on it. The recipient website needs to be CORS enabled, so it is secure. The author's report is misinformed, and pretending Apple should implement some feature outside of standards is silly. Yes, this feature could be improved, but not by disabling it or by making Apple become standards non-compliant

I'm not talking about cross-origin requests in general; those are completely fine and reasonable.

I'm talking about requests from pages served from the Internet to servers on localhost or servers on an RFC1918 address.

I feel that the distinction between internet and local is unnecessary. Isn't it equally bad if someone sends a request to your CORS-broken local webcam as it is if they send a request to your CORS-broken bank account?

Or does SOP not apply to local addresses?

I think for all cases it could make sense to enable the user to also approve CORS requests instead of just the cross origin website itself (since they are often insecure).

> Isn't it equally bad if someone sends a request to your CORS-broken local webcam as it is if they send a request to your CORS-broken bank account?

This comes from the same line of thinking as "shouldn't every device have a routable IP?". Yes, in theory, but a long history of not having one has made people more lax about local systems and securing services. And until the vast majority of local services address their security issues, we shouldn't make them accessible.

> Or does SOP not apply to local addresses?

It should, but that's not the world we have. Yes, we should fix the million local devices with CSRF/CORS/etc issues. We should also have an extra layer of protection in web browsers to prevent this. Defense in depth. (And note that many local devices do this intentionally, to give a website more permissions, as in the case of Zoom. The local web server wants to make itself accessible to the Internet; browsers should prevent that.)

Totally agree, that makes good sense.

Reply on news.ycombinator.com