Técnicas para la optimización del análisis automático de vulnerabilidades en aplicaciones web
- ROMÁN MUÑOZ, FERNANDO
- Luis Javier García Villalba Director
Universidad de defensa: Universidad Complutense de Madrid
Fecha de defensa: 20 de diciembre de 2017
- María Victoria López López Presidente/a
- Ana Lucila Sandoval Orozco Secretario/a
- Pedro Peris López Vocal
- Marta Beltrán Pardo Vocal
- Andrés Caro Lindo Vocal
Tipo: Tesis
Resumen
Las aplicaciones web están disponibles en cualquier momento a un gran número de usuarios potenciales y, por lo tanto, expuestas a ataques malintencionados o no. Para mitigar los riesgos es habitual realizar un análisis de vulnerabilidades sobre las aplicaciones web durante el ciclo de vida de su desarrollo. Los métodos para detectar las vulnerabilidades en las aplicaciones web pueden ser de dos tipos: estáticos si analizan el código fuente de la aplicación o dinámicos si analizan la aplicación ejecutándola. Estos últimos son los más frecuentes. El análisis dinámico de vulnerabilidades consta de dos etapas: una primera llamada fase pasiva o de rastreo, donde se pretende localizar el mayor número posible de puntos de entrada a la aplicación, y una segunda llamada fase activa donde se realizan determinadas pruebas sobre los puntos de entrada localizados para intentar encontrar vulnerabilidades. Para realizar el análisis dinámico se suele emplear una herramienta automática que sigue estas dos fases a partir de la URL y eventualmente unas credenciales válidas. Las herramientas actuales no realizan por completo la primera fase de rastreo fundamentalmente por dos motivos: primero porque estas herramientas no son capaces de rellenar adecuadamente los formularios, especialmente aquellos que tienen restricciones muy fuertes en sus campos, y segundo porque a menudo no ejecutan correctamente el código de cliente que envía la aplicación al navegador. Respecto a la segunda fase, de prueba y análisis, la principal carencia que se detecta en el uso de estas herramientas se encuentra en las características que deben tener y en el método para determinar si las tienen, ya que no existe un criterio definido y aceptado sobre las funcionalidades que deben tener las herramientas, es decir, qué vulnerabilidades deben probar y detectar si es el caso. Asimismo, tampoco hay información sobre las pruebas que realmente hacen las herramientas cuando analizan una aplicación. El método tradicional de probar y comparar las herramientas de análisis consiste en intentar detectar con ellas una serie de vulnerabilidades en una aplicación vulnerable y analizar los informes resultantes. El conjunto de vulnerabilidades a detectar cambia de un trabajo a otro, por lo que no se pueden contrastar los resultados, y no se estudian qué pruebas realmente realizan las herramientas. La primera contribución se traduce en dos mejoras en la fase de rastreo: por un lado, se crea un nuevo método para encontrar valores de los campos de los formularios que la aplicación vaya a aceptar pudiendo avanzar en su flujo de funcionamiento definido y, por otro lado, se implementa un mecanismo mediante el cual una herramienta automática puede ejecutar el código cliente de la misma forma en la que lo haría un navegador empleado por un usuario. La segunda contribución, relativa a la fase de prueba y análisis, consiste en la compilación de una completa clasificación de vulnerabilidades, que agrupa las clasificaciones actuales y que además puede mantenerse actualizada. Estas vulnerabilidades son las que las herramientas deberían ser capaces de detectar. La tercera contribución es el desarrollo de una aplicación vulnerable que tiene implementadas muchas de las vulnerabilidades web y, en la que, a modo de ejemplo, se prueba un conjunto de herramientas con ella para determinar sus capacidades de detección. La cuarta y última contribución está relacionada con el hecho comentado anteriormente de que no se sabe qué hacen realmente las herramientas. Para intentar determinar las acciones de las herramientas sobre las aplicaciones se implementa una solución, basada en situar un elemento intermedio entre herramienta y aplicación, que dice qué pruebas hacen las herramientas y se compara con las vulnerabilidades de la aplicación y con el informe final de la herramienta. De esta forma se sabe si las herramientas prueban todo lo que deben y pueden y si informan de todo lo que han probado y detectado.