DAST: 7 casos de uso, ejemplos, ventajas y desventajas
La capacidad de DAST para simular ciberataques reales y exponer vulnerabilidades en tiempo real lo convierte en una herramienta valiosa en el ámbito de la ciberseguridad. Como se observa en el gráfico, la popularidad de DAST ha aumentado significativamente en los últimos cinco años.
Teniendo en cuenta que una parte significativa de los ataques de software explotan la capa de aplicación. 1 El enfoque de DAST en las pruebas externas se vuelve aún más crucial.
A continuación, vea cómo DAST se integra en los flujos de trabajo de DevSecOps, cumple con los requisitos de cumplimiento y detecta vulnerabilidades en tiempo de ejecución que las herramientas estáticas no detectan.
Ventajas y desventajas de DAST
¿Cómo funciona DAST?
DAST sigue una secuencia repetible cada vez que se ejecuta contra una aplicación objetivo.
- Identificación del objetivo: El escáner apunta a una URL o a un conjunto de puntos finales de API. En entornos CI/CD, esto generalmente se configura una sola vez y luego se activa automáticamente en cada compilación.
- Rastreo: La herramienta mapea la superficie de ataque de la aplicación siguiendo enlaces, enviando formularios y analizando JavaScript, creando un inventario de cada entrada y punto final al que puede acceder. Los escáneres modernos utilizan un rastreador AJAX junto con el rastreador estándar para gestionar aplicaciones de una sola página que cargan contenido dinámicamente.
- Simulación de ataque: Contra cada entrada detectada, el escáner dispara cargas útiles de ataque: cadenas de inyección SQL, vectores XSS, secuencias de recorrido de ruta, encabezados mal formados y otros extraídos del OWASP Top 10 y más allá. Tres técnicas principales sustentan esta fase:
- El fuzzing envía datos inesperados o mal formados para provocar errores no controlados.
- Manipulación de parámetros, modificación de valores en URL, cookies y cuerpos de solicitud para probar la validación de entrada.
- Pruebas de autenticación que intentan fijar la sesión, predecir el token y escalar privilegios en todos los roles de usuario.
- Análisis de respuesta: El escáner evalúa cada respuesta en busca de indicadores de una vulnerabilidad real, como rastreos de pila, mensajes de error de la base de datos, redirecciones a recursos no deseados o datos devueltos cuyo acceso debería estar controlado. Las herramientas que utilizan escaneo basado en pruebas confirman la posibilidad de explotación antes de señalar un problema, lo que reduce los falsos positivos.
- Informes: Los resultados se recopilan en un informe ordenado por gravedad, que incluye el punto final afectado, la carga útil que desencadenó el problema y recomendaciones para su solución. La mayoría de los escáneres empresariales envían la información directamente a Jira, GitHub Issues o plataformas SIEM, de modo que los hallazgos se dirigen al equipo adecuado sin necesidad de una revisión manual.
- Nuevas pruebas: Una vez implementada la solución, el escáner se ejecuta de nuevo en el punto final previamente vulnerable para confirmar que la vulnerabilidad se ha corregido, un paso que también sirve como evidencia documentada para las auditorías de cumplimiento.
Los 7 principales casos de uso de DAST
1-Integración con el ciclo de vida del desarrollo
DAST se integra en las fases de prueba y preproducción del ciclo de vida del desarrollo de software, donde las aplicaciones están en funcionamiento pero aún no han llegado a producción. En esta etapa, corregir vulnerabilidades es más económico y no supone ningún riesgo para el cliente. En los pipelines de CI/CD, los análisis se pueden activar automáticamente en cada compilación, lo que convierte la seguridad en una parte rutinaria del proceso de lanzamiento, en lugar de una etapa final.
Ejemplo de la vida real
Antes de la integración, el equipo de seguridad realizaba análisis manuales que no podían seguir el ritmo del calendario de lanzamientos de Park 'N Fly. Tras conectar Invicti a sus flujos de trabajo existentes de Azure DevOps y Jira, los análisis se activaron automáticamente con cada compilación, lo que permitió que las comprobaciones de seguridad pasaran de una revisión trimestral a una revisión por lanzamiento. El equipo recuperó el equivalente a la carga de trabajo manual de un empleado a tiempo completo. 2
2-Simulación de ataque en el mundo real
Las herramientas DAST simulan ataques reales a una aplicación web, proporcionando una evaluación práctica de su nivel de seguridad.
Ejemplo de la vida real
En mayo de 2023, una vulnerabilidad de inyección SQL en la plataforma MOVEit Transfer de Progress Software, una aplicación de transferencia de archivos gestionada muy utilizada, fue explotada antes de que el proveedor tuviera conocimiento de ella. La brecha comprometió 11,3 millones de registros de pacientes en Maximus y afectó a decenas de agencias gubernamentales y empresas en varios países, incluyendo la BBC, la empresa británica de software de recursos humanos Zellis y el gobierno de Nueva Escocia. 3
Progress Software se enteró de la vulnerabilidad solo porque ya estaba siendo atacada activamente. La confirmaron, lanzaron un parche y notificaron a los clientes el mismo día, pero la explotación ya había comenzado antes de que se hiciera pública. 4
Un escáner DAST que se ejecutara contra la aplicación web de MOVEit en un entorno de prueba habría enviado cargas útiles de inyección SQL a los campos de entrada de la aplicación y habría detectado la respuesta anómala de la base de datos, la misma técnica que utilizaron los atacantes. En ese caso, la solución sería una tarea de desarrollo. Sin esa prueba, la misma vulnerabilidad habría permanecido en un sistema de producción utilizado por cientos de organizaciones.
3-Requisitos de cumplimiento y reglamentarios
Las normativas como PCI DSS, HIPAA y GDPR exigen pruebas de seguridad periódicas para las aplicaciones que manejan datos confidenciales. La clave está en la « demostración »: los auditores requieren evidencia documentada de que se detectaron y corrigieron las vulnerabilidades, no solo la confirmación de que se realizaron las pruebas. DAST genera precisamente eso: los informes de análisis muestran qué vulnerabilidades existían en la aplicación en producción, cuándo se detectaron y si se verificó su corrección.
- Las organizaciones deben proteger las aplicaciones web de acceso público mediante evaluaciones periódicas de vulnerabilidades o un WAF (Firewall de Aplicaciones Web). DAST cumple con la opción de evaluación al probar la aplicación implementada contra los vectores de ataque que buscan los auditores (inyección SQL, XSS, fallos de autenticación) y generar resultados con marca de tiempo listos para la auditoría.
- Las organizaciones deben realizar comprobaciones automatizadas semanales para detectar cambios no autorizados en los scripts de las páginas de pago y en los encabezados HTTP. Los informes de análisis DAST facilitan esta tarea al proporcionar evidencia continua a nivel de aplicación de que el entorno general que rodea a las páginas de pago no se ha visto comprometido.
Ejemplo de la vida real
Channel 4, la emisora comercial pública del Reino Unido, opera la plataforma de streaming All 4 con 24 millones de usuarios registrados, todos sujetos a los requisitos de seguridad de datos del RGPD. Para demostrar el cumplimiento, el equipo de seguridad encargó previamente varias pruebas de penetración externas por proyecto. Cada prueba arrojaba resultados, el equipo los corregía y luego pagaba por una nueva prueba. El CISO Brian Brackenborough describió el coste acumulativo: cada proyecto podía pasar por varios ciclos dependiendo de su complejidad.
Tras integrar la plataforma automatizada DAST de Invicti, Channel 4 pasó a realizar escaneos continuos en hitos fijos del proyecto, sustituyendo el ciclo de repetición de pruebas por una verificación automatizada interna. El gasto anual en pruebas de penetración se redujo aproximadamente un 60 % en el primer año y cayó a cerca del 20 % del gasto original en el segundo año. 5
4-Cobertura integral
DAST prueba todas las interfaces que la aplicación expone al exterior (formularios de inicio de sesión, tokens de sesión, puntos finales de API, parámetros de URL, encabezados HTTP) sin acceso al código fuente. La autenticación defectuosa, la fijación de sesión, las referencias directas a objetos inseguras y los controles de acceso mal configurados no son patrones estáticos en el código; surgen del comportamiento de la aplicación cuando un usuario o un atacante le envía datos específicos.
DAST abarca los puntos finales que los desarrolladores podrían no haber expuesto intencionalmente. Las API ocultas, las rutas obsoletas que permanecen activas después de un cambio de funcionalidad y las interfaces de administración accesibles desde la red pública no aparecerán en una revisión de código, pero sí en un rastreo de DAST.
5- Monitoreo continuo
Las aplicaciones no permanecen estáticas tras su implementación. Se actualizan las bibliotecas, se añaden nuevos puntos de acceso, se realizan cambios de configuración y se cargan scripts de terceros desde dominios externos, cualquiera de los cuales puede introducir una vulnerabilidad que no existía en el último análisis. Las pruebas anuales o trimestrales no pueden detectar un fallo introducido en una implementación realizada un martes. DAST, integrado en una canalización de CI/CD, se ejecuta con cada nueva compilación, lo que significa que la seguridad de la aplicación se verifica de forma continua en lugar de periódica.
Las dependencias de terceros hacen que esto sea especialmente importante. Los ataques a la cadena de suministro, en los que se compromete un componente externo de confianza y se utiliza para inyectar comportamiento malicioso en aplicaciones posteriores, se sitúan ahora como el tercer riesgo más alto para las aplicaciones web en el OWASP Top 10:2025. DAST detecta estos ataques en tiempo de ejecución, donde se manifiesta el comportamiento inyectado, en lugar de en el código fuente, donde la dependencia puede parecer inalterada.
Ejemplo de la vida real
En junio de 2024, el dominio y el repositorio de GitHub de Polyfill.js fueron adquiridos por un nuevo propietario que modificó el script para redirigir a los usuarios de dispositivos móviles a sitios maliciosos. Más de 100 000 aplicaciones web cargaban Polyfill directamente desde la CDN, lo que significaba que una dependencia de confianza se convirtió silenciosamente en un vector de ataque sin que se modificara el código de ninguna de esas aplicaciones. Las herramientas DAST detectaron el comportamiento malicioso poco después de que se detectara, identificando qué aplicaciones cargaban el script comprometido y generando recomendaciones para su corrección. 6
6-Identificación de problemas en tiempo de ejecución
Algunas clases de vulnerabilidades no existen en el código fuente, sino que surgen del comportamiento de una aplicación desplegada en condiciones reales. Las condiciones de carrera aparecen cuando varias solicitudes simultáneas acceden al mismo recurso. Los fallos en la lógica de negocio se manifiestan cuando un atacante ejecuta un flujo de trabajo de varias etapas en el orden incorrecto. La falsificación de solicitudes del lado del servidor (SSRF) solo se manifiesta cuando la aplicación realiza conexiones salientes con otros sistemas. Las fugas de memoria, los fallos de tiempo de espera de sesión y la deserialización insegura requieren que la aplicación esté en ejecución para activarse.
DAST aborda estas cuestiones interactuando con la aplicación exactamente como lo haría un usuario o un atacante: enviando datos de entrada, observando las respuestas y probando cómo se comporta el sistema en condiciones que el análisis estático no puede simular.
7-Complemento a otros métodos de prueba
Ningún método de prueba por sí solo cubre toda la superficie de ataque de una aplicación moderna. Los equipos de seguridad suelen combinar DAST con:
- SAST analiza el código fuente antes de su implementación, detectando problemas como secretos codificados, llamadas a funciones inseguras y concatenaciones de cadenas vulnerables a inyecciones en las primeras etapas del desarrollo. No puede probar el comportamiento en tiempo de ejecución.
- IAST instrumenta la aplicación desde dentro durante su ejecución, monitorizando el flujo de datos a través del código en ejecución. Mientras que DAST observa el comportamiento externo de la aplicación, IAST observa su comportamiento interno durante la misma solicitud; ambos métodos producen resultados complementarios desde perspectivas opuestas.
- SCA analiza bibliotecas de terceros y de código abierto en busca de vulnerabilidades conocidas (CVE), señalando las dependencias vulnerables antes de que lleguen a producción. El incidente de Polyfill ilustra esta deficiencia: SCA no habría detectado el ataque porque la biblioteca en sí no tenía ninguna vulnerabilidad en el momento en que el dominio que la alojaba se vio comprometido. DAST detectó el comportamiento malicioso en tiempo de ejecución que SCA no pudo ver.
- Los escáneres de red y de vulnerabilidades identifican puertos abiertos, servicios obsoletos y configuraciones incorrectas de la infraestructura en la capa de host y de red, por debajo de la propia aplicación.
Limitaciones que debe tener en cuenta al usar DAST
1. No hay visibilidad del código interno.
DAST analiza los puntos finales, formularios, encabezados y respuestas que expone la aplicación. No puede leer el código fuente, por lo que las vulnerabilidades que no se manifiestan mediante interacción externa pasan desapercibidas. Por ejemplo, una credencial codificada directamente en la lógica del servidor no aparecerá en un análisis DAST a menos que genere una respuesta observable. Para detectarlas, se requiere SAST o una revisión del código.
2. Descubrimiento en etapa avanzada
DAST requiere una aplicación en ejecución, lo que significa que no se puede usar hasta la fase de pruebas o de preproducción. Una vulnerabilidad introducida al principio del desarrollo puede persistir durante varios ciclos de compilación antes de que un análisis de DAST la detecte. Cuanto más tarde se descubra una vulnerabilidad, más código se habrá desarrollado sobre ella, lo que aumenta tanto el costo de la corrección como el riesgo de que la solución introduzca nuevos problemas.
3. Falsos positivos y falsos negativos
Las herramientas DAST infieren vulnerabilidades a partir de las respuestas de las aplicaciones, lo que significa que pueden marcar un comportamiento benigno como una vulnerabilidad (falso positivo) o no detectar una vulnerabilidad que requiere una secuencia específica de entradas (falso negativo). Los falsos positivos hacen perder tiempo en la remediación; los falsos negativos generan una falsa sensación de seguridad. Las herramientas modernas reducen los falsos positivos mediante el análisis basado en pruebas, que confirma que una vulnerabilidad es explotable antes de informarla, pero aún existen lagunas en la cobertura, especialmente en flujos de trabajo complejos y autenticados.
4. Fallos en la lógica empresarial
DAST identifica vulnerabilidades que producen anomalías detectables como inyección SQL, XSS y omisión de autenticación. No puede detectar fallos donde la aplicación se comporta exactamente como está programada, pero la lógica en sí es insegura. A partir de 2026, la autorización a nivel de objeto (BOLA) y la autorización a nivel de función (BFLA) son los principales riesgos de seguridad de las API; ambos implican que la aplicación procese correctamente una solicitud que debería haber rechazado. Ningún escáner automatizado puede determinar que una regla de negocio es incorrecta, solo que se ha infringido.
5. Riesgo de escaneo de producción
DAST envía activamente cargas útiles de ataque a una aplicación en producción. En entornos de prueba, este es el comportamiento previsto. En producción, el mismo análisis puede provocar errores, corromper datos de prueba, bloquear cuentas o generar una carga que degrade el rendimiento para los usuarios reales. La mayoría de los equipos restringen los análisis completos de DAST a entornos de preproducción y utilizan una monitorización pasiva más ligera en producción, aceptando una cobertura limitada a cambio de seguridad operativa.
6. Sin localización a nivel de código
DAST identifica la existencia de una vulnerabilidad en un punto final determinado, pero no puede señalar la línea de código responsable. Un desarrollador que recibe un hallazgo de DAST debe reproducir el problema, rastrear la solicitud a través de la pila de la aplicación y localizar el origen manualmente. Integrar la salida de DAST con los resultados de SAST o utilizar IAST, que instrumenta la aplicación internamente, puede reducir esta brecha al correlacionar el hallazgo en tiempo de ejecución con una ubicación en el código.
7. Brechas de cobertura en las arquitecturas de aplicaciones modernas
DAST rastrea una aplicación siguiendo enlaces y enviando formularios. Las aplicaciones de una sola página creadas con React, Angular o Vue renderizan el contenido dinámicamente mediante JavaScript después de la carga inicial de la página, lo que los rastreadores tradicionales no pueden explorar por completo. Las API que requieren tokens de autenticación específicos, flujos de trabajo de varios pasos o formatos de entrada no estándar también pueden quedar sin probar a menos que la herramienta DAST esté configurada explícitamente para ellas. La cobertura es tan completa como la capacidad del escáner para navegar por la aplicación.
Preguntas frecuentes
Las pruebas dinámicas de seguridad de aplicaciones (DAST) analizan una aplicación en ejecución desde el exterior, sin acceso a su código fuente. Envían entradas maliciosas, cargas útiles de inyección SQL, cadenas XSS e intentos de omisión de autenticación a las interfaces expuestas, e identifican las respuestas inesperadas como posibles vulnerabilidades. Dado que opera exactamente como lo haría un atacante externo, DAST detecta fallos que solo se manifiestan en tiempo de ejecución y que el análisis estático del código no puede detectar.
En las prácticas modernas de desarrollo de software, especialmente en aquellas que siguen metodologías DevOps, las mejores prácticas y herramientas de DAST se pueden integrar en los flujos de integración y entrega continuas (CI/CD). Esta integración garantiza la seguridad de forma continua durante todo el ciclo de vida de la aplicación.
Para elegir una herramienta DAST, consulte la lista de las mejores soluciones DAST .
Las herramientas DAST, las herramientas de escaneo de vulnerabilidades, las herramientas de seguridad de API y las herramientas de seguridad de aplicaciones cumplen funciones específicas en el contexto más amplio de la ciberseguridad, aunque existe cierta superposición entre ellas.
Las herramientas DAST se especializan en probar la seguridad de las aplicaciones web mientras se están ejecutando, simulando ataques externos para descubrir vulnerabilidades que solo son evidentes durante el funcionamiento.
Las herramientas de escaneo de vulnerabilidades ofrecen un servicio más amplio, ya que analizan sistemas, redes o aplicaciones en busca de diversos problemas de seguridad, incluidas debilidades que podrían no limitarse al software en sí, sino que podrían estar relacionadas con configuraciones o sistemas obsoletos.
Las herramientas de seguridad para API están diseñadas específicamente para proteger las API, que son interfaces críticas entre diferentes aplicaciones de software. Estas herramientas se centran en aspectos de seguridad propios de las API, como la protección de los puntos finales, la autenticación y la gestión de las llamadas a la API, y la garantía de la integridad de los datos durante la transmisión.
Las herramientas de seguridad de aplicaciones abarcan una amplia gama de herramientas, incluidos los tipos mencionados anteriormente, y están diseñadas para proteger las aplicaciones a lo largo de todo su ciclo de vida. Esta categoría incluye herramientas y prácticas que abordan la seguridad en diferentes etapas, desde el desarrollo hasta la implementación y el mantenimiento.
Sin embargo, estas categorías se superponen:
Las herramientas DAST son un subconjunto de las herramientas de seguridad de aplicaciones, específicamente diseñadas para identificar vulnerabilidades en aplicaciones web en producción mediante ataques externos simulados.
Las herramientas de seguridad de API también se engloban dentro del ámbito más amplio de las herramientas de seguridad de aplicaciones, pero se centran específicamente en la seguridad de las interfaces de API, abordando desafíos únicos como la seguridad de los puntos finales y la autenticación.
Las herramientas de escaneo de vulnerabilidades tienen un alcance más amplio, abarcando comprobaciones de seguridad en sistemas completos, incluyendo redes y aplicaciones. A menudo incluyen capacidades para identificar vulnerabilidades en aplicaciones web y API, solapándose así con las herramientas DAST y de seguridad de API.
Enlaces de referencia
Sé el primero en comentar
Tu dirección de correo electrónico no será publicada. Todos los campos son obligatorios.