Hacker News Reader

Comment by andix | Hacker News Reader

Running http(s) over TCP on localhost should not happen on any production application. This simply doesn’t properly work in a secure manner.

View on HN

Since browsers killed plug-ins, there's simply no alternative if a website needs to communicate with a locally-installed application.

Just don’t do it then. Either ship something electron based (or similar) with an embedded browser and IPC communication with the bundled „backend“, or communicate via a trusted server.

Listening on localhost is a security nightmare, also because it is accessible from other user accounts on the same machine. The server probably can do some privileged tasks (otherwise you wouldn’t need it) and could be hijacked by malware.

Just don't do it then? Great reply

No, really. Let's stick to the example online banking: If you need to install software to use it, why don't you just deliver an Electron (like) application, and host the whole banking application inside of the application? You get the additional benefit, that you can configure the security inside your applications browser as you wish, pin certificates to make MITM even less likely. Electron let's you ship native code too, comes with an auto updater, etc.

And there are numerous alternatives to Electron if you don't like to ship a full Chrome browser. It get's a bit more complicated then, but its possible, take a look at Tauri for example.

To be honest, I had multiple projects, where a http://localhost solution was proposed, and we found a better solution without it. It is very rarely the best thing to do.

I've usually seen user authentication required for the server running on localhost. Are there other issues you're aware of?

It is possible to secure that, sure. Another possibility is MITM. Because you usually don’t have HTTPS, there is no verification of the Server possible. If the server runs on an unprivileged port >1024, any other application on the same computer (even on another user account) could hijack that port.

If you use http://localhost, you need to authenticate both server and client. It can be done, but often it is not done properly. This authentication needs to be present on every request. And that’s tricky, because you would need to track every http-tcp-connection, and ask the server for authentication in the beginning of the connection. Once you open a TCP new connection, you would need to do that again. As far as I know, you can’t do that with JavaScript inside a browser.

Another preventable mistake is, that the server somehow gets accessible not only from localhost, but gets exposed to a public network interface somehow.

So all in all a lot of possible headaches, that can be prevented by choosing a different architecture.

There absolutely is, it's called native messaging hosts. It allows webextensions in your browser to talk to executables installed on your local machine. The locally-installed application simply needs to install their appropriate extension in your browser.

Yes, that was their first iteration. If you think that this went any better than communicating via a local web server, well… https://palant.info/2023/01/09/touchen-nxkey-the-keylogging-...

That isn't the fault of the native messaging host transport mechanism though. I'm just saying there are transport alternatives that are more secure than the Root CA installation nonsense the apps in your submission employ.

Neither are applications doing root CA installatin nonsense a fault of communication via a local web server. HTTPS isn’t required here, but they either have this hack in place for compatibility with decade old browsers – or they simply failed to revisit it.

This is absolutely not true. As I wrote to a different reply.

For about 5 years it is possible to call localhost from https page without any warning. Localhost is a secure context, exactly that you don't need to do this.

I cannot find the docs that says that, but... it is true. You can try that yourself.

W3C has it here https://w3c.github.io/webappsec-secure-contexts/#localhost

you can see in Chrome source code let's say here

https://source.chromium.org/chromium/chromium/src/+/main:thi...

Reply on news.ycombinator.com