Hacker News Reader

Comment by iameli | Hacker News Reader

> In general, there's no reason why a page on the internet should be allowed to access devices on your local area network. Of course, if the user enters a LAN IP into the browser location bar, this should be allowed, but that's not a cross-origin request.

What's a local area network? 10.x.x.x? That's going to break VPNs and enterprise integrations in a variety of ways. With IPv6 it's even less predictable.

The solution to this problem is CORS — accessing LAN servers, or any cross-origin destination, requires affirmative consent from the LAN server in the form of the Access-Control-Allow-Origin header.

View on HN

If you can't control the lan server, like in zoom case, cors won't save you. In fact it did not save you a bit in this case.

Who is "you" here? The user? Zoom?

You is you. The user. I do not control the zoom local server, and I do not control what the zoom server answer as the cors header. Having cors enabled in my browser do not save me from anything in this case.

What do you mean about the “zoom case?”

Zoom did control the localhost server, and setting a CORS header would have helped mitigate the attack.

Zoom did control the localhost server, you did not.

If zoom made the localhost server answer the cors header with '*', what you can do?

Ah, gotcha.

Perhaps I should have said "The solution to this problem is _properly-implemented_ CORS." My point is that browsers already have a mechanism for mitigating this particular problem and I don't think the additional proposed mitigation (restricting browser access to localhost/LANs) would break a lot of legitimate usage without much benefit.

There's only so much browsers can do to mitigate hostile code running on the machine. CORS won't save me if Zoom decided to wipe my hard drive, you know?

Hmm… servers on localhost could be required to have CORS headers.

That also makes it much harder to extract interesting information from non-HTTP servers running on localhost.

I was too wondering about how this could work in IPv6.

There is no equivalent of RFC1918 for IPv6 and filtering link-local addresses won't do much as every host on the LAN is still adressable by its publicly routable address. These are probably too hard to predict, though.

You assume that the target is a web server. I can learn lots of interesting things by firing GET requests at non-web servers.

You mean with image requests or something, right? Actual fetch() and XHR won't even tell JavaScript that a server exists unless it passes the CORS preflight check.

Reply on news.ycombinator.com