¿Seguridad del juego web a través de WebSockets?

3

El proyecto en el que estoy trabajando depende de WebSockets para comunicarse entre el servidor y el navegador del cliente para todas las interacciones dentro del juego. Asisto a la universidad para Seguridad Informática, pero todavía no estoy seguro de posibles ataques contra el sistema de validación actual.

Comenzaré muy rápido y diré que en este momento actual no puedo usar Secure WebSockets debido a que Autobahn ( still ) no es compatible con Secure WebSockets. Si tengo que cambiar el marco que estoy usando para resolver cualquier problema, lo haré.

Tal como funciona en este momento, al conectarse, el usuario solicita la clave pública del servidor (2048 bits) que se puede cambiar en un intervalo regular, el servidor entrega la clave pública al usuario. Para validar la clave, se envía al servidor un intercambio rápido de envío de una cadena conocida constante cifrada con la clave y el servidor verifica que la clave sea correcta para el usuario. Después de verificar la clave, el cliente cifra la contraseña de texto sin formato proporcionada por el usuario y la envía al servidor. El servidor descifra la contraseña, hace un hash de la contraseña con bcrypt y valida la contraseña de una manera resistente a los ataques de tiempo (no se produce una salida anticipada, casi el tiempo de ejecución es constante). El cifrado utiliza un nonce aleatorio como parte del relleno para evitar los ataques de repetición.

La parte de la que más sospecho es sobre cómo mi implementación actual "rastrea" qué socket pertenece a quién . Básicamente, si una solicitud de "inicio de sesión" es manejada por un socket y el resultado es positivo, entonces el "socket" recibe un "nombre" al establecer un atributo especial en el socket para el nombre de usuario proporcionado en la solicitud de inicio de sesión.

Al desconectarse, el socket se destruye y hay comprobaciones de inactividad para los sockets que no han recibido una solicitud en mucho tiempo para que se desconecte automáticamente. La única forma de establecer el atributo en un servidor de socket es realizar una solicitud de inicio de sesión exitosa.

Soy consciente de la posibilidad de ataque de MITM con respecto al intercambio de claves.

Mis preocupaciones son ¿cuáles son las fallas en este sistema y cómo debo prevenirlas o mitigarlas?

    
pregunta Seth M. Larson 06.01.2016 - 14:44
fuente

1 respuesta

2

Esencialmente, tiene una cadena equivalente de contraseña (la contraseña cifrada de clave pública), que está protegida por el requisito de que se envíe la cadena constante. Sin embargo, si se trata de una cadena constante, un atacante podría simplemente reproducir una llamada antigua; después de todo, puede obtener la clave (es pública). El nonce aleatorio también debe transferirse al cliente, o generarse en el cliente; de cualquier manera, como ocurre antes de la autorización, es probable que un atacante lo obtenga.

Podría valer la pena considerar la inclusión de algún tipo de token en todas las solicitudes, el desacoplamiento efectivo del socket específico de un usuario determinado y, por lo tanto, eludir su área principal de preocupación. Siempre que pueda probar que la solicitud proviene de un usuario autorizado específico. Esto también tiene la ventaja de permitir que los mismos procesos backend manejen métodos de inicio de sesión alternativos (por ejemplo, si agregó una API a su aplicación para el uso de aplicaciones móviles). Esto también garantiza que las sesiones de los usuarios puedan continuar durante un reinicio del proceso del lado del servidor: actualmente, por su sonido, los usuarios se desconectarán si tuviera que reiniciar el proceso del servidor, incluso si el reinicio del proceso fue momentáneo. Presumiblemente, las banderas en sockets específicos no se establecerían en este caso, sin un nuevo inicio de sesión.

    
respondido por el Matthew 06.01.2016 - 16:34
fuente

Lea otras preguntas en las etiquetas