5 ms·

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 communica

by andix 4y ago

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.

trallnag 4y ago
Just don't do it then? Great reply
- andix 4y ago
  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 http://localhost solution was proposed, and we found a better solution without it. It is very rarely the best thing to do.
8organicbits 4y ago
I've usually seen user authentication required for the server running on localhost. Are there other issues you're aware of?
- andix 4y ago
  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 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.

by andix 4y ago

trallnag 4y ago

Just don't do it then? Great reply

andix 4y ago
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 http://localhost solution was proposed, and we found a better solution without it. It is very rarely the best thing to do.

8organicbits 4y ago

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

andix 4y ago
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 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.