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

191–198 of 198 posts

Re: I can see your local web servers

#191

Post by nodesocket »

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…

> Scanning localhost ... localhost complete.

Yet I am running Node.js http-server[1], and see the request in the logs:

    [Tue May 28 2019 23:56:54 GMT-0500 (Central Daylight Time)] "GET /" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36"
[1] https://github.com/indexzero/http-server

Re: I can see your local web servers

#192

Post by lostmsu »

Skunkleton wrote: post #172
ozim wrote: post #165

Earlier quoted context omitted.

I started python -m SimpleHTTPServer 5000 and site reports nothing, but I get: 127.0.0.1 - - [28/May/2019 22:14:51] "GET / HTTP/1.1" 200 - each time I refresh page. So it sends request that is received by server but somehow does not register on site.

Because your browser is preventing the javascript from accessing the response.

I wonder if one can read the response via the time side-channel attack.

Re: I can see your local web servers

#193

Post by rewq4321 »

lostjohnny wrote: post #118
tlrobinson wrote: post #98

Earlier quoted context omitted.

The post specifically mentions CORS and shows an example Express app that has CORS enabled.

CORS is not enabled by default anywhere, I have few servers running right now on my laptop and the page can't see any of them, because all of them have CORS disabled First thing you do when you enable CORS is to configure it to only respond to specific domains, so when you deploy to production you don't leave it open by accident. BTW if you enable CORS as in 'simple usage' in the docs, chances are the home page is a…

Recently I was testing a client-side algorithm that pulled a lot of data from the server and I thought my http server might have been the bottleneck, and so I spun up a few copies of the server but had to enable cors to get the client talking to them all. Newbs like me don't realise that localhost+cors = exposed to the www, so this article was very surprising and useful. This app is only used internally and so your deployment justification doesn't make sense for this case, but I will definitely make sure only specific domains are exempted in the future, thanks to this article.

Re: I can see your local web servers

#194

Post by lostjohnny »

OvermindDL1 wrote: post #187
lostjohnny wrote: post #123

Earlier quoted context omitted.

> 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?

Not by default [1], but you can set it to what you prefer.

But in my case my network is configured to always reach the in house DNS first, to keep latency low

[1] https://github.com/letsencrypt/boulder/blob/8167abd5e3c7a142...

Re: I can see your local web servers

#196

Post by johnp_ »

dredmorbius wrote: post #169
gnomewascool wrote: post #30

If you use uMatrix, you can easily block the localhost and local network "sniffing" with the following rule[0]: * 127 * block ### block access to IPv4 localhost 127.x.x.x * localhost * block * [::1] * block ### block access to IPv6 localhost * 192.168 * block ### block access to LAN 192.168.x.x In principle, you can use this without any other blocking, i.e. with the rule: * * * allow and hence without disabling javas…

Add all the RFC1918 unroutable private networks. https://en.wikipedia.org/wiki/Private_network 10.0.0.0 – 10.255.255.255 (10.0.0.0/8) 172.16.0.0 – 172.31.255.255 (172.16.0.0/12) 192.168.0.0 - 192.168.255.255 (192.168.0.0/16) 127.0.0.0 - 127.255.255.255 (127.0.0.0/8) https://tools.ietf.org/html/rfc1918 Possibly also 100.64.0.0/10 for carriers. https://tools.ietf.org/html/rfc6598#page-8

Possibly also the IPv6 ULAs:

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

Not sure if those can be expressed in uMatrix as a prefix rule.

Re: I can see your local web servers

#197

Post by londons_explore »

jasonkester wrote: post #116
ryanjshaw wrote: post #80

Earlier quoted context omitted.

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 reaso…

IIS handles all this out of the box for me. I just bind the host name to the site in question. It sounds like maybe this isn’t something that other web servers do, which is surprising. The whole point of the operation is to seamlessly run 30 odd websites on one dev machine without needing to fiddle with port numbers or anything else.

In the *nix world and with the move to containerization, most applications now assume they are the only thing running on the web server, and therefore demand custom config/settings. Node apps for example are their own server.

Re: I can see your local web servers

#198

Post by boomlinde »

linuxftw wrote: post #128
boomlinde wrote: post #127

Earlier quoted context omitted.

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…

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…

> 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.

Post reply on HN