Si utilizo un socket Python en localhost, ¿hay algún problema de seguridad que deba tener en cuenta?

Question

Si utilizo un socket Python en localhost, ¿hay algún problema de seguridad que deba tener en cuenta?

#1 de CBHacking (1 votos)

1

Estoy implementando un simple socket en Python para transferir datos entre dos scripts que se ejecutan en La misma máquina (desafortunadamente, un socket es la única configuración posible para mi situación).

Estos datos, en muchos casos, serán muy confidenciales (es decir, números personales de tarjetas de crédito).

¿El hecho de pasar los datos entre scripts de esta forma me abre cualquier problema de seguridad?

lado del servidor:

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
        break

lado del cliente:

import socket

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

Fuente de código.

webserver python server tcp websocket

pregunta user1318135 25.10.2017 - 18:14

fuente

1 respuesta

Lea otras preguntas en las etiquetas webserver python server tcp websocket

¿Es posible CSRF contra una descarga de PDF que requiere autenticación de cookies? Proxychains no funciona, la prueba de fugas de DNS muestra la ubicación

score 1 · Answer 1

Esto es completamente inseguro en los escenarios local-máquina multiusuario . Por ejemplo, suponga que su sistema se ejecuta en un cuadro de Windows que está unido a un dominio y permite a cualquier miembro del dominio para iniciar sesión en la máquina, o una red de Linux que permita a otras personas ingresar a SSH (ambas configuraciones son comunes en los entornos corporativos). Incluso sin administrador / acceso de root , cualquier persona que pueda ejecutar código en la máquina puede abrir su propio escucha de socket en el puerto 8089 si el oyente "oficial" no se está ejecutando, o puede enviar tráfico al oyente oficial Si el cliente no está utilizando todas las ranuras de conexión. Cualquiera de estos escenarios abre el sistema para comprometer el tráfico de la red.

Un atacante de red local también puede intentar comprometer al cliente o al servidor, estrellándolos (lo que puede hacer que se paren en su lugar, incluso con solo un fallo) o incluso obtener una ejecución de código como la cuenta de servicio ( por ejemplo, si una parte tiene una vulnerabilidad de inyección de comando). Esto podría potencialmente permitir que el atacante no solo robe la información que el servicio debe manejar, sino que también obtenga acceso a otras áreas restringidas mientras enmascara quién está accediendo realmente al sistema.

El enfoque correcto aquí es utilizar un mecanismo de IPC seguro, uno que permita controles de acceso y proporcione confidencialidad a la conexión. Los dos más cercanos a los sockets TCP de bucle invertido son los sockets de dominio Unix (local) en sistemas basados en * nix, y tuberías con nombre de Windows en sistemas basados en Windows. Muchas bibliotecas y marcos basados en sockets ya son compatibles con estos, por ejemplo, el módulo server de Node se complace en escuchar en un socket local o canalización con nombre, por lo que podría ser un cambio más fácil de lo que está esperando. También puede cambiar a una conexión SSL / TLS que admita la autenticación mutua cliente-servidor, como el uso de un certificado de cliente o una clave precompartida (y, por supuesto, validar que el certificado del servidor es aquel al que solo tiene acceso el proceso del servidor legítimo). ), pero es probable que sea un cambio más complicado en el que sea más fácil equivocarse, en comparación con el uso de un canal de comunicación que fue diseñado desde el principio para la seguridad.