Manual de Burp Suite Community Edition
Capítulo 4 · Proxy a fondo: interceptar, modificar y reenviar
Serie: Burp Suite desde cero | unfantasmaenelsistema.com
En el capítulo 2 vimos lo esencial de Proxy: activar Intercept, ver una petición retenida, y HTTP history como registro completo. Este capítulo profundiza en las tres cosas que se hacen de verdad con Proxy día a día: modificar una petición antes de que salga, filtrar el ruido de un histórico que crece muy rápido, y automatizar sustituciones repetitivas con reglas de Match and replace.
Qué aprenderás en este capítulo
Cómo editar una petición retenida en Intercept antes de reenviarla · La diferencia entre Forward y Drop, y cuándo usar cada uno · Cómo filtrar HTTP history para encontrar solo lo que te interesa · Qué son las reglas de Match and replace y para qué sirven las que trae Burp por defecto
1. Editar una petición retenida
Cuando Intercept está activado, la petición retenida se muestra en un editor de texto (pestañas Pretty / Raw / Hex) que es completamente editable. Puedes cambiar cualquier cosa: el método, la ruta, una cabecera, una cookie, el cuerpo de un POST. Nada se envía al servidor hasta que pulsas Forward -y hasta entonces puedes deshacer, volver a editar o directamente descartar la petición con Drop.
Una petición retenida en Intercept: todo el panel Request es editable antes de reenviarla
Un ejemplo típico de por qué esto importa: imagina que quieres comprobar si Juice Shop distingue su comportamiento según el idioma declarado en `Accept-Language`, o si una cookie de sesión concreta es realmente necesaria para que una petición tenga éxito. Ambas preguntas se responden igual: editas el valor en el panel Request, pulsas Forward, y comparas la respuesta con la que obtenías antes del cambio. Es el mismo principio -cambiar un dato y observar la reacción del servidor- que vamos a aplicar una y otra vez en el resto del manual, primero a mano en Intercept y más adelante, de forma mucho más cómoda, con Repeater (capítulo 7).
Un truco práctico: no todo tiene que pasar por Intercept
Retener cada petición manualmente es lento y solo tiene sentido cuando quieres examinar o modificar algo puntual. Para el trabajo normal de navegar y dejar que Burp registre todo, la rutina habitual es: Intercept off, navegas con normalidad, y luego revisas y modificas lo que haga falta desde HTTP history, enviando la petición concreta a Repeater con el botón derecho.
2. Forward, Drop, y qué pasa con las que no tocas
| Acción | Qué hace |
|---|---|
| Forward | Deja pasar la petición retenida hacia el servidor -con los cambios que hayas hecho, si los hay- |
| Drop | Descarta la petición: nunca llega al servidor. Útil para probar cómo reacciona la aplicación cuando una llamada esperada simplemente no ocurre |
| Intercept on/off | Decide si las peticiones futuras se quedan retenidas (on) o pasan directas sin pausa, quedando igualmente registradas en HTTP history (off) |
3. Filtrar HTTP history
Con Juice Shop cargado, el histórico crece con cada petición de imagen, cada llamada de fondo del framework, cada comprobación de sesión. El icono de embudo ("Filter settings") junto al encabezado de HTTP history deja quitar de en medio ese ruido: ocultar CSS e imágenes, filtrar por código de estado, por extensión, o por texto libre en la URL.
La combinación que más se usa en la práctica es simple: esconder CSS/imágenes/fuentes, y dejar visibles solo las peticiones con método POST/PUT/DELETE o con extensión .json -es decir, las que casi siempre importan cuando estás analizando funcionalidad en vez de simplemente navegando.
4. Match and replace: sustituciones automáticas
Match and replace aplica una regla de "si ves esto, sustitúyelo por esto otro" a todo el tráfico que pasa por Burp, sin que tengas que interceptar nada a mano. Burp trae ya varias reglas preparadas (desactivadas por defecto) que sirven como buen ejemplo de para qué se usa esto en la práctica:
Reglas de Match and replace incluidas por defecto en Burp: emular distintos navegadores, ocultar el Referer, forzar respuestas sin caché
| Regla de ejemplo | Para qué sirve |
|---|---|
| Emulate Edge / iOS / Android | Cambia el User-Agent de cada petición, para ver si la aplicación sirve contenido distinto (o comprueba peor las cosas) según el dispositivo que declaras |
| Require non-cached response (If-Modified-Since / If-None-Match) | Elimina las cabeceras de caché condicional, forzando que el servidor responda siempre con el contenido completo en vez de un 304 |
| Hide Referer header | Quita la cabecera Referer de las peticiones salientes, útil para comprobar si algún endpoint depende de ella para funcionar (una mala práctica de seguridad frecuente) |
Puedes crear tus propias reglas con el botón Add: por ejemplo, sustituir automáticamente el valor de un parámetro en cada petición a un endpoint concreto, para no tener que editarlo a mano en Intercept cada vez. En Community, las reglas trabajan sobre texto y expresiones regulares simples; la automatización más avanzada (condicional, con lógica) es terreno de las extensiones que vemos en el capítulo 10.
Conclusión
Con Intercept para pausar y editar, HTTP history filtrado para no perderte en el ruido, y Match and replace para automatizar sustituciones repetitivas, ya tienes el control completo sobre el tráfico que pasa por Burp.
Los próximos dos capítulos aplican exactamente estas herramientas a los flujos que vas a auditar una y otra vez en cualquier aplicación real: un formulario de login, uno de registro, y los formularios de contacto y dirección.
unfantasmaenelsistema.com | Seguridad, sistemas y todo lo que no debería funcionar (pero funciona)