←back to thread

I can see your local web servers

(http.jameshfisher.com)
652 points jamesfisher | 1 comments | | HN request time: 0.214s | source
Show context
founderling ◴[] No.20028376[source]
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 pointing to localhost and detects if those error out.

replies(5): >>20028381 #>>20028422 #>>20028443 #>>20034079 #>>20036964 #
jensneuse ◴[] No.20028422[source]
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.
replies(2): >>20028925 #>>20029142 #
dillonmckay ◴[] No.20029142[source]
Hmmm...

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

I may be missing something.

replies(1): >>20034407 #
kbenson ◴[] No.20034407[source]
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 the connection (or if it's a request to the same domain and CORS for the current page isn't too restrictive, it allows the initial request without a HEAD request).

What you see in the browser developer tools if you open them up is that a bunch of requests are being made, but are being denied because they are failing CORS checks.

Where data is being leaked (in context of security) is that there's a difference in how the responses are handled. Either it's allowed (because the remote side CORS is too loose) in which case the page will show s message that the specific host/port combi is available, or it will get no response and time out, in which case they skip checking that host any more and assume there's nothing at that IP (which is when they print the "unreachable" message), or it continues on with the next port. If at the end there's been no success and no timeout, it prints the "complete" message, and that means there's probably something at that IP.

An important thing to note is that CORS is not like a firewall, and it doesn't actually stop all traffic from happening, so that can sometimes be used to get additional information that's not necessarily meant to be exposed. That said, what the page is showing is that the specific way CORS functions (that is, asking the remote side if they accesible), and the fact that Javascript runs locally on your browser, means that there's some interesting ways those interact which can cause security concerns.

A as idea of how this could be used to more nefarious ends, if it found listening and accessible servers on localhost or the local network, it could then try to identify them based on the headers/content returned, and try to do something with that.

Given that you could possibly even compile some network vulnerability scanner/exploiter to WASM and use it for only the subset of vulnerabilities it could accomplish through plain HTTP requests (a lot of work, it's probably easier to just write your own shim and crib their exploit library), this could be very easily weaponized.

replies(1): >>20035393 #
comex ◴[] No.20035393[source]
That all makes sense, but the OP said that the scan didn’t identify their HTTP server. I wonder why.
replies(1): >>20035639 #
1. kbenson ◴[] No.20035639[source]
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).