3 ms·

Localhost is typically uniquely trusted, generally speaking, even when loading a localhost page on HTTP it behaves like a page served over HTTPS would (in terms

by ghxst 2y ago

Localhost is typically uniquely trusted, generally speaking, even when loading a localhost page on HTTP it behaves like a page served over HTTPS would (in terms of the browser APIs you have access to for example). Also for a port scan it's not all that unusual since you can do it without loading any resources, so CORS alone wouldn't protect you from it. Maybe an extension that injects / modifies CSP rules could protect from this but it might also end up breaking websites.

lxgr 2y ago
> it might also end up breaking websites That's what I was trying to get at: Are any websites using this legitimately to communicate with local applications? If so, isn't that a pretty big fingerprinting and attack vector (how are websites authenticating themselves to these local applications and vice versa)?
- ghxst 2y ago
  Potentially? Typically nowadays if you have some application on the host and a browser component (like a password manager) you would use a native messaging host and extension. There's also deep links / intents type communication. But if neither of those fit your use case I guess you would be able to have something running on localhost, maybe for something like an FTP server it would be more common. The ports that these scripts typically scan are those of known automation tools as well as malware, example is port 9222 for Chrome Devtools Protocol. Edit: Also any local network equipment probably uses local ips a lot, they often have web UIs that have legitimate use cases for this.
0x457 2y ago
> Localhost is typically uniquely trusted, generally speaking, Sure, but that trust is about me, an owner of this particular localhost, interacting with it, not trust some.website.on.web to have an unchecked communication with it.
- ghxst 2y ago
  I should probably have rephrased it a little, I don't disagree with you at all, was just adding more context on localhost and some of the nuances with it when it comes to browser behavior.

by ghxst 2y ago

lxgr 2y ago

> it might also end up breaking websites That's what I was trying to get at: Are any websites using this legitimately to communicate with local applications? If so, isn't that a pretty big fingerprinting and attack vector (how are websites authenticating themselves to these local applications and vice versa)?

ghxst 2y ago
Potentially? Typically nowadays if you have some application on the host and a browser component (like a password manager) you would use a native messaging host and extension. There's also deep links / intents type communication. But if neither of those fit your use case I guess you would be able to have something running on localhost, maybe for something like an FTP server it would be more common. The ports that these scripts typically scan are those of known automation tools as well as malware, example is port 9222 for Chrome Devtools Protocol. Edit: Also any local network equipment probably uses local ips a lot, they often have web UIs that have legitimate use cases for this.

0x457 2y ago

> Localhost is typically uniquely trusted, generally speaking, Sure, but that trust is about me, an owner of this particular localhost, interacting with it, not trust some.website.on.web to have an unchecked communication with it.

ghxst 2y ago
I should probably have rephrased it a little, I don't disagree with you at all, was just adding more context on localhost and some of the nuances with it when it comes to browser behavior.