Un flujo de trabajo con Burp Suite que encuentra fallos reales, no solo alertas

Todas las auditorías de aplicación web que hacemos pasan por Burp Suite, y casi ninguno de los hallazgos que importan sale de pulsar "Scan". El escáner activo es bueno con las clases de fallo que tienen una firma determinista: XSS reflejado, inyección SQL con mensaje de error, salto de directorio. Es ciego a los que de verdad provocan brechas, que van de autorización, lógica de negocio y estado.

En lo que Burp no tiene rival es en ser un sitio donde sentarse entre el navegador y la aplicación, con todas las peticiones a mano. El valor está en cómo lo configuras.

Primero el alcance, o el historial no sirve

Define el alcance del objetivo antes de la primera petición, y activa "and URL in the suite scope" en el filtro de interceptación del proxy. Si no, dos horas de navegación te dejan un historial lleno de balizas de analítica, fuentes de CDN y widgets de chat de terceros, con la petición que buscas perdida dentro.

Incluye los hosts propios de la aplicación y el host de su API. Excluye el endpoint de cierre de sesión: Burp lo tocará durante un escaneo y matará tu sesión en el peor momento.

La autenticación es lo que casi todo el mundo hace mal

Un escaneo sin autenticar de una aplicación autenticada encuentra la página de login. Ese es el resultado completo.

Tres cosas tienen que estar bien:

Reglas de sesión. En Settings → Sessions, añade una regla limitada al objetivo que ejecute una macro para volver a autenticarse cuando caiga la sesión, con una regla de "comprobar que la sesión es válida" que busque una cadena que solo aparece estando dentro. Sin esto, medio escaneo corre como usuario anónimo y no te enteras.

Varias identidades. Consigue credenciales de al menos dos usuarios del mismo rol y uno de un rol distinto, más una sesión sin autenticar. Casi todo fallo de autorización se encuentra cogiendo una petición capturada como usuario A y reproduciéndola como usuario B.

Un token que Burp entienda. Si la aplicación usa un bearer token en cabecera en vez de una cookie, la macro tiene que extraerlo y la regla de sesión tiene que inyectarlo. Merece la pena los quince minutos; todo lo demás depende de ello.

Las extensiones que se ganan su sitio

De la tienda BApp, cuatro hacen casi todo el trabajo:

• Autorize reproduce cada petición que haces con una segunda identidad de menos privilegio y marca las que salen bien. Esta sola extensión encuentra más fallos reales y graves en una auditoría típica que el escáner activo. El fallo de autorización a nivel de objeto es el defecto serio más común en las API modernas y es invisible para el escaneo por firmas.
• Param Miner adivina parámetros y cabeceras no enlazados. Así es como encuentras el ?debug=true que activa una traza y el X-Original-URL que salta el control de acceso del proxy.
• JS Link Finder o JS Miner extraen endpoints, rutas y a veces credenciales del JavaScript empaquetado. Las aplicaciones de página única mandan toda su superficie de API al navegador; léela.
• Logger++ te da una vista filtrable y exportable de todas las herramientas de Burp a la vez, algo que importa cuando tienes que demostrar qué enviaste y cuándo.

De dónde salen los hallazgos de verdad

Repeater, petición a petición. Coge una petición que devuelva un objeto por ID y cambia el ID. Cambia el identificador de usuario en el payload del JWT y mira si se comprueba la firma. Quita la cabecera Authorization entera. Cambia el método de POST a GET. Manda la petición dos veces en paralelo y mira si el cupón se aplica dos veces. Nada de esto lo deduce un escáner.

Intruder contra identificadores, no contra contraseñas. Enumerar IDs secuenciales de objeto desde dos cuentas te cuenta el modelo de autorización en un minuto. Deja la fuerza bruta de credenciales fuera del trabajo salvo que esté explícitamente en alcance, porque bloquea usuarios reales y genera alertas que el cliente tiene que triar.

Comparer sobre las respuestas. La diferencia entre "usuario no encontrado" y "contraseña incorrecta", o entre un 200 de 1.240 bytes y un 200 de 1.238 bytes, es a menudo el hallazgo entero.

Distinguir un hallazgo de una alerta

Cada incidencia del escáner necesita tres cosas antes de entrar en el informe: una petición que puedas reproducir a mano, un efecto observado que no sea solo una cadena reflejada, y una frase sobre qué gana un atacante. "XSS reflejado en el parámetro de búsqueda" con un payload que solo dispara en un contexto que la CSP bloquea no es un hallazgo, son deberes. Un XSS almacenado en un campo que ve un administrador, con una prueba funcional que roba una sesión, sí lo es.

Y al revés también. Burp puntúa el control de acceso roto como bajo o informativo cuando lo puntúa, porque no puede saber que el objeto detrás del ID es la factura de otro inquilino. Vuelve a puntuarlo todo por lo que valen los datos.

Deja la evidencia reproducible

Guarda el fichero de proyecto, exporta las filas relevantes de Logger++ y escribe cada hallazgo como un comando curl que el propio desarrollador del cliente pueda pegar en una terminal. Un hallazgo que el equipo reproduce en treinta segundos se corrige en el siguiente sprint; uno que exige instalar Burp y reproducir una macro se queda un año en el backlog.

Esto lo hacemos dentro de una revisión de seguridad más amplia, porque los fallos de una aplicación web y la postura de su cuenta cloud suelen ser la misma historia contada por los dos extremos.