¿Es posible el secuestro de sesión a través de sessionId?

  

¿Es posible el secuestro de la sesión a través de sessionId?

Probablemente no.

owasp dice que un identificador de sesión debe tener al menos 128 bits de longitud para evitar el forzoso de sesión. Dan estos cálculos de ejemplo:

  

Con un identificador de sesión de 64 bits, suponga 32 bits de entropía. Para   sitio web grande, suponga que el atacante puede probar 1,000 conjeturas por   segundo y que hay 10.000 identificadores de sesión válidos en cualquier   momento dado Dados estos supuestos, el tiempo esperado para un   atacante para adivinar con éxito un identificador de sesión válido es menor que   4 minutos.

     

Ahora asuma un identificador de sesión de 128 bits que proporciona 64 bits de   entropía Con un sitio web muy grande, un atacante podría probar 10,000   adivina por segundo con 100,000 identificadores de sesión válidos disponibles para   ser adivinado Dados estos supuestos, el tiempo esperado para un atacante   adivinar con éxito un identificador de sesión válido es mayor que 292   años.

Incluso si asumimos que un atacante puede realizar 10 millones de intentos por segundo, aún les tomaría 3 meses obtener una identificación válida en el último ejemplo dado.

El ID de sesión de PHP , por ejemplo, parece ser 160 bits por defecto (creo que la documentación no es tan buena), también puede establecer usted mismo .

  

¿Cómo puedo, como desarrollador de una aplicación, evitar esto?

Además de usar una ID lo suficientemente fuerte, también puede vincular una sesión a una IP, o vincularla a una sesión TLS , de esa manera, incluso si un atacante obtiene la sesión (a través de fuerza bruta o de otra forma), no pueden usarla. Y también podría bloquear las direcciones IP que utilizan demasiados intentos con ID de sesión no válidas.

La respuesta de tim sobre la entropía es perfecta en el tema de la fuerza bruta que obliga a sessionId.

Pero nota, hay formas más fáciles de robar la sesión. Por ejemplo, si emite la sesión a través de HTTPS (autenticación) pero luego se recupera a HTTP, ahora su sesión se expone en texto claro. Cualquier cosa que pase por HTTP se puede asumir que se grita en voz alta y abierta para todos los que están escuchando en la línea.

Un ataque dirigido puede engañar a un usuario para que haga clic en una URL HTTP al sitio web de destino y al intruso del atacante hasta que el usuario haga clic en la URL y envíe la sesión a través de HTTP. es por eso que debe establecer un indicador de seguridad para su sesión para asegurarse de que no se envíe a menos que esté a través de HTTPS.

Puede vincular la sesión a IP, pero tenga en cuenta que muchos usuarios pueden compartir la misma IP si están detrás de un NAT. Entonces no es realmente una gran solución de seguridad.

Incluso si tiene su sesión completa sobre SSL, aún las vulnerabilidades en el navegador pueden permitir el robo de la sesión; Los scripts de sitios cruzados pueden robar la sesión. Para estar seguro, debe solucionar todos estos problemas, pero al final del día, suponga que la sesión puede ser robada, y piense ahora qué?

Una solución avanzada para el secuestro de sesiones es el token de sincronización; de esta manera, cada vez que el navegador del cliente realiza una solicitud HTTP al servidor, el servidor envía un nuevo token suficientemente complejo al cliente como un valor de campo de formulario oculto, y el cliente debe enviar este valor en la siguiente solicitud como un forma oculta del valor. Si el cliente envía la sesión correcta (por ejemplo, robada de la cookie), pero no tiene el token de sincronización más reciente, entonces hay algo incorrecto. Esta solución también previene la falsificación de solicitudes entre sitios. Si tiene SSL, esta solución tampoco puede ser interrumpida por el hombre en el medio.