Live data from Hacker News

I can see your local web servers

http.jameshfisher.com

171–180 of 198 posts

Re: I can see your local web servers

#171

Earlier quoted context omitted.

Same-origin policy is not a security model. It's a ridiculous quarter century old hack. If you pause to think about it, domain names are a horrible way to delineate security boundaries on the web.

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 CORS headers).

Scenarios like that should be the foundation of a sensible security model, not an afterthought achieved by applying layers and layers of security ducktape in every single instance.

Re: I can see your local web servers

#172
post #165

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…

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.

Re: I can see your local web servers

#173

Earlier quoted context omitted.

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…

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.

IIRC dell uses this to load support information into site. It's a reason, not saying it's a good one.

Re: I can see your local web servers

#174

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…

>Not on some random thing the application does (like authentication, CSRF or sending CORS headers).

Sending CORS headers isn't "some random thing" though, it's specifically the one thing that stops the security model that's in place from working.

There's a lot of bad security practices that you could define as "some random thing", and the fact that some people might do that thing doesn't make the whole model around it invalid.

Re: I can see your local web servers

#175
post #107

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…

Anyone know if this can be done on a hosts level instead of a browser level?

It can’t. At best you can try to modify the hosts file to point localhost to somewhere bogus, but aside from the potential breakage that could cause, it won’t help against any site that simply accesses http://127.0.0.1 instead of http://localhost. In general, the hosts file can be useful for quick-and-dirty blocking, but it’s not really capable of enforcing a security barrier.

Edit: But there may be other ways to do it at an OS level, depending on your OS.

Re: I can see your local web servers

#176

Earlier quoted context omitted.

Hmmm... I can see the request in server logs, but it seems CORS is preventing the response. I may be missing something.

They way this is set up it's enumerating systems and ports on internal networks, not actually accessing those systems and ports. The CORS header (or lack thereof) in the HTTP response of the requested item is what dictates whether it can be accessed, so what happens is the request first sends a HEAD request to get the headers for the endpoint, and then if CORS is set up and allowed for cross-domain access is allows t…

That all makes sense, but the OP said that the scan didn’t identify their HTTP server. I wonder why.

Re: I can see your local web servers

#177
post #176

Earlier quoted context omitted.

They way this is set up it's enumerating systems and ports on internal networks, not actually accessing those systems and ports. The CORS header (or lack thereof) in the HTTP response of the requested item is what dictates whether it can be accessed, so what happens is the request first sends a HEAD request to get the headers for the endpoint, and then if CORS is set up and allowed for cross-domain access is allows t…

That all makes sense, but the OP said that the scan didn’t identify their HTTP server. I wonder why.

Well, "Scanning localhost ... localhost complete." which they report means it found the sever, but did not allow access (CORS restricted). This is normal, as the default behavior unless modified by a CORS header is that cross-origin resource sharing is disallowed, and that includes same host but separate port. I believe edit is correct, in that this demonstration is for finding poorly configured local services that have a CORS header that is too open (perhaps because there are multiple services meant to interact with each other).

Re: I can see your local web servers

#178

Earlier quoted context omitted.

Whereas I'm learning that my network is fairly secure against this type of port scanning.

Of course, mine was too. I'm sure in part due to the diligent security team that will be stopping by my desk in the next few days!

Since I work from home I'm both the security team and the guy who inadvertently ran a port scanner in his web browser.

Re: I can see your local web servers

#180

Earlier quoted context omitted.

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…

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.
Post reply on HN