I can see your local web servers - http://http.jameshfisher.com/2019/...

This article pisses me off so much.

Can someone tell me what's the deal with websites being able to access localhost:3000?

Newsflash, jamesfisher.com:80 is open to everyone on the internetworkz!!1!1!!

JavaScript accessing resources in the 192.168.x.x ranges and 127.0.0.01 with known typical ports.
By these requests returning 200 status, a site could identify an internal Webserver running.

People assume that if something is running on their local webserver, then it's not available for anyone else. That's not true, a malicious website can access these and for example forward them to its server.

Maybe you have a sql server or another resource bound to a localhost port that your website requires. Those resources should not be directly available to the internet, yet a webpage with the right js code could access those resources.

Eg:
<public_ip>:80 - public website
localhost:1433 - backend sql server

The webpage should never be able to access the sql server, and yet it can. That's a massive vulnerability.
Thanks, javascript!

@endor As far as I understand it only works for HTTP. Maybe you could detect other services' presence, but AFAIK there are no web APIs that let you directly talk to sockets (except for websockets, but they were designed with this in mind and require a handshake). So you can't dump a local SQL server.

@gronostaj
I'm pretty sure you can connect to a mysql database with JavaScript.

Create a connection over 127.0.0.1:3306 root without pass (local environments wouldn't normally have a password unless the dev is wise)
Export a dump back and then push it back to visiting websites backend.

🤔 this is almost worth setting up a actual test for.

@C0D4 Since when does JS support raw sockets?

What if I told you a some legitimate applications work that way?

To login with the German eID a request is sent to 127.0.0.1:.. where the background service is running and is connected to the smart card reader.

@sbiewald
A quick search leads me to chrome apps being able to create a socket connection.

https://developer.chrome.com/apps/...

@C0D4 Interesting.
I'm glad it's just for chrome apps (not even addons) and not 'random' JavaScript on websites.

@sbiewald yea, luckily for now.

It's got me interested, Digging the internets for a feasible example a random website could actually use.

@C0D4 It would be funny (and scary,l if a website could connect directly on arbitrary ports to arbitrary machines, possibly bypassing firewalls sending, performing a vulnerability scan and automatically drop malware on vulnerable machines...

By the way: While an application can detect a running webserver, it might not get any data back from those, as the 'same origin policy' prevents that (unless explicitly disabled).

@sbiewald mysql has a http client for 5.7...
I mean if someone was stupid enough to add that, you could potentially generate ajax requests hitting a local host and have mysql be a good boy and output data.

http://blog.ulf-wendel.de/downloads...

I can't find an offical link to it but this seems to cover it extensively.

What do you have local there which has the importance but wouldn't have the security it'd have live?
Or the other way around: which donkeyass would have a copy of live data in there?

😂😂😂, the article smells like and is full of bullshit. I visited it twice on my iPhone and this is what I got

Also, he’s going on about how port 3000 on local host is insecure, Newsflash kid... your “site” is not served over a HTTPS connection, so his article is null and void.

I'm loling right now at everyone saying this is not a real thing. Have fun in the dark where you feel safe.

@err-occured By following your logic: if someone's fat, they can't say that fastfoods are unhealthy.

@watzon we're not in the dark

we're just not idiots xD

@Parzi then you should know that this is a real thing. It's a confirmed exploit. You can look up "driveby pharming" on Google for more info.

@watzon don't preach to the choir, is all i'm sayung. Most of us aren't running shit on localhost unsecured.

@Parzi Really? How do you think people are testing their Angular/React/Vue/newFancyFramework apps?

@gronostaj without sensitive data?

@Parzi Yeah, because of course people never develop with a copy of production DB :P Also, if you're working on a commercial app, you probably don't want to leak the source before it's released.

That's a quite well known attack vector, forcing the client to access its own resources for you. Another example of this is embedding xss in a request and hoping some admin opens those logs in a vurnerable web gui.

@sbiewald there's a loooooong way from being able to ping an IP to dropping files on that machine. If it was that easy you could attack any web server in the world

@gronostaj WHO THE FUCK TESTS WITH THE PROD DB (or a copy of one)

THAT'S JUST ASKING FOR LEAKS

@Froot they're called "script kiddies", or "skidmarks", if you will.

@Parzi the point is that it can see machines on your local network as well. So if you're working from the same network as your servers, you're screwed anyway, even if your pc has nothing running on it

@endor still wouldn't be localhost tho xD

Does the above page works for anyone? There are several device in my house which have port 80 open (for example, my router). But it does not detect it.

Anyway, a lot of damage can be prevented when the browser properly implements same origin policy and the server side properly implements CORS (for example, a home router's AJAX login request should not place a header to allow every Origin).

At first this might seem bad, but it is just how browsers SHOULD work. There are a lot of options to prevent any actual abuse, only under the worst of circumstances something bad MIGHT happen.

But yeah, the website is a little bit bullshit. A few years a W3C working group started a proposal for a protocol to detect devices in the network. Opera implemented this in a nightly build I think. But in the end it never became a standard (which might have compromised security, however some cool ideas came to mind back then).

@Hel8y The page could only work in the following cases:
- Server sets improper CORS headers, allowing access
- By timing requests: While an evil webpage cannot get contents from a third website -- because of the same origin policy -- it can still get timing.

@sbiewald The page online doesn't use timing, does it? I just checked my router and it does not seem to set any CORS headers.

Wouldn't timing not only allow for scanning open ports serving HTTP, but basically allows you to scan if "something" rejects your packets? A firewall rejecting packets or an open port closing the connection because it does not speak the HTTP protocol would reply faster than a timeout.

@Hel8y Yes, theoretically, but I'm not sure if you can differentiate between:
- Closed port (connection closed with RST)
- Open port
- Firewall drop (leading to timeout)

The website just tried to connect and goes to the next target if there is any timeout.

Not setting CORS headers is fine, in the case you didn't know.

@sbiewald I think you can detect an online IPs if the timeout is not reached. In all other cases the IPs are offline or dropping packets.

Yeah, skipping CORS is fine as long as you doing a "safe" request. I read the W3C standard front to back a while ago because I couldn't figure out why some requests were not working. Turned out to be some IE specific bug related to some headers which should have been accepted by default.

(Note sure which, but I think it was the Origin header itself which had to be added to the allowed request headers. All other browsers seemed to be fine with this. I'm not sure anymore what the specifications said about the Origin header, but I assume it is the safe header list).