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

71–80 of 198 posts

Re: I can see your local web servers

#71

Post by m12k »

chronial wrote: post #68
lostjohnny wrote: post #66

Earlier quoted context omitted.

It doesn't matter, you should be in control of a DNS the user relies on and you should have your server send Access-Control-Allow-Origin: mypage.com or Access-Control-Allow-Origin: * which is not a default anywhere AFAIK and is domain based, not IP based And your server should be enabled to respond to mypage.com host header

I don't quite understand your comment. Do you mean "shouldn't" whenever you wrote "should"?

I think they write 'should' when they mean 'need to if you want the aforementioned to be a practical attack vector'

Re: I can see your local web servers

#72

Post by chronial »

lostjohnny wrote: post #66
chronial wrote: post #53

Earlier quoted context omitted.

The Cross-Origin check be circumvented via DNS Rebinding: When you request mypage.com, my DNS returns the ip of my webserver. On all subsequent requests, it will return 127.0.0.1. Now localhost is on the same origin as my page.

It doesn't matter, you should be in control of a DNS the user relies on and you should have your server send Access-Control-Allow-Origin: mypage.com or Access-Control-Allow-Origin: * which is not a default anywhere AFAIK and is domain based, not IP based And your server should be enabled to respond to mypage.com host header

Based on m12k's suggested interpretation of your comment:

> you should be in control of a DNS the user relies on

You always are when a users visits your domain – you control the DNS of your domain.

> Access-Control-Allow-Origin: *

You don't need access-control headers, because you stay on the same domain.

> Your server should be enabled to respond to mypage.com host header

Most servers listening on localhost ignore the host header.

Re: I can see your local web servers

#73

Post by kj4ips »

Some time ago, I made something using a similar technique to redirect to router configuration pages. Used WebRTC to get local IPv4, then spawned a worker and timed it, if it came back fast, I assumed it was there, and redirected the user, otherwise I tried a different common "router" address. I was unaware of dns rebinding at the time.

Re: I can see your local web servers

#74

Post by jasonkester »

I only ever run my local dev server on port 80, and use a hosts file to assign custom (fake) domain names to each of the sites I want to run.

I mentioned as much here a few years ago when I first came across this idea of assigning (and remembering) random unique port numbers to every one of your apps in development, and was surprised to hear that it's such a common practice. It seems sub-optimal for a lot of reasons, beyond the obvious one noted in the article.

The big one for me is that none of my apps need to know anything about how to handle port numbers URLs. They know their own domain name via a config setting that can be flipped on the live server. It's the same pattern (with no colons or numbers to worry about) so there are no edge cases to test.

Re: I can see your local web servers

#76

Post by dillonmckay »

jensneuse wrote: post #18
founderling wrote: post #12

I started a local webserver listening on localhost:80 just to see what happens, but this thing seems to not detect it. It shows me "Scanning localhost ... localhost complete." Edit: My guess is that this thing can only detect servers that send a CORS header that permits cross domain access. It could probably do way better detection if it did not do xhr requests but added script/css/whatever elements to its own page p…

CORS is a security mechanism for browsers to prevent leaking user information (e.g. cookies) when doing cross domain requests from a browser. CORS does not prevent accessing the server at all. You can always curl a CORS protected server but you won't be able to make a requests including the user's cookies from a disallowed domain.

Hmmm...

I can see the request in server logs, but it seems CORS is preventing the response.

I may be missing something.

Re: I can see your local web servers

#78

Post by dillonmckay »

shakna wrote: post #57
ypkuby wrote: post #47

Earlier quoted context omitted.

Do you have any locked down policy on them though? I assume this would only work if you gave blanket access. I noticed in my tests it found one on port 3000 with blanket access, but didn't see one on port 9999 with restricted access( policy => allow from *.mydomains )

Yes. I'm terrible and have them set to allow all domains, and all methods.

Maybe your browsers are up-to-date?

Re: I can see your local web servers

#79

Post by phiresky »

gbuk2013 wrote: post #65
phiresky wrote: post #63

Earlier quoted context omitted.

The only thing blocking WebRTC gets you is that it hides which subnet you are on, right? As in, an attacker can still just enumerate all of the common ones (10.0.0.0/24, 192.168.0.1/24, and like 5 others) and get the same results as with WebRTC enabled. So blocking it really just slightly increases the obscurity, but not really the security.

Sure, but it helps and it is cheap. I also don't use a common subnet and enjoy uMatrix. Obscurity is a viable strategy as part of a layered defence. ;)

True.

My main problem is that blocking WebRTC blocks some very interesting methods to "re-decentralize" the web, which are only viable if most people don't have it disabled.

Re: I can see your local web servers

#80

Post by ryanjshaw »

jasonkester wrote: post #74

I only ever run my local dev server on port 80, and use a hosts file to assign custom (fake) domain names to each of the sites I want to run. I mentioned as much here a few years ago when I first came across this idea of assigning (and remembering) random unique port numbers to every one of your apps in development, and was surprised to hear that it's such a common practice. It seems sub-optimal for a lot of reasons,…

Unless I'm missing something, this only works if you are running one site at a time, or you have a single web server bound to port 80 that supports virtual hosts. You also need application and/or configuration support to get this working properly. And even then, if you run any software with an embedded web server you are usually out of luck unless you want to fiddle with a reverse proxy configuration.

For these reasons I, at least, simply run applications on different ports. The problem isn't the port, it's the web browser allowing cross domain requests to local networks by default (another reply here suggested it is WebRTC specifically that is flawed).

Post reply on HN