There are legitimate reasons for port scanning, but I'm not sure most websites out there are using it for noble purposes.
I guess browsers could allow it based on explicit permission from the user, just like it's already done for microphone and camera.
Port scanning from a user’s browser is effectively sneaking behind a user’s firewall. The only legitimate reasons I can envision are security research, and this, to me, is such a small edge case that I’m not sure such access is ever warranted.
I’d be all for a user notification that says “fnord.com wants to access 192.168.0.10 on tcp/443, which seems to be a web server on your home/work network. Are you sure you want to allow this?” I’d want to see this for each new access request, such that port scanning would not be a use case that was supported.
Sure, have an about:config toggle to shut this off, with appropriate warnings.
Yea this is very surprising.
I run a file server in my local network. There is no access control on it because it’s behind my router’s firewall, but everyone in the LAN can access it.
I find it very surprising that now any random website can access it with no oversight.
Why worry about spectre and meltdown when such blatant backdoors are implemented in browsers?!
Does your file server speak HTTP? If so you might have a problem. If not, it sounds like it's inaccessible to this attack, except to discover that it exists.
I'm curious, what would be a good reason to do this? I'm not creative enough to think of anything this enables a site to do that isn't malicious. If I'm running a service on localhost, and that service needs to communicate with the site I'm browsing, surely I could just direct that service to communicate with the site itself.
For instance, if I'm running a local chat application and need it to communicate with the web version, why does the website need to be able to port scan to accomplish this? I can think of other ways to accomplish this that are a lot more secure.
Ubiquiti routers have a fairly magical browser SPA that can run on their domain and talk to local routers. It involves webrtc connections to local addresses.
But I think if same-origin were enforced more strictly, they could have found another way.
It does this most of the time, either through the cloud or direct to the controller. But during setup of the first device on a network it does something direct from the browser to get it connected to the cloud.
I'm not defending this use case, but one example I can think of is that Spotify runs a local server so that websites you access can control it, e.g. if you are on Billboard looking at top music charts, clicking on a song could start the song in Spotify, and even embed a player in the web browser, without you needing to be signed into Spotify in your browser.
This might be banks trying to detect compromised users. Many "tech support" scams aim to get remote desktop access to users PC's and then have them log in to their bank while scammers are connected. I could see how banks looking for remote access software could be a useful heuristic in fighting this problem.
Your bot is running a redis server locally, it allows local connections, because it's just a bot, boom.
Taking it a bit further, if we have really smart people involved: the timing of the attempted connections/rejections tell you something about the system that you can use to detect bots/scrapers.
Another example of this being used in the past is to scan for chrome extensions that scrape site content as well. I believe LinkedIn might have gotten hit hard for trying something similar but they were using extension URLs not localhost. Some extensions do spin up localhost services though.
IRC servers don't run in a browser. Instead they scan ports from the outside, which is not a problem. Anything they find is open to the entire internet anyway.
You run a network, and want to run a security audit. You need to know what devices are operating on it, and what services they are offering.
I don't get upset if someone opens and closes a socket to my VPS to see if something's there. My VPS is exposed to the internet. If a socket opens, it should be secure anyways. There's the chance nginx has an unknown zero day, but if I wanted to avoid that, I'd firewall it.
Things are a little less nice if you open a socket and start sending data to see what's there, assuming the server doesn't respond with a banner.
That might be a reason for you to port scan your network.
It is not a reason for your website to port scan my network. Especially since your website running inside my browser is inside my firewall.
> and want to run a security audit
Then you use tools designed to run security audits. You don't open a huge security hole in everybody's browser just so you can use a browser to run a security audit.
But that's a very different use case than having a website you visit portscan your computer (which I believe is what the user above you is referring to.
There's really no legitimate reason for eBay, or any other website, to portscan your computer. There's nothing there needed for browsing their website.
What about port scanning your service before you've secured it during development? At some point we have to be able to trust the network we're on. It's ludicrous to expect everything to be configured correctly and securely right from the start especially if you're developing the thing being scanned while it's being scanned. I'd much rather websites not be able to scan my home or office network than have to treat that network like I treat the Internet.
> I don't get upset if someone opens and closes a socket to my VPS to see if something's there. My VPS is exposed to the internet.
That's not what's happening here.
My laptop is not exposed to the public internet because it's behind a firewall / NAT. This is like going to my house, plugging a device into an Ethernet port on my router, and scanning my internal network from inside my network.
Except instead of them planting a device, all they have to do is get you to navigate to their webpage. They're getting your laptop to do the port scanning for them, and in so doing, they get access to your internal network. The problem isn't port scanning, the problem is NAT busting.
