4 ms·

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

by andix 4y ago

ronsor 4y ago
Since browsers killed plug-ins, there's simply no alternative if a website needs to communicate with a locally-installed application.
- 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.
- xnyanta 4y ago
  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.
  - palant 4y ago
    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-anti-keylogger-solution/#abusing-touchen-extension-to-attack-banking-websites https://palant.info/2023/01/09/touchen-nxkey-the-keylogging-...
    - xnyanta 4y ago
      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.
      - palant 4y ago
        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.
- shp0ngle 4y ago
  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 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:third_party/blink/web_tests/http/tests/security/secureContexts/localhost.html?q=localhost&ss=chromium https://source.chromium.org/chromium/chromium/src/+/main:thi...

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

by andix 4y ago

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

ronsor 4y ago

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

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.
xnyanta 4y ago
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.
- palant 4y ago
  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-anti-keylogger-solution/#abusing-touchen-extension-to-attack-banking-websites https://palant.info/2023/01/09/touchen-nxkey-the-keylogging-...
  - xnyanta 4y ago
    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.
    - palant 4y ago
      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.
shp0ngle 4y ago
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 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:third_party/blink/web_tests/http/tests/security/secureContexts/localhost.html?q=localhost&ss=chromium https://source.chromium.org/chromium/chromium/src/+/main:thi...