Por Jesús Cea Avión jcea@hispasec.com En Febrero de 2002, David Martin y Andrew Schulman publicaron un interesante informe sobre la seguridad del servicio de navegación anónima "SafeWeb". Aunque dicho documento está ya anticuado, refleja con una claridad diáfana los problemas a los que debe enfrentarse un servicio de este tipo. "SafeWay" era un servicio que permitía a los usuarios navegar por Internet de forma anónima, tanto para los servidores web a los que se conecte el usuario, como para cualquier curioso que pudiese haber entre "SafeWay" y la máquina del usuario. Un ejemplo sería el sistema de control de contenidos corporativo. Para ello se establece un túnel SSL, entre "SafeWay" y el navegador del usuario. El usuario no requiere ningún software específico; basta con un navegador con soporte SSL. Cualquiera con menos de 5 años de antigüedad, prácticamente. La mayor parte de los problemas de "SafeWay" vienen derivados de intentar "limpiar" el posible código JavaScript que pudiera existir en las páginas web. Dado que JavaScript es un lenguaje "completo", resulta imposible asegurar su "limpieza" de forma estática (principio de Turing). Sería necesario implementar un intérprete JavaScript nuevo. Otros servicios de anonimato, reconociendo el problema, optan por eliminar todo el código JavaScript de las páginas web. Esto es más seguro y simple, pero existen dos problemas: a) hay páginas que no funcionan sin JavaScript y b) un atacante suficientemente motivado puede codificar el JavaScript de forma tal que sea reconocido por el navegador pero no por el filtro. Naturalmente este último problema se puede considerar un "bug" y las nuevas versiones del filtro lo irían aliviando. Lamentablemente "SafeWay" intentó preservar al máximo las funcionalidades de las páginas originales, lo que supone soportar JavaScript. Pero, por el principio de Turing, no es posible saber, de forma estática, si un programa tiene efectos maliciosos o no. "SafeWay" optó simplemente por restringir el acceso a determinadas funcionalidades consideradas peligrosas. Pero esto tiene dos problemas: a) Hay funciones peligrosas "desconocidas" y que, por tanto, no se filtran adecuadamente y b) Pueden invocarse funciones peligrosas usando como primitivas funciones seguras. El caso más evidente del segundo punto sería, por ejemplo, el construir una cadena "prohibida" mediante la concatenación de subcadenas "permitidas". Si la palabra "prohibido" está prohibida y se filtra, podemos construirla como "proh"+"ibido" o "pro"+"hi"+"bi"+"do". Un escáner estático como el que usaba "SafeWay" es incapaz de enfrentarse a esquemas de este tipo. Con ello, David y Andrew demostraron que, en la práctica, un servidor web malicioso puede ejecutar código JavaScript arbitrario en el navegador del usuario. Ello permitiría, por ejemplo, acceso a "cookies" o a la IP real del usuario, comprometiendo el anonimato garantizado en la navegación. Pero los problemas realmente graves son: * Acceso a cualquier "cookie" de cualquier página web que haya visitado el usuario a través de "SafeWay". * Creación y modificación de cualquier "cookie" que se quiera, para cualquier página que se desee. * Posibilidad de realizar un seguimiento de todas las páginas web a las que el usuario acceda, vía "SafeWay". Hay que señalar que estas vulnerabilidades, muy graves, existen debido al uso de "SafeWay" por parte del usuario. Es decir, que este servicio, no solo no garantiza el anonimato en la navegación, sino que introduce gravísimos problemas de seguridad adicionales, que un usuario "no anónimo" no padece. El documento es una lectura recomendable de 24 páginas, en PDF. Sirve como un excepcional ejemplo de como no hacer las cosas. Más Información:
|
