¿La capacidad de un usuario para elegir el valor de una cookie de identificación de sesión constituye un defecto de seguridad?

Sí, existe un riesgo ya que se trata de un problema clásico de reparación de sesión ( Página OWASP ). Una buena práctica estándar para la administración de sesiones de aplicaciones web siempre sería volver a emitir un token de sesión aleatoria cada vez que el usuario envíe un inicio de sesión. Cualquier otra cosa (no volver a emitir al iniciar sesión o permitir que el usuario configure los valores del token de sesión) no es una buena idea.

La cantidad de un problema depende de cómo funciona exactamente la aplicación y del entorno del usuario. Algunos ejemplos de esto es un riesgo

• Muchos sitios web tienen áreas no autenticadas que no están cifradas. por lo tanto, si el token se establece en estos y luego no se vuelve a activar, el token puede ser secuestrado por un ataque de rastreo de paquetes (por ejemplo, a través de una red inalámbrica) antes de que el usuario inicie sesión y luego la sesión autenticada pueda ser secuestrada

• Si se accede a la aplicación desde un entorno de PC compartido, entonces un atacante que puede establecer el valor del token en un navegador abierto, podría secuestrar una sesión de usuarios si usa el sistema sin cerrar y volver a abrir el navegador (asumiendo que el token se elimina cuando se cierra el navegador).

Este es un problema de seguridad, pero no puede hacer nada al respecto, ya que el cliente siempre puede establecer cualquier ID de sesión que desee. Si no hay una sesión del lado del servidor con ese ID, es probable que el usuario vea un mensaje de sesión caducada y se vea obligado a autenticarse.

Si un atacante puede obtener el ID de sesión de los usuarios legítimos, existe la posibilidad de un secuestro de sesión configurando el mismo ID de sesión en el navegador de atacantes y navegando al sitio en cuestión.

HTTPS va de alguna manera hacia la prevención de este tipo de ataque al detener a un hombre en el medio del robo de la ID de la sesión.

Hay otros métodos mediante los cuales un atacante puede obtener un ID de sesión de las víctimas, como un ataque de scripts entre sitios en aplicaciones web vulnerables. En una aplicación de este tipo, es trivial engañar a la víctima para que abra una página que pueda ejecutar algún javascript proporcionado por el atacante que les envíe el ID de sesión y les permita asumir su identidad con ese servicio.

No me preocupa que un hacker tenga la capacidad de configurar el ID de sesión antes de iniciar sesión, ya que cuando la víctima se autentica con la aplicación web, la respuesta establecerá un nuevo ID de sesión proporcionado por el servidor.

La mayoría de las aplicaciones web en estos días también contienen medidas secundarias para evitar el secuestro de la sesión a través de otras cookies que contienen sumas de comprobación con información específica de la máquina que se encuentra en ellas. Los sitios como Facebook le permiten especificar una lista de dispositivos seguros para evitar este tipo de ataques.