¿Puedo confiar en un Id. de sesión para que sea único?

Aunque hay una respuesta aceptada aquí, es algo engañoso.

  

¿Puedo confiar en un ID de sesión para unicidad?

Si la unicidad es la única restricción, entonces la respuesta corta es sí. Si usted es Facebook o Google, entonces la debida diligencia requeriría que se tome un tiempo para evaluar la probabilidad de colisiones en función del algoritmo y la arquitectura de la aplicación. Para las aplicaciones en las que la base de usuarios concurrentes sea inferior a un millón, el método implementado en plataformas comunes debería ser suficiente.

Sin embargo, la singularidad solo aborda la funcionalidad del sistema. Desde un punto de vista de seguridad, debe asegurarse de que el ID de sesión no sea predecible, es decir,

• que no se puede inferir de los datos disponibles; md5(CLIENT_IP) sería una mala identificación de sesión

• que intentar adivinar con fuerza bruta la identificación de la sesión es difícil; next_session_id=last_session_id+1 sería una mala elección

Si realmente debe implementar su propia generación de ID de sesión, use un buen generador de números aleatorios. Observe el tamaño de los identificadores de sesión que está generando su sistema actual y apunte al menos a ese tamaño en su implementación.

user52472 dijo:

  

El almacenamiento de tokens de sesión en la base de datos podría permitir a un atacante hacerse pasar por otros usuarios si puede obtener acceso a estos tokens a través de un ataque de inyección SQL

Dado que todo el punto de las sesiones del lado del servidor se basa en el almacenamiento del lado del servidor, esto se puede definir mejor como:

El almacenamiento de tokens de sesión en el servidor podría permitir a un atacante secuestrar sesiones si es capaz de inyectar código que lee el almacenamiento

.... aunque la naturaleza de SQL es tal que generalmente es el resultado de la inyección de código.

Una solución es no almacenar los datos de la sesión en comparación con el ID de sesión, sino una representación transformada de ellos (por ejemplo, sha1 (session_id + salt)), pero esto solo proporciona beneficios limitados: si la sal y el mecanismo están expuestos, el mecanismo es inefectivo OTOH esto se traduce fácilmente a otros sustratos de almacenamiento.

Si las sesiones se almacenan en una base de datos relacional, entonces es posible protegerlas contra la enumeración mediante la inyección de código al no permitir el acceso directo a la tabla subyacente a la cuenta utilizada por la aplicación. clave (id de sesión) suministrada como un argumento a una función almacenada con separación de privilegios.

Estás en lo correcto, el sitio antiguo es el enlace más débil. Veo dos posibles debilidades:

1. El token de sesión no es criptográficamente aleatorio.
2. El almacenamiento de tokens de sesión en la base de datos podría permitir a un atacante hacerse pasar por otros usuarios si puede obtener acceso a estos tokens a través de un ataque de inyección SQL.

Para el primero, se trata de obtener un número aleatorio seguro criptográficamente y de asegurarse de que tenga suficientes bits. No estoy muy familiarizado con el ASP clásico, por lo que no podría decirle la mejor manera de lograrlo.

Para el segundo, recomendaría dejar que el marco gestione toda la gestión de la sesión cada vez que pueda quitar el servicio del sitio anterior. Esto también solucionaría el primer problema.