Instrumentar la aplicación durante las pruebas

Las pruebas de seguridad interactivas, IAST por sus siglas en inglés, ponen un agente dentro del proceso de la aplicación mientras otra cosa la usa: la batería de pruebas funcionales, una persona de calidad, un recorrido automático. El agente marca los datos que entran de fuera (parámetros, cuerpos, cabeceras, archivos) y los sigue por dentro hasta los puntos peligrosos: una consulta SQL, una plantilla, una redirección, una ruta en disco. Si el dato llega sin pasar por algo que reconozca como protección, lo informa con la ruta, el parámetro y la línea.

Frente al análisis estático, ve lo que de verdad se ejecuta, con su configuración y sus librerías, y por eso suele equivocarse menos. Frente al análisis dinámico desde fuera, no adivina por las respuestas: ve el flujo. Pero tiene dos límites que hay que tener presentes al leer su informe. Solo ve el código que las pruebas recorren: una ruta que la batería no toca no aparece, y su silencio no significa nada. Y solo reconoce las protecciones que conoce: una validación propia bien hecha puede salir como flujo sin proteger.

Abre el laboratorio y lee informe-flujos.txt. Dos flujos salen marcados como vulnerables. Para uno de ellos, fragmentos.py confirma que el parámetro termina pegado a la consulta sin ninguna lista de columnas permitidas.

El otro flujo marcado es una redirección. El agente dice que no vio ningún saneador que reconozca. Lee la función que usa esa ruta en fragmentos.py y decide si el destino puede ser algo distinto de una ruta interna fija.

Compara las rutas que el agente dice haber visto con inventario-rutas.txt. Las que faltan no están limpias: simplemente nadie las ejecutó mientras el agente miraba.

Entre las rutas que el agente no vio está la que exporta residentes y la que cambia la cuenta de recaudo. Lee la nota de configuracion-agente.txt sobre producción.