(N.d.E.: Vean antes la primera parte y la segunda parte)
Cuando la sesión se encuentra alojada en la cookie resulta mucho más difícil de explotar, debido a que cualquier navegador Web básico emplea la protección de mismo origen o “origin server”, donde un recurso web solo puede modificar atributos si ese recurso pertenece a su mismo dominio, puerto y protocolo, es decir, el servidor atacante no puede modificar la cookie del servidor víctima, y por tanto, no podrá fijar su sesión a la víctima.
Aún así existen distintas formas de intentar explotar una fijación de sesión almacenada en una cookie:
2. Si puedo modificar el tráfico de red entre la víctima y el servidor vulnerable. Sinceramente ocurre lo mismo que en el caso anterior.
3. Pasar por GET la sesión y esperar un tratamiento incorrecto de la variable, ya que algunas aplicaciones Web si leen la variable de sesión por GET modifican la variable en la cookie.
4. Inyectando código HTML y JS en la cabecera del navegador, en especial “meta http-equiv” para intentar modificar la cookie. Esto funcionaba hace unos años, ahora mismo a mí no me ha dado buen resultado.
5. Intentado poner la cookie en la URL de tal forma que entre el recurso vulnerable y la cookie haya un salto de línea añadido “\r\n”, de modo que parezca que el servidor interprete la URL como URL más cabecera cookie. Era una vulnerabilidad relativamente antigua, tampoco me ha funcionado.
Por tanto, y desde mi punto de vista, intentar explotar una fijación de sesión por cookie es bastante difícil ya que se depende muchas veces de que el servidor, el navegador web de la víctima o la aplicación Web tenga alguna vulnerabilidad adicional.
Y ahora la pregunta que se estarán realizando, ¿por qué este post de una vulnerabilidad conocida y tanto interés en explotar la vulnerabilidad si la sesión va en una cookie? La respuesta es sencilla, en un viaje de vuelta en el tren me puse a jugar con una aplicación Web que sirve para practicar auditoría Web: DVWA. Como todas estas aplicaciones tienen una página de acceso al reto protegida por usuario y contraseña, la cual en principio no es vulnerable.
En caso de la DVWA creo que es vulnerable a fijación de sesión, ya que ésta no cambia antes y después de autenticarnos. Por precaución busqué si alguien había comentado algo previamente pero no he encontrado ningún comentario al respecto. Lógicamente esta aplicación no está enfocada a estar jamas en producción y su único propósito es docente. Aunque no tiene ningún tipo de criticidad puede servir como ejemplo.
Veámoslo en las siguientes dos capturas. Primero accedemos al recurso “login.php” sin estar autenticados, en la variable PHPSESSID vemos el valor de la sesión:
Una vez autenticamos el valor de la sesión continua siendo la misma:
Por desgracia al ir en la cookie la sesión me fue imposible explotar la vulnerabilidad. Para finalizar agradecer la ayuda proporcionada por Raúl Siles para intentar fijar la sesión en la cookie y recomendar esta presentación sobre fijación de sesión (PDF), a cuya charla en Barcelona tuve el placer de asistir. Nos vemos en la próxima entrada.
(N.d.E.: Mañana es festivo nacional —España—, por lo que nos vemos de nuevo el jueves con un post diferente a estos últimos)
Si la aplicacion web esta corriendo sobre weblogic y este esta mal configurado (tiene activa la propagacion del id de sesion por url) se puede forzar a un usuario a tomar un id de sesion arbitrario pasandole el enlace http://www.aplicacion.com/;jsessionid=%5Bsesion%5D