DAST
Ataca la aplicación en ejecución como lo haría un usuario malintencionado, sin ver el código.
Qué es
(Dynamic Application Security Testing) prueba la aplicación en ejecución, de afuera hacia adentro, en caja negra: el scanner envía solicitudes maliciosas y observa las respuestas, como lo haría un atacante, sin acceso al código fuente.
Al operar sobre el sistema real ya ensamblado, el DAST valida lo que el no ve: configuración del servidor, headers HTTP, autenticación, sesión y la interacción entre componentes.
Cómo funciona
- crawling: un spider mapea los endpoints, formularios y parámetros de la aplicación
- fuzzing: cada entrada descubierta recibe payloads de ataque (, , path traversal, SSRF)
- análisis de respuesta: el scanner verifica si el ataque se reflejó, se ejecutó o filtró información
- chequeos pasivos: headers ausentes, cookies sin flags, versiones expuestas
Un ataque en la práctica
El scanner encontró un parámetro id en el crawler. Primer paso: la prueba clásica de SQL injection, cerrar la comilla e insertar una condición siempre verdadera. Lo que envía el scanner:
GET /users?id=1'%20OR%20'1'='1 HTTP/1.1
Host: tienda.ejemplo.comQué delata la falla
La firma del SQLi está en la respuesta: en lugar de un usuario, volvieron todos, porque la condición inyectada pasó a ser parte de la query. El scanner compara esa respuesta con la baseline del parámetro original y concluye: inyectable.
200 OK
[ {"id": 1, "nombre": "Ana"}, {"id": 2, "nombre": "Beto"},
{"id": 3, "nombre": "Caio"}, ... ] <- todos los usuariosCuando no hay eco: inyección ciega
No siempre la respuesta devuelve los datos, y los engines modernos esconden el error. Para esos casos, el scanner usa inyecciones ciegas e infiere por el comportamiento. Un retraso controlado es la evidencia:
GET /users?id=1'%20AND%20SLEEP(5)-- HTTP/1.1
con el payload: respuesta en 5,2 s
sin el payload: respuesta en 0,1 s
=> la base ejecutó el SLEEP: inyectable a ciegasDónde entra en el pipeline
Después del deploy en staging o preview: el pipeline levanta el entorno y apunta el scanner hacia él, fallando ante hallazgos críticos. Los scans programados contra producción cubren lo que cambia fuera del ciclo de release.
Puntos fuertes y limitaciones
- fuerte: reporta lo que realmente es explotable, con un falso positivo bajísimo, porque solo afirma lo que provocó
- fuerte: agnóstico al lenguaje, porque prueba HTTP, no código
- débil: solo ve la superficie expuesta; el código sin ruta accesible queda fuera
- débil: lento y tardío, encuentra después del deploy, cuando corregir ya cuesta
conexiones en el mapa
actualizado el 14/10/2026 · fuentes para profundizar · reportar un error
en otros dominios
- WAF - observación, shadow y enforcementsecopsencuentra la falla; el WAF mitiga mientras no se corrige (virtual patching)
Estudia antes
Desbloquea
pon a prueba lo que entendiste
Cargando preguntas…