FFUF + Burp Suite — Fuzzing con Requests Reales y Visibilidad Total

1. Operational Scope & Technical Objective

FFUF aporta velocidad (miles de requests con wordlists) y Burp Suite aporta visibilidad (inspección, modificación y análisis de cada request/response). Combinados resuelven el problema más común del fuzzing web: replicar requests complejos —con headers, cookies de sesión, CSRF tokens o múltiples parámetros POST— sin reconstruirlos a mano. FFUF permite fuzzar una request real exportada de Burp (-request) y asignar una wordlist independiente a cada keyword; alternativamente, enrutando todo el tráfico de FFUF por el proxy de Burp se obtiene historial completo, replay en Repeater e interceptación de requests generados.

2. High-Impact Syntax & Command Cheatsheet

Método 1: fuzzing de una request exportada de Burp

FFUF fuzza una request HTTP completa en lugar de construir la URL. Útil cuando la app exige headers numerosos, cookies, tokens CSRF o formatos custom.

Paso 1 — capturar. En Burp, hacer clic derecho sobre la request → Save Item, o copiar la request cruda a un fichero:

POST /login HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Cookie: session=abc123

username=FUZZUSR&password=FUZZPW

Los valores a fuzzear se sustituyen por keywords propias (FUZZUSR, FUZZPW), no por la FUZZ por defecto, cuando hay más de una variable.

Paso 2 — ejecutar FFUF con -request:

ffuf -request request.txt \
  -w usernames.txt:FUZZUSR \
  -w passwords.txt:FUZZPW \
  -request-proto http
#   -request <file>      -> carga la request raw exportada de Burp
#   -w <wordlist>:<KEYWORD> -> asigna un diccionario a cada keyword del request
#   -request-proto http  -> fuerza HTTP (o https) como protocolo de la request

Cada keyword se sustituye por los valores de su wordlist; todos los headers y cookies se conservan tal cual fueron capturados.

Método 2: enrutar FFUF por el proxy de Burp

Configurar el proxy. En Burp: crear un Proxy Listener (host/puerto), y en Request Handling definir el destination host/port hacia la app objetivo. Burp actúa como proxy transparente entre FFUF y el target.

Apuntar FFUF al listener:

ffuf -u http://127.0.0.1:8080/FUZZ -w wordlist.txt
#   127.0.0.1:8080 es el listener del proxy de Burp
#   Burp reenvía cada request al destino configurado en Request Handling

Fuzzing multi-variable (login, auth de API, tokens)

ffuf \
  -request login.txt \
  -request-proto http \
  -w users.txt:FUZZUSR \
  -w passwords.txt:FUZZPW
#   Cada keyword usa su diccionario: combinaciones usuario/contraseña reales,
#   no una sola palabra repetida (producto cartesiano de ambas listas)

3. Real-World Offensive/Defensive Scenarios

Fuzzing de formularios autenticados sin romper la sesión. La request capturada conserva Cookie, CSRF y Authorization: fuzzear -request mantiene intacta la sesión en cada intento, algo imposible de replicar con una URL sola.

Depuración de respuestas anómalas. Con Burp como proxy intermedio, cada request generado queda en Proxy History: se inspecciona el request exacto que produjo un resultado raro, se envía a Repeater/Intruder/Comparer/Decoder para análisis, y se puede interceptar un request de FFUF y modificar headers/cookies/tokens antes de reenviarlo — útil para verificar que la autenticación viaja bien en los fuzzings de login.

Multi-keyword para auth y endpoints de API. -w users.txt:FUZZUSR -w passwords.txt:FUZZPW prueba combinaciones reales sobre el formulario de login; la misma técnica fuzzea tokens y parámetros de APIs autenticadas sin perder los headers de sesión.

Flujo de trabajo típico

1. Navegar la app en Burp y capturar la request que representa la funcionalidad a fuzzear.
2. Guardar la request cruda a un fichero (Save Item o copia manual).
3. Sustituir los valores a probar por keywords descriptivas (FUZZUSER, FUZZPASS, FUZZTOKEN).
4. Ejecutar FFUF con -request (o apuntar -u al listener de Burp).
5. Enviar los hallazgos interesantes a Repeater/Intruder para validación manual.

Best practices

• Exportar requests reales desde Burp en lugar de reconstruirlas a mano.
• Keywords descriptivas cuando haya varias wordlists.
• Enrutar por Burp cuando las respuestas sean anómalas o haya que depurar autenticación.
• Preservar cookies, headers de auth y tokens CSRF de la request capturada.
• Validar con Repeater cualquier respuesta interesante antes de escalarla.

Defensa

La combinación es indetectable por firma (tráfico HTTP normal con sesión real), pero deja patrones de comportamiento: ráfagas de requests a una misma ruta con payloads distintos, y volúmenes altos de login. Las defensas efectivas son el rate-limit por sesión/IP en endpoints de auth, CAPTCHA en login, validación de parámetros (no procesar campos desconocidos), y la monitorización de logs por ráfagas de requests que comparten el mismo Cookie con parámetros variables — la firma exacta de un fuzzing autenticado vía -request.