I am implementing a simple socket in Python to pass data back and forth between two scripts running on the same machine (unfortunately, a socket is the only possible setup for my situation).

This data, in many cases, will be highly sensitive (i.e. personal credit card numbers).

Does passing the data between scripts in this way open me up to any security concerns?

Server side:

import socket

serversocket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
serversocket.bind(('localhost', 8089))
serversocket.listen(5) # become a server socket, maximum 5 connections

while True:
    connection, address = serversocket.accept()
    buf = connection.recv(64)
    if len(buf) > 0:
        print buf

Client side:

import socket

clientsocket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
clientsocket.connect(('localhost', 8089))

Code source.

  • If you're on a *nix system I'd use unix sockets and make the file permission as restrictive as possible. Why is this the only possible setup? – AndrolGenhald Oct 25 '17 at 16:28
  • It needs to run on Windows 7 as well. There's a better discussion on the Python mailing list, but that's not linkable. You can, in part, see the reasons in the comments to this answer: stackoverflow.com/a/46802154/1318135 – user1318135 Oct 25 '17 at 16:33
  • The two scripts will always run on the same machine to exchange data or do you expect them to run over network – Ubaidah Oct 25 '17 at 18:53
  • 1
    The problem is, that each user and thus process could connect to these sockets, if you do not add authentication and encryption. This is why @AndrolGenhald suggested to use sockets. – cornelinux Oct 25 '17 at 19:25
  • 1
    I would use the address form or ::1 which is required to be handled locally and not sent out; the name form localhost should do this but people sometimes change it (and sometimes even have arguably sane reasons to). – dave_thompson_085 Oct 26 '17 at 5:38

This is completely insecure in local-machine multi-user scenarios. For example, suppose your system runs on a Windows box that is domain-joined and allows any member of the domain to log into the machine, or a Linux network that allows other people to SSH in (both configurations are common in corporate environments). Even without admin/root access, anybody who can run code on the machine can open their own socket listener on port 8089 if the "official" listener isn't running, or can send traffic to the official listener if the client isn't using up all the connection slots. Either of these scenarios opens the system up to compromise of the network traffic.

A local network attacker can also attempt to compromise the client or server, crashing them (which may then let them stand up their own in its place, even with just a crash) or possibly even gaining code execution as the service account (for example, if one part has a command injection vulnerability). This could potentially enable the attacker to not only steal the information the service is meant to handle, but also gain access to other restricted areas while masking who is actually accessing the system.

The correct approach here is to use a secure IPC mechanism, one that allows access controls and provides connection confidentiality. The two that are closest to loopback TCP sockets are Unix domain (local) sockets on *nix-based systems, and Windows named pipes on Windows-based systems. Many socket-based libraries and frameworks already support these - for example, Node's server module is perfectly happy to listen on a local socket or named pipe - so it might be an easier change than you're expecting. You could also switch to a SSL/TLS connection that supports mutual client-server auth, such as using a client certificate or a pre-shared key (and of course validating that the server certificate is one that only the legitimate server process has access to), but that's likely a more complicated change that is easier to get wrong, compared to using a communication channel that was designed from the start for security.

  • as soon as you mentioned "Windows box" it become clear it is insecure – Ubaidah Oct 28 '17 at 13:32
  • ... or a Linux network that allows other people to SSH in. Your blind open-source zealotry and lack of reading comprehension say some unfortunate things about you, @Ubaidah. Go troll somewhere else more suited to your level of "discourse", OK? – CBHacking Oct 29 '17 at 17:49
  • I am very sorry I did not mean to offend you in any way. In fact, I like your answer that is why I added a comment. – Ubaidah Oct 30 '17 at 16:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.