XSS en la web de la OPII
El otro día de casualidad me encontré con otro ejemplo más de lo que no se debe hacer en una aplicación web dentro de las páginas de la Universidad Politécnica de Valencia. Si en otro post hablaba de un problema de cookies y robo de sesión en la intranet de alumnos de la UPV, esta vez se trata de dos XSS en las páginas de la Oficina de Programas Internacionales de Intercambio (o algún nombre similar 😀 ).
Estaba yo mirando mis datos de la beca Erasmus cuando me tuve que ir a comer, y al volver me encuentro con que la sesión había expirado y la URL era del tipo error.asp?msg=mensaje , y el mensaje aparecía en el cuerpo de la página. Un claro ejemplo de XSS temporal si no se filtra adecuadamente el mensaje.
Además de éste, mirando las páginas de la opii que tenía en la barra de direcciones de mi firefox, me encontré con otra URL similar, pero esta vez metían el mensaje en un alert() de JavaScript y sólo era necesario cerrarlo con '); para salirse del alert y seguir añadiendo código JavaScript.
Les avisé y en un día tenía respuesta vía mail con un agradecimiento e informándome de que se habían corregido ambos fallos.
En fin, como decía antes, un ejemplo más de qué NO se debe hacer. Al menos esta vez fueron rápidos en corregirlo.
Cookies: domain, path y seguridad
Ahora que ya lo han resuelto creo que es el momento de comentarlo por aquí. Hace más de un mes (concretamente el 17 de febrero) nos dimos cuenta por casualidad de un fallo en los servicios web de la UPV que podía suponer el acceso a la Intranet con otro usuario, con la consecuencia de poder ver su expediente académico, datos personales, webmail, préstamos en biblioteca... incluso número de cuenta si tenía domiciliado el pago de la matrícula.
Todo vino porque Bea me comentó que no podía acceder a la web del IEEE-sbUPV ya que le salía google. Entonces avisé al administrador de dicho servidor y estuvimos mirando qué pasaba. Llegamos a la conclusión de que se trataba de una cookie del PoliformaT, una aplicación de nuestra universidad, que hacía saltar las alarmas del mod_security y ejecutaba la acción por defecto: mandar al usuario a google. Y fue entonces cuando se encendió la bombilla: si esta cookie se manda aquí, es posible que se mande a todo el dominio upv.es, junto con los identificadores de sesión... y ello probablemente implique que se pueda robar dicha sesión.
Así que creé una pequeña página en PHP en mi página personal de la universidad ( por si alguien no lo sabe, se puede poner tu página en la carpeta www de tu unidad compartida W: y tener una web en http://personales.alumno.upv.es/nombre_usuario ) que simplemente mostraba las cookies, algo así:
<?php
print_r($_COOKIE);
?>
Con esto, se obtenía la variable TDp, e introduciéndola en la petición HTTP se podía acceder a la sesión de otro usuario utilizando por ejemplo paros proxy . Nosotros lo probamos con una cuenta de alumno (la de Bea, con su consentimiento) y accedimos sin problemas... desconozco si como profesor se habría podido, pero supongo que funcionaría igual.
Y bien, ¿cual era el problema? Pues básicamente dos: que se mandaba la cookie a TODO el dominio *.upv.es y no a www.upv.es y la ruta específica donde se encuentra la aplicación de la intranet, y que para identificar la sesión se usaba única y exclusivamente dicha cookie.
Soluciones? Pues no mandar la cookie a todos sitios y/o utilizar algún dato más del usuario que deba permanecer invariable durante una sesión para identificarlo, por ejemplo la dirección IP. La solución que ha tomado la UPV ha sido la segunda, y por ello no sé desde cuando está resuelto el problema ya que las cookies se siguen mandando y yo lo que he hecho durante este tiempo era mirar de vez en cuando si las cookies se mandaban o no. Ayer probé de nuevo durante una clase con un compañero (también con su consentimiento) y vimos que daba un error por haber cambiado de dirección IP.
Para la otra solución, supongo que todos los lenguajes de programación web permiten especificar fácilmente a qué dominio y ruta pertenece la cookie. Por ejemplo en PHP, la función setcookie lo permite especificar en sus parámetros y por defecto manda la cookie al dominio actual, con ruta el directorio actual.
Así pues, si programas aplicaciones web, y sobretodo si van a estar en hostings compartidos, deberías tener en cuenta esto que parece una tontería, pero puede permitir el secuestro de una sesión 😉