Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I can see your local web servers

http.jameshfisher.com

Post reply on HN
Print view View original

181–190 of 198 posts

Re: I can see your local web servers

#181

Post by mehrdadn »

linuxftw wrote: post #180
mehrdadn wrote: post #160

Earlier quoted context omitted.

This makes no sense. I'm just talking about localhost, I don't care where the physical computer is. It makes no difference if you're an enterprise with software running on a private or public or whatever IP. Whatever the case, I still don't see why you should be able to use JS to access a localhost address.

But what if your webserver is bound to 0.0.0.0:80? Which IP ranges do you block? Just the lo interface? Well, that wouldn't prevent this exploit as the webserver would be listening on all of your IP addresses.

What? Nobody cares what the listener is listening to. Nobody even cares if a listener even exists. It's completely irrelevant. You just block the outgoing request if it's sent to a localhost address from a non-localhost address. What's so complicated about this?

Re: I can see your local web servers

#182

Post by linuxftw »

mehrdadn wrote: post #181
linuxftw wrote: post #180

Earlier quoted context omitted.

But what if your webserver is bound to 0.0.0.0:80? Which IP ranges do you block? Just the lo interface? Well, that wouldn't prevent this exploit as the webserver would be listening on all of your IP addresses.

What? Nobody cares what the listener is listening to. Nobody even cares if a listener even exists. It's completely irrelevant. You just block the outgoing request if it's sent to a localhost address from a non-localhost address. What's so complicated about this?

If you're suggesting that anything not originating on an enumerated list of IP's for localhost cannot request an url for something that resolves to an entry in an enumerated list of IP's for localhost, that would be possible, but is not really representative of the entire surface area of the effect demonstrated in the article.

It's also entirely possible you have some development api running on a particular port on localhost, and some app running in a container or VM that wants to make calls to it.

Re: I can see your local web servers

#183

Post by mehrdadn »

linuxftw wrote: post #182
mehrdadn wrote: post #181

Earlier quoted context omitted.

What? Nobody cares what the listener is listening to. Nobody even cares if a listener even exists. It's completely irrelevant. You just block the outgoing request if it's sent to a localhost address from a non-localhost address. What's so complicated about this?

If you're suggesting that anything not originating on an enumerated list of IP's for localhost cannot request an url for something that resolves to an entry in an enumerated list of IP's for localhost, that would be possible, but is not really representative of the entire surface area of the effect demonstrated in the article. It's also entirely possible you have some development api running on a particular port on l…

> is not really representative of the entire surface area of the effect demonstrated in the article

So let's let perfect be the enemy of good? What's the logic here? Let's leave a huge security hole because we can't achieve perfection in all scenarios?

> It's also entirely possible you have some development api running on a particular port on localhost, and some app running in a container or VM that wants to make calls to it.

The VM should be on localhost or you should jump through a few hoops to whitelist it somehow. I see no reason why this should be allowed by default.

Re: I can see your local web servers

#184

Post by linuxftw »

mehrdadn wrote: post #183
linuxftw wrote: post #182

Earlier quoted context omitted.

If you're suggesting that anything not originating on an enumerated list of IP's for localhost cannot request an url for something that resolves to an entry in an enumerated list of IP's for localhost, that would be possible, but is not really representative of the entire surface area of the effect demonstrated in the article. It's also entirely possible you have some development api running on a particular port on l…

> is not really representative of the entire surface area of the effect demonstrated in the article So let's let perfect be the enemy of good? What's the logic here? Let's leave a huge security hole because we can't achieve perfection in all scenarios? > It's also entirely possible you have some development api running on a particular port on localhost, and some app running in a container or VM that wants to make cal…

> So let's let perfect be the enemy of good? What's the logic here? Let's leave a huge security hole because we can't achieve perfection in all scenarios?

The logic here is don't hastily start implementing changes to how http requests currently work without a well established plan for doing so. I think there would be a good deal of corner cases you need to account for to successfully implement this feature.

Anyway, this problem seems pretty obvious, and I'm sure this discussion has been had elsewhere already.

Re: I can see your local web servers

#185

Post by mehrdadn »

linuxftw wrote: post #184
mehrdadn wrote: post #183

Earlier quoted context omitted.

> is not really representative of the entire surface area of the effect demonstrated in the article So let's let perfect be the enemy of good? What's the logic here? Let's leave a huge security hole because we can't achieve perfection in all scenarios? > It's also entirely possible you have some development api running on a particular port on localhost, and some app running in a container or VM that wants to make cal…

> So let's let perfect be the enemy of good? What's the logic here? Let's leave a huge security hole because we can't achieve perfection in all scenarios? The logic here is don't hastily start implementing changes to how http requests currently work without a well established plan for doing so. I think there would be a good deal of corner cases you need to account for to successfully implement this feature. Anyway, t…

> The logic here is don't hastily start implementing changes to how http requests currently work without a well established plan for doing so.

As if the point of this thread was to push browser vendors to hastily implement this without thinking it through? Are you just trying to find something to have an argument over? I'm tired of this.

Re: I can see your local web servers

#186

Post by brlewis »

gambler wrote: post #171
kyle-rb wrote: post #161

Earlier quoted context omitted.

I disagree about domain names, but I don't think that's even relevant to this discussion. Do you have some kind of security model in mind that would work better than same-origin policy in this case? I.e. cross-origin requests are still allowed to happen somehow, but users are still protected against random services intentionally disabling your security measures?

It is bloody obvious that when people spin something up on their local machines the do not intend to make those pages available to every website they visit. This by itself suggests that there should be a dedicated security context for such applications and that the restriction on information exchange should be based on that context. Not on some random thing the application does (like authentication, CSRF or sending C…

>an afterthought achieved by applying layers and layers of security ducktape

This is where you're missing the fundamental nature of the issue in this article. The sensible security model is there by default. An additional layer is added to make a resource available cross-origin, and the article merely serves to remind people that making a resource available cross-origin is still making it available cross-origin when the origin is localhost.

Re: I can see your local web servers

#187

Post by OvermindDL1 »

lostjohnny wrote: post #123
tgragnato wrote: post #117

Earlier quoted context omitted.

> But even if you did, you still haven't resolved the issue: you can't make a call to a different domain without access-control headers, unless it's the same domain > you can't load mypage.com and then fetch from www.mypage.com, even if you resolve www.mypage.com to 127.0.0.1 the browser won't let you do it In this part you’re confusing what a rebinding attack is: by serving a DNS response with a short TTL an attacke…

> In this part you’re confusing what a rebinding attack is: by serving a DNS response with a short TTL an attacker is able to associate two different IPs But it doesn't really work. I query my DNS, on my home router, not your DNS. And the DNS on my home router query the ISP's DNS, which caches requests. I bet you can't go below few minutes resolution. I had this problem when validating the Letsencrypt DNS challenge,…

Wait, doesn't the certbot DNS challenge query the nameservers of the domain being checked, not your local DNS resolver, otherwise my fast DNS challenges should fail?

Re: I can see your local web servers

#189

Post by efreak »

mehrdadn wrote: post #35

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?

Caching reverse proxies for local virtual machine use, in my case. Primarily used for Linux repos, but also configured for personal use, eg for webcomics.

Re: I can see your local web servers

#190

Post by mehrdadn »

efreak wrote: post #189
mehrdadn wrote: post #35

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?

Caching reverse proxies for local virtual machine use, in my case. Primarily used for Linux repos, but also configured for personal use, eg for webcomics.

That's about as far from compelling a reason as you can imagine for the browser to allow this by default?
Post reply on HN