←back to thread

I can see your local web servers

(http.jameshfisher.com)
652 points jamesfisher | 3 comments | | HN request time: 0s | source
Show context
mehrdadn ◴[] No.20028539[source]
Here's a question I've had for a while: WHY in the world do web browsers not block access to localhost? What exactly is the extremely compelling use case that has prevented them from blocking this?
replies(6): >>20028568 #>>20028760 #>>20029313 #>>20029331 #>>20032073 #>>20036758 #
mjlee ◴[] No.20029331[source]
There are a fair number of applications that expose a UI with a local web server. I use the Ubiquiti Controller, but it's also quite common in the world of Plex, etc. It's also a path used for local OIDC, such as with the gcloud CLI.
replies(1): >>20029377 #
mehrdadn ◴[] No.20029377[source]
> expose a UI with a local web server

I'm not talking about UIs hosted on local web servers being able to send requests to themselves, I'm talking about UIs hosted on REMOTE web servers being able to send requests to local ones. It seems far worse than a random cross-origin request to me and for the life of me I can't imagine uses cases.

replies(2): >>20029984 #>>20030184 #
linuxftw ◴[] No.20030184[source]
That's not really how the internet works.

What is a local webserver? Running on your machine? Running on your LAN? Running on your corporate intranet? How should a browser differentiate between these things?

What qualifies as a remote server? Did you know, some very large enterprise environments squat on public IP's for private intranet internally due to address space exhaustion (IPv4 anyway)? Just because something appears to be on a public address doesn't mean it actually is.

replies(2): >>20030924 #>>20033739 #
1. boomlinde ◴[] No.20030924[source]
It seems like an obvious measure would be for sites served outside the private-use or loopback ranges to be unable to request content from servers in private-use or loopback ranges.

> Did you know, some very large enterprise environments squat on public IP's for private intranet internally due to address space exhaustion (IPv4 anyway)?

Sucks to be them. If they've exhausted their private use IPv4 addresses, they can either rest comfortably knowing that NAT and IPv6 can solve their problem or they can ignore IETF recommendations and build a card house network that breaks if you give it a stern look.

replies(1): >>20031026 #
2. linuxftw ◴[] No.20031026[source]
My preferred solution would be to disable javascript altogether.

> Sucks to be them. If they've exhausted their private use IPv4 addresses, they can either rest comfortably knowing that NAT and IPv6 can solve their problem or they can ignore IETF recommendations and build a card house network that breaks if you give it a stern look.

This will only lead to organizations running IE7 (or whatever outdated IE version is most common now) forever.

replies(1): >>20146363 #
3. boomlinde ◴[] No.20146363[source]
> My preferred solution would be to disable javascript altogether.

My preferred solution would be not to use web browsers at all, but our preferred solutions are much harder to make a case for than a simple security policy.

> This will only lead to organizations running IE7 (or whatever outdated IE version is most common now) forever.

In general, let's let them make that choice, but this could be configurable in the browser in the same way Javascript and cookie policy exceptions are handled.