El ocaso del análisis DAST

Muchas organizaciones recopilan datos de una infinidad de fuentes, como los usuarios, y luego los almacenan en lagos de datos. En la actualidad, los datos lo son todo, al igual que la capacidad de procesar una gran cantidad de datos en poco tiempo. 

El uso de los datos siempre se realiza a través de APIs. Las API mantienen unidos todos los componentes de la aplicación y los hacen accesibles como uno solo para cualquier tipo de cliente, como un usuario. 

Por supuesto, las API no vinieron solas. La arquitectura monolítica tradicional ha dado paso a otras, como los microservicios. Hoy todo es modular. Los microservicios hacen que cualquier aplicación sea modular para una mejor escalabilidad, mayor flexibilidad y menor time-to-market. 

Los microservicios combinados con las API se consideran el futuro del desarrollo de software. Esto es tan cierto que OWASP lanzó en 2019 una versión adaptada a APIs de su conocido OWASP TOP 10. Por lo tanto, en este escenario, la seguridad de las aplicaciones debe adaptarse a esta nueva forma de crear software y mantenerse al día. 

En la última década, la seguridad para aplicaciones también ha evolucionado en forma de varias pruebas de seguridad automatizadas y especializadas. Sin embargo, esa evolución de los controles de seguridad parece quedarse atrás, como sucede con los análisis dinámicos de seguridad de aplicaciones (DAST).

DAST, un tipo guay 

El análisis DAST surgió como una herramienta de caja negra “bastante” automática para encontrar vulnerabilidades específicas en aplicaciones web en un momento en el que casi las únicas técnicas eran el análisis SAST y el pentesting manual. Los DAST surgieron con la promesa de ayudar al pentester y cubrir algunos de los vacíos en las herramientas SAST, como reducir los falsos positivos y el tiempo de escaneo. 

El proceso de ejecución es muy sencillo: a partir de conjuntos de reglas predefinidos, envía solicitudes HTTP a la aplicación web y verifica ciertas cadenas de texto en las respuestas para ver si existe alguna vulnerabilidad. En pocas palabras, el análisis DAST intenta simular a un pentester. 

No hace falta decir que hay un par de inconvenientes principales:  

• Falsos positivos. Cualquier número de falsos positivos necesitaría una breve revisión después del escaneo, el llamado triaje. Ese triaje a menudo precisaría de los ojos expertos de un analista de ciberseguridad e, incluso para un experto, lleva un tiempo precioso que puede terminar ralentizando los pasos posteriores al escaneo 
• Tiempo. Los escaneos tardan tiempo en ejecutarse, generalmente de 30 minutos a 2 horas, o tal vez días, dependiendo del tamaño de la aplicación. Además, el tiempo dependerá de lo buena que sea la configuración. Cuanto mejor sea la configuración, menos tiempo tardará en ejecutarse. Pero conseguir una buena configuración previa al escaneo no es tan fácil y la mayoría de las veces también requiere de un experto en ciberseguridad 

El DAST está muy por detrás del desarrollo de software 

La forma de desarrollar software ha cambiado. El DAST ahora se suele integrar en el pipeline CI/CD y, en entornos de CI/CD, la agilidad y la velocidad son piezas clave. Cualquier compilación e implementación no debe durar más de un par de minutos. 

Esto no sucede con los análisis DAST. Como ya hemos mencionado, los escaneos DAST tardan tiempo en ejecutarse, se necesita tiempo para revisar los hallazgos y tiempo para configurarlos. Pero estos escollos no son los únicos contrarios a la agilidad y la velocidad: 

• Descubrimiento y crawling. Una de las principales características de las herramientas DAST es su capacidad para buscar y navegar casi todos los recovecos de la aplicación durante el escaneo. Aplicando algunas reglas heurísticas para reescribir direcciones URL y seguir vínculos, las herramientas DAST pueden detectar y rastrear numerosos subdominios y secciones de aplicaciones web. Otra versión de este proceso de descubrimiento consiste en utilizar proxies y recopilar todos los endpoints que se van a analizar. Pero en la actualidad, mientras que la seguridad se está desplazando hacia la izquierda en el SDLC, estas características podrían considerarse una deficiencia porque requieren tiempo. Afortunadamente, la mayoría de las herramientas DAST a lo largo de los años han incluido la posibilidad de especificar en varios formatos qué endpoints de la aplicación se desean escanear 
• Los desarrolladores usan DAST. Bajo el nuevo paradigma DevSecOps, los desarrolladores pueden usar por su cuenta algunas herramientas presentes en los pipelines, como las herramientas de seguridad, con el objetivo de conseguir una mayor agilidad en proceso de desarrollo de software. Si los desarrolladores por sí mismos pueden revisar los hallazgos de un análisis de seguridad de un análisis DAST, esto supuestamente aceleraría todo el proceso desarrollo. En teoría. En la práctica, los desarrolladores no siempre saben distinguir qué es un falso positivo y qué no lo es, o necesitan invertir más tiempo para hacerlo que un experto en seguridad. Este escenario reduce drásticamente la tolerancia a los falsos positivos de los equipos de DevSecOps y socava la confianza en los controles de seguridad 

Finalmente, el software en sí también ha cambiado. Como dijimos al principio, las APIs y los microservicios son el presente y el futuro, y el DAST está bien adaptado para ellos: 

