El protocolo HTTP fue diseñado para cumplir unos requisitos muy limitados, sin tener en cuenta muchas de las necesidades de la actualidad; por ejemplo, el protocolo no es capaz inicialmente de proporcionar o restringir visibilidad sobre sus recursos dependiendo de qué usuario los solicite.
Cuando un usuario accede a un servidor web éste realiza el saludo a tres bandas, solicita un recurso al servidor mediante HTTP, el servidor le devuelve el recurso solicitado y se cierra la conexión, por lo que si pinchamos en un enlace de la web, el servidor lo vería como una petición nueva y desconocerá que somos el mismo usuario. Por ello fue necesaria la creación del concepto de sesión, de tal forma que el servidor web sepa que somos el mismo usuario y en función de la sesión, proporcione visibilidad sobre unos recursos y con un determinado formato.
Esta sesión es un valor que debe ser aleatorio, difícil de adivinar y con una caducidad temporal. Normalmente la sesión irácomo parámetro de la URL, en las cookies o en métodos POST; la sesión será generada y proporcionada por el servidor, mientras que el cliente web tendrá la obligación de añadir la sesión en sus peticiones para que el servidor tenga constancia de quién está realizando la solicitud. Por ejemplo, imagínese que usted se autentica en su webmail de tal forma que se le permita leer su correo electrónico y por algún tipo de vulnerabilidad, por ejemplo un XSS, alguien tiene acceso a su sesión. Este atacante podrá tener las mismas funcionalidades en el recurso web que tiene usted. Su usuario y contraseña solo le sirvieron para indicarle al servidor Web que conceda a su sesión visibilidad sobre su correo.
Por ello existen multitud de posibles vectores de ataque para que un potencial atacante intente obtener su sesión y, por tanto, sea capaz de suplantar a su usuario; principalmente estos se centran en los siguientes tres tipos:
1. Sesión predecible.. Si la generación de la sesión no es aleatoria un atacante puede predecirla y suplantar al usuario.
2. Lectura de la sesión. La sesión puede ser accedida cuando hay alguna vulnerabilidad en la aplicación web, como un cross site scripting, o por emplear protocolos sin cifrado en entornos donde un potencial atacante podría leer el tráfico de red. Así se entiende el riesgo que supone acceder a un recurso web donde el proceso de autenticación es cifrado (HTTPS), pero una vez autenticados, navegamos sin cifrar (HTTP) y por tanto nuestra sesión también lo hace en texto en claro.
3. Fijación de sesión. Si una aplicación web, sin estar autenticados en el entorno, nos concede un identificador de sesión, y al autenticarnos el valor de esta sesión no cambia, estaremos ante una vulnerabilidad de fijación de sesión.
En la siguiente entrada documentaremos con mayor extensión cómo funciona la fijación de sesión, proporcionando una prueba de concepto real sobre esta vulnerabilidad.
