Existen muchos tipos diferentes de vulnerabilidades de sitios web, uno de los cuales se llama «congelación de sesión». La congelación de sesiones es un problema en el que un atacante podría manipular el identificador de sesión (también conocido como ID de sesión de un usuario) y luego usarlo para obtener acceso a su cuenta. Hay dos formas en que este tipo de vulnerabilidad podría funcionar: El atacante podría encontrar o establecer el ID de sesión de otro usuario.
Cómo se realiza un ataque de congelación de sesión
El ID de sesión de un usuario es a menudo una parte integral de la autenticación del sitio web y, en muchos casos, es el único dato que identifica al usuario que ha iniciado sesión en particular. El problema con esto es que un atacante podría configurar o aprender el ID de sesión de otro usuario, y los usuarios podrían usar el token de sesión y luego actuar como un usuario.
Normalmente, esto hace que el usuario haga clic en algún tipo de enlace de phishing. El enlace en sí es perfectamente legítimo, pero contiene una variable que establece un ID de sesión específico. Si el usuario luego inicia sesión con el ID de sesión y el servidor no asigna un nuevo ID de sesión cuando inicia sesión, el atacante puede simplemente configurar su ID de sesión en el mismo y acceder a la cuenta de la víctima.
Otra forma en que el atacante puede determinar el ID de sesión de la víctima es mostrarlo en una URL. Por ejemplo, si el atacante puede convencer a la víctima de que le envíe un enlace que contenga la identificación de sesión de la víctima, el atacante podría usar la identificación de sesión para acceder a la cuenta de la víctima. En algunos casos, esto puede suceder de forma completamente aleatoria. Por ejemplo, si el usuario copia y pega la URL con el ID de sesión a un amigo o foro, cualquier usuario que siga el enlace iniciará sesión con la cuenta de usuario.
Correcciones para la congelación de la sesión
Hay varias soluciones a este problema. Como siempre, la mejor solución es implementar tantas correcciones como sea posible como parte de una estrategia de defensa integral. La primera solución es cambiar el ID de sesión del usuario cuando inicia sesión. Esto evita que un atacante influya en el ID de sesión de un usuario que inició sesión. También puede configurar el servidor para que solo acepte los ID de sesión que ha generado y para rechazar explícitamente los ID de sesión proporcionados por el usuario.
El sitio web debe configurarse de modo que los detalles confidenciales del usuario, como el ID de sesión, nunca se incluyan en la URL ni en un parámetro de solicitud GET o POST. Esto evita que el usuario comprometa accidentalmente su propia ID de sesión. Al utilizar un ID de sesión y un token de autenticación independiente, duplica la cantidad de información que el atacante necesita para evitar que accedan a sesiones con ID de sesión conocidos.
Es importante que cualquier ID de sesión válida para un usuario deje de ser válido cuando se hace clic en el botón de cierre de sesión. Es posible volver a generar el ID de sesión con cada solicitud. Si los ID de sesión anteriores no son válidos, también evitará que los atacantes utilicen el ID de sesión conocido. Este enfoque también reduce en gran medida la ventana de amenaza cuando un usuario revela su propia ID de sesión.
Habilitar más de estos enfoques puede eliminar este problema como un riesgo de seguridad a través de una estrategia de defensa en profundidad.