• El DAST no identifica ningún contenido generado de forma dinámica en el front-end, lo cual es muy común hoy en día debido al uso extendido de frameworks Javascript, como Angular, React, Next, JQuery, etc 
• El DAST no detecta algunos tipos de vulnerabilidades habituales en las APIs, como los IDOR/BOLA, porque para ello se requiere contexto de la lógica de negocio de la aplicación, como roles de usuario y privilegios 
• El DAST también tiene dificultades para pasar a través de algunos muros de protección, como tokens anti-CSRF y varios mecanismos típicos de autenticación / autorización en APIs, como OAuth2, SSO y autenticación multifactor. Aunque es posible superar algunas de estas barreras, sin duda aumentaría el tiempo para preparar el escaneo, y cada aplicación necesita su propia configuración a medida 

¿Cómo usar DAST en 2023 y no morir en el intento? 

Llegados a este punto, es bastante tentador pensar que el DAST es inútil, pero no lo es. Muchas de las deficiencias anteriores se pueden subsanar mediante el uso del DAST de otras maneras: 

• Reutilizar DAST para encontrar resultados fáciles. Algunas vulnerabilidades son fáciles y rápidas de encontrar para cualquier herramienta DAST y tienen una proporción de falsos positivos razonablemente baja. Algunos ejemplos son las cabeceras HTTP inseguras o inexistentes, Cross Site Scripting o incluso algún tipo de SQLi 
• Probar requisitos de seguridad específicos. Si existe un catálogo de requisitos de seguridad, el análisis DAST podría usarse para ejecutar un conjunto muy específico de pruebas para verificar esos requisitos de alto valor en muchas aplicaciones 
• Crear plantillas de configuración de antemano. Como hemos mencionado ya, cuanto mejor sea la configuración, menos tiempo tardará en ejecutarse. Sería una buena idea invertir tiempo en preparar configuraciones que se pueden utilizar para escanear varias aplicaciones con características o arquitectura similares. Al hacer esto, con una sola configuración bien hecha, el tiempo de ejecución y los falsos positivos se reducirían considerablemente en futuros escaneos 
• Evitar escaneos completos. Escanear toda la aplicación podría llevar mucho tiempo y cada paso en pipeline de CI/CD debería durar solo unos segundos o minutos. En su lugar, hay que limitar el alcance del escaneo únicamente a los últimos cambios realizados en la aplicación 
• Alimentar el DAST con las rutas de la API exactas a escanear. Si la herramienta lo admite (recomendado), probar solo los endpoints de la API que se desea analizar, como los que tienen cambios. Esto permitiría obtener una cobertura de escaneo del 100% gradualmente sin ralentizar el proceso de CI / CD 
• Ejecutar el DAST de forma asincrónica. Si el escaneo se inicia en una fase del ciclo CI/CD y va a tardar un tiempo, una buena opción sería simplemente ejecutarlo sin esperar a que termine. Más tarde, cuando se complete, el equipo responsable podría revisar los hallazgos o hacer algún triaje 

Aparte de esto, el DAST sigue siendo una herramienta realmente útil para cualquier pentester, ya que es capaz de testear (fuzz) una gran cantidad de parámetros de entrada en numerosas aplicaciones en poco tiempo con una serie de conjuntos de reglas predefinidos que permitan encontrar muchos tipos de vulnerabilidades, como inyecciones y configuraciones erróneas. 

Qué debe tener una herramienta DAST para hacer pruebas de seguridad en APIs 

Al evaluar herramientas DAST o similares para hacer pruebas de seguridad en APIs, puede ser difícil saber qué herramienta es la mejor opción, por lo que a continuación se muestran algunos criterios que se pueden usar: 

• Fácil de integrar en un pipeline de CI/CD 
• Permite elegir qué tipo de aplicación se va a escanear: API o web con front-end 
• Admite varios formatos de especificación de API para especificar las rutas exactas de la API a escanear: colecciones de Postman, OpenAPI / Swagger, introspection de GraphQL, WADL, WSDL, etc. 
• Permite seleccionar el tipo específico de API que se va a probar: REST, GraphQL, SOAP 
• Proporciona la capacidad de definir pre y post scripts para generar configuraciones muy precisas para detectar vulnerabilidades de lógica de negocio 

A modo de resumen 

La forma en que se desarrolla el software ha cambiado, al igual que el software en sí. La agilidad y la velocidad son ahora características clave de cualquier SDLC gracias a las ventajas de utilizar pipelines de CI/CD. Las APIs se han convertido en el núcleo de cualquier componente software nuevo, por lo que la generación de aplicaciones seguras depende de la ausencia de vulnerabilidades en las APIs que hay por debajo. 

Las APIs deben probarse y asegurarse a un ritmo muy rápido y, aunque el análisis DAST no es lo más idóneo para eso, es posible modificar la configuración de los escaneos y la forma de integrarlos en los pipelines para analizar APIs mejor y más rápido. 

La IA: una nueva esperanza 

Este post no puede terminar sin hacer mención a la inteligencia artificial. 

La verdad es que cualquier solución DAST podría aprovechar la IA para resolver muchas de las desventajas que se han mencionado en este artículo, y algunas más. Por ejemplo, se podría usar para mejorar el proceso de descubrimiento y navegación a través de la reescritura inteligente de URLs, evitar solicitudes duplicadas o iterativas, disminuir los falsos positivos, detectar vulnerabilidades complejas de la lógica de negocio… 

¿Creéis que es posible que la IA se convierta en el fuego que revivirá al fénix del DAST? 

Ernesto Rubio, Consultor de Ciberseguridad