Qué es un proxy

Se trata de una herramienta que sirve para posicionarse entre el tráfico de dos partes. Este principio es el mismo que se encuentra detrás de los famosos ataques Man in the Middle (MITM), sin embargo sus usos son mucho más amplios, ya que también son el fundamento de las herramientas que nos permiten realizar análisis web, mostrándonos la estructura en texto plano de las peticiones HTTP, en donde podremos registrar, detener, modificar y reenviar estas peticiones para entender los comportamientos de las aplicaciones y servidores. Además, los proxies tienen funciones muy relevantes en el enrutamiento del tráfico, ya sea en balanceadores de carga (los cuales tienen mucha importancia en la distribución del tráfico, para evitar sobrecargas en los servidores) o en la implementación de Web Application Firewalls (WAF). Es muy importante distinguir la diferencia entre proxy y VPN, en donde el proxy no encripta el tráfico, mientras que la VPN funciona de manera similar pero bajo un túnel encriptado.

Podemos definir estos dos tipos de proxy:

• Forward proxy: Se posiciona en el cliente. Es decir, entre el navegador y su salida al internet.
• Reverse proxy: Se encuentra en el lado del servidor. Recibe las peticiones de internet y las reparte en los servidores finales donde se encuentran los backend con las lógicas del sitio. Un balanceador de carga o un WAF trabajan de esta manera.

Para el propósito de estas guías, nos interesa un caso puntual del primero. Existen múltiples herramientas que actúan como un proxy local, entre el navegador y el internet, permitiendo analizar el flujo de tráfico web y realizar distintas pruebas abriendo la puerta de un estudio más granular y con mayor capacidad del sitio web al no estar restringido por las definiciones del front-end. Con ello, podremos estudiar el comportamiento de un sitio web a plenitud.

Burp Suite — Primeros pasos

Burp Suite (PortSwigger), se trata justamente de un proxy local con múltiples herramientas que nos ayudan en el análisis del tráfico web. En muchos sentidos es una navaja suiza, ya que además del set de herramientas que trae por defecto, es extensible mediante una tienda o mediante la API que trae incorporada. Existen varias versiones de pago con funcionalidades muy prácticas para el trabajo profesional, aunque la edición Community es gratuita y suficiente para aprender todo lo que necesitamos.

Se descarga desde el siguiente Link. Hay dos formas de instalarlo:

• Instalador de plataforma (Windows, Linux, macOS): trae su propio Java empaquetado, así que no necesitas instalar nada más.
• JAR independiente: requiere que tengas Java 21 o superior instalado, y se lanza con

$ java -jar burpsuite_community.jar

Configurando el navegador

Por defecto el Proxy de Burp se configura en 127.0.0.1:8080. Para que tu tráfico pase por ahí tienes dos caminos:

• El navegador de Burp: Burp incluye un Chromium integrado (Proxy → Intercept → Open Browser) que ya viene preconfigurado, con el proxy y el certificado listos. Es la forma más rápida de empezar.
• Tu navegador externo: En las configuraciones de red, puedes definir 127.0.0.1:8080 como proxy HTTP. Cambiar esto a mano cada vez es incómodo, así que se recomienda el uso de una extensión que alterna el proxy con un solo clic.

Esa extensión es FoxyProxy, disponible para Firefox y Chrome. Creas un perfil que apunte a 127.0.0.1:8080 y lo activas o desactivas desde la barra de herramientas cuando quieras interceptar.

Con esto el tráfico HTTP ya pasa por Burp. Pero en cuanto entres a un sitio HTTPS, el navegador te va a mostrar en la pantalla las advertencias del certificado. Eso no es un fallo: es exactamente la teoría del capítulo anterior funcionando, y toca resolverla.

El certificado

En el manual de HTTPS viste que un navegador solo confía en un certificado si lo firma una autoridad de certificación (CA) que ya está en su almacén de confianza. Un proxy de interceptación es, por definición, un Man in the Middle: rompe el túnel TLS. Por este motivo, Burp tiene que presentarte un certificado del sitio que estás visitando firmado por su propia CA.

Esa CA no está en tu almacén de confianza, así que el navegador hace bien en desconfiar. La solución es instalar deliberadamente la CA de Burp como autoridad de confianza:

• Con Burp corriendo y el proxy configurado en tu navegador, entra a http://burp (o http://burpsuite o http://127.0.0.1:8080) y pulsa CA Certificate. Con ello se descarga un archivo en formato .der.

• En Firefox: Ajustes → Privacidad y seguridad → Certificados → Ver certificados → Autoridades → Importar, seleccionas el archivo y marcas "Este certificado puede identificar sitios web".
• En Chrome: usa el almacén del sistema operativo (salvo en Linux, donde se importa en la pestaña Authorities). Por eso en Windows y macOS, instalar la CA en el sistema cubre también a Chrome y a Edge.

Proxy

La pestaña Proxy es aquella en donde podremos interceptar el tráfico del sitio sobre la marcha. Aquí tenemos 3 opciones:

• Intercept on/off: con off, Burp deja pasar todo, pero sigue registrando. Todo el histórico queda en Proxy → HTTP history y es donde podremos revisar a posteriori lo que la aplicación mandó al servidor.
• Forward: la deja seguir hacia el servidor (tras editarla, si quieres). También es posible dejar seguir el tráfico en un grupo de peticiones.
• Drop: descarta la petición, no llega al servidor final.

Es importante mencionar que existen otras funcionalidades a las que se puede acceder con el clic derecho, en donde por ejemplo, podemos interceptar la respuesta también antes de que llegue al navegador. Cabe destacar que en dicho caso, el tráfico ya volvió desde el servidor por lo que dicha modificación afecta solamente a la información que se renderiza en el cliente. Aunque esto puede ser igualmente útil para ciertos análisis que involucran al front-end.

Todo lo que atraviesa el proxy queda guardado en dos historiales que conviene conocer: el HTTP history, con cada petición y respuesta en orden, filtrable y ordenable por dominio, método o código de estado; y el WebSockets history, su equivalente para el tráfico WebSocket. Son el registro de todo lo que la aplicación hizo mientras navegabas y el punto de partida desde el que enviarás peticiones al resto de herramientas.

Desde esta pestaña, podremos enviar las peticiones que nos interesen a las funcionalidades que explicaremos más adelante, como el Repeater o Intruder.

• Match and replace

En los ajustes del Proxy defines reglas de match and replace que reescriben partes de cada petición o respuesta automáticamente al pasar. Cada regla es un patrón (texto o expresión regular) y su reemplazo se puede aplicar tanto en las cabeceras como el cuerpo de estas. Sirve, por ejemplo, para forzar la modificación automática del User-Agent, inyectar una cabecera en todas las peticiones (esto es un requisito para algunos programas de Bug Bounty, muy útil para identificar el tráfico producto de tu investigación), o hacer permanente el reemplazo de recursos JavaScript.

Existe un pequeño truco que es bueno tenerlo a mano. Imagina que un sitio en el cuerpo de la respuesta, realiza un llamado al archivo script.js. Mediante el Match and replace, podemos identificar esa llamada y modificarla por http://localhost:9999/script.js, de tal manera que descargaremos el JavaScript modificando su contenido de la manera que queramos y lo disponibilizaremos mediante un servidor Python local python -m http.server 9999. Con ello podremos modificar la conducta del front-end, permitiendo en algunos casos alcanzar visualmente funciones administrativas, evadir inicios de sesiones incorrectamente implementados, romper encriptaciones a nivel de cliente o definir breakpoints y console.log que pueden ser vistos en la consola del navegador.

• Ajustes del Proxy

El Proxy tiene su propia página de ajustes (Settings → Tools → Proxy). Ahí defines las reglas de interceptación, que deciden qué peticiones se interceptan y cuáles no. Una vez esté configurado el scope, activando la casilla And URL Is in target scope el intercept solo registrará lo que esté dentro del alcance, descartando así el ruido que no nos interesa (analytics, CDNs).

Browser integrado

El Chromium que Burp trae integrado sirve para más que saltarse la configuración de proxy y certificado. Este incluye herramientas adicionales como el DOM Invader. Muy útil para encontrar vulnerabilidades del lado del cliente. Para activarlo, se debe acceder a las herramientas de desarrollo y a la extensión disponible en la barra de herramientas de Chromium.

Su gracia es que instrumenta el DOM en vivo y saca a la superficie lo que normalmente tendrías que rastrear leyendo JavaScript minificado:

• DOM XSS: identifica los sinks controlables de la página y te muestra en qué contexto cae tu input y cómo la aplicación lo sanea (o no).

• Client-side prototype pollution: rastrea automáticamente los vectores de contaminación de prototipos y los conecta con sinks peligrosos.

• DOM clobbering y web messages: registra, modifica y reenvía los mensajes que la página intercambia mediante postMessage().

  No profundizaremos aquí en estas vulnerabilidades (serán descritas en sus respectivos manuales), pero conviene saber que la herramienta existe.

Dashboard

El Dashboard es la interfaz de control de las tareas del proyecto. Su tabla de Tasks lista lo que Burp está haciendo en segundo plano (crawling, escaneos, ataques de Intruder) y permite pausarlas, reanudarlas o revisarlas. Lamentablemente, varias de estas funciones son exclusivas de la versión Professional.

Sin embargo, hay dos paneles que merecen especial atención:

• Event log: el registro de todo lo que ocurre en el proyecto. Es de donde obtendremos información en caso de que algo falle. Muchos problemas se diagnostican aquí.
• All issues: la tabla de vulnerabilidades detectadas, que se va llenando con lo que encuentran los escaneos activos y algunas extensiones. En muchas ocasiones pueden aparecer hallazgos relevantes, así como potenciales líneas de investigación para algunas explotaciones interesantes.

Target

En la pestaña Target, se encuentra una subpestaña site map en la cual se muestra el árbol de todo lo que Burp ha visto del sitio (rutas, parámetros, respuestas, etc.) y que se va llenando a medida que navegas por la aplicación.

Luego, existe una segunda subpestaña, señalada como scope. Puedes definir qué dominios entran en la auditoría para que el resto (analytics, CDNs, dominios de terceros) desaparezca del ruido. En una auditoría real, el scope es lo que te mantiene dentro de lo autorizado; mandar peticiones a un dominio fuera de alcance podría tener incluso repercusiones legales. Configurarlo bien es lo primero que se hace. Sin embargo, se debe considerar que al excluir el scope algunas peticiones pueden pasar desapercibidas, de tal manera que la recomendación es primero generar tráfico de manera pasiva para entender a qué dominios se realizan llamadas y luego configurar el scope mediante listas blancas con los dominios de interés, para finalmente enviar tráfico manipulado.

Para un control fino, activa Use advanced scope control: en vez de una lista simple de dominios, defines reglas con expresiones regulares sobre el protocolo, el host, el puerto y la ruta. Por ejemplo, para incluir un dominio y todos sus subdominios pondrías en el campo Host una regla como ^(.*\.)?ejemplo\.com$, y para sacar del alcance un subdominio irrelevante, una regla de exclusión con ^analytics\.ejemplo\.com$.

Recuerda que luego de añadir y excluir los dominios del scope, debes volver a la configuración del proxy para definir si quieres interceptar o no las peticiones realizadas a estos.

Repeater

Esta es la principal herramienta de ataque y análisis. Puedes enviar cualquier petición desde cualquier pestaña con Ctrl+R. Luego, la editas y la reenvías cuantas veces quieras, viendo la respuesta al lado. Cada petición vive en su pestaña, con su historial de cambios, así que puedes ir y volver entre peticiones sin perder nada.

Es donde ocurre el trabajo manual fino: cambiar un parámetro y ver qué responde el servidor, probar un payload de inyección, recorrer un proceso de varios pasos. Todo lo que en los próximos manuales harás para confirmar una vulnerabilidad, una SQLi, un IDOR, un XXE, lo probarás aquí.

En las últimas versiones de Burp, se han añadido algunas funcionalidades adicionales, muy útiles para probar condiciones de carrera, en donde es posible enviar grupos de peticiones, sincronizadas en el último byte. No entraremos en detalle ahora, pero te recomiendo los siguientes artículos de PortSwigger:

• Peticiones en grupo
• Single Packet Attack

Finalmente, una última función a la cual poner atención, es al Inspector. Se trata de un panel lateral en donde se pueden modificar ciertos atributos de las peticiones con las que se está trabajando, tales como la versión del protocolo (HTTP 1.1 o 2), algunas codificaciones, cabeceras, entre otros.

Intruder

Cuando quieres repetir una petición muchas veces cambiando algo en cada una, como por ejemplo, probar mil contraseñas, recorrer IDs, fuzzear un parámetro, etc. Usas el Intruder. Para ello, marcas la posición de la petición que quieres atacar encerrándola en el símbolo §, luego defines la lista de payloads que quieres utilizar (Burp ofrece varias listas predeterminadas para distintos tipos y propósitos de ataques). También puedes configurar el resource pool, para calibrar la cantidad de tráfico que quieres enviar por unidad de tiempo.

Los modos de ataques se resumen en la siguiente tabla:

┌───────────────┬──────┬──────────────────────────────────────────────────────┐
│ Ataque        │ Sets │ Descripción                                          │
├───────────────┼──────┼──────────────────────────────────────────────────────┤
│ Sniper        │ 1    │ Uno por posición, de a una posición a la vez         │
│ Battering ram │ 1    │ El mismo payload en todas las posiciones simultáneas │
│ Pitchfork     │ N    │ Un set por posición, avanzan en paralelo             │
│ Cluster bomb  │ N    │ Un set por posición, todas las combinaciones         │
└───────────────┴──────┴──────────────────────────────────────────────────────┘

Con cientos de respuestas, el problema es encontrar la interesante. Para eso están las reglas de Grep:

• Grep — Match: marca las respuestas que contienen una expresión (Welcome, Invalid), y crea una columna con el conteo para ordenarlas.

• Grep — Extract: crea una columna con un dato específico de la respuesta (un token, un nombre), útil para encadenar o para leer resultados de un vistazo.

  Una advertencia: Intruder a máxima velocidad, con listas grandes, genera mucho tráfico. Contra un entorno frágil puede botarlo, y contra uno con WAF generará bloqueos que podrían arruinar el resto de la prueba. La velocidad y el volumen son decisiones: ajústalos al objetivo y a lo que tu autorización y contexto permiten.

El Intruder también permite añadir columnas adicionales mostrando por ejemplo el tiempo de respuesta de una petición. A veces podrías encontrar vulnerabilidades que se manifiesten de maneras invisibles en el contenido, pero que tengan un impacto visible respecto al tiempo que tardan en responder.

Collaborator

Muchas vulnerabilidades no devuelven nada visible en la respuesta: la aplicación procesa tu payload, pero no te muestra el resultado. Se conocen como errores a ciegas (blind) y fuera de banda (out-of-band): un SSRF ciego, un XXE ciego, una inyección SQL que no imprime datos pero sí puede forzar una conexión hacia un servidor externo. Burp Collaborator es justamente eso: un servidor externo que nos permitirá monitorear estas interacciones.

La idea es simple: Collaborator te entrega un dominio único y controlado; tú lo insertas en tus payloads, y si la aplicación o su backend interactúa con dicho dominio, Collaborator lo registra y te avisa. Esa interacción es la prueba de que el payload se ejecutó. Soporta tres protocolos: HTTP/HTTPS, DNS y SMTP, y el de DNS es especialmente valioso: muchos entornos bloquean la salida HTTP pero dejan resolver DNS, y una simple consulta al subdominio ya confirma el fallo. Es una funcionalidad de la versión Professional; por defecto usa el servidor público de PortSwigger (*.oastify.com).

En muchos escenarios trabajarás con una VPN para llegar al dominio analizado. En esos casos, es posible que al ejecutar un payload que incluya un dominio del Collaborator, al enrutar el tráfico por la VPN se podrían realizar consultas DNS en el camino a la aplicación. Queda a tu criterio determinar si esto es producto de una vulnerabilidad o precisamente una conducta normal del enrutamiento, pero debes saber que es algo que puede ocurrir.

Hay dos escenarios donde el servidor público no sirve: una aplicación interna que no tiene salida a internet, o un objetivo que bloquea el dominio de Collaborator. Para eso puedes desplegar tu propio servidor de Collaborator privado. No es un "localhost": necesitas un host alcanzable por el objetivo, con un dominio propio y sus registros DNS; luego configuras Burp apuntando a este dominio en los ajustes. En una auditoría interna, ese host va dentro de la misma red que el objetivo. Con eso recuperas la detección fuera de banda incluso si es que el servidor público queda descartado.

Te dejo el siguiente enlace como referencia: Configuración de servidor Collaborator privado

Sequencer, Comparer, Decoder, Logger y Organizer

Adicionalmente, encontraremos cinco herramientas de apoyo que conviene considerar:

• Sequencer: analiza la entropía de una muestra, tales como tokens de sesión, anti-CSRF, de reset de contraseña, etc. Captura muchos (live capture) y ejecuta una batería de pruebas estadísticas. Si un token de sesión resulta predecible, es un hallazgo grave; volveremos en un futuro manual.
• Comparer: resalta las diferencias entre dos peticiones o respuestas, palabra por palabra o byte por byte. Es lo que usas para ver por qué dos respuestas casi idénticas se comportan distinto: enumeración de usuarios (¿la respuesta a un usuario válido difiere de la de uno inválido?) o SQLi ciega booleana.
• Decoder: codifica y decodifica sobre la marcha (URL, Base64, HTML, hex) y calcula hashes. Para transformaciones rápidas sin salir de Burp.
• Logger: registra todo el tráfico HTTP que genera Burp, no solo el del navegador. A diferencia del HTTP history del Proxy, que solo ve lo que pasa por el navegador, el Logger incluye las peticiones del Scanner, del Intruder y de las extensiones.
• Organizer: un cajón para guardar peticiones interesantes y volver a ellas después (Ctrl+O). Le añades notas y un estado, sin sacarla de su contexto.

Macros y session handling

Durante las auditorías y particularmente al llevar a cabo procesos automatizados, nos encontraremos con una dificultad, la sesión caduca o a veces las peticiones pueden ser llevadas a cabo una sola vez, por ejemplo, producto de tókenes CSRF. Para ello, Burp tiene varias soluciones.

• Macros: una secuencia grabada de peticiones que Burp puede reproducir para obtener una sesión fresca.
• Session handling rules: reglas que, sobre el tráfico de las herramientas que elijas, ejecutan acciones automáticas: comprobar si la sesión sigue viva, y si no, correr una macro para re-loguearse, actualizar las cookies desde el cookie jar y refrescar tokens CSRF antes de reenviar.

Bien configurado, esto es lo que hace posible auditar la zona autenticada de una aplicación sin re-loguearte a mano cada pocos minutos. Es tedioso de montar la primera vez y transforma por completo lo que puedes automatizar.

Hay además una vía más visual para el mismo problema del login, pensada para los escaneos autenticados: las secuencias de login grabadas (recorded login sequences). Con la extensión Login Recorder, grabas tu inicio de sesión interactuando con el sitio en el navegador, y Burp genera un guion que luego reproduce para mantenerse autenticado durante un escaneo. Es una funcionalidad de la versión Professional, pero una excelente alternativa cuando el login es demasiado complejo para automatizarlo a mano.

Extensiones

Tal como mencionábamos al comienzo, Burp es una herramienta extensible. Encontraremos una BApp Store (Extensions → BApp Store), que se trata de un catálogo de usuarios que PortSwigger revisa (pero no garantiza ni mantiene). Algunas están escritas en Java propiamente tal, aunque puedes encontrar varias otras en Python (que requiere el ambiente Jython) o en Ruby (con su respectivo JRuby). Personalmente, te listo a continuación mis favoritas, aunque te sugiero explorar tanto en estas como en otras que pueden estar disponibles en el Store o en repositorios externos. ¡También puedes crear las tuyas!

• JWT Editor: detecta y edita JSON Web Tokens, los firma o cifra, y automatiza ataques conocidos contra su implementación.
• Autorize: reenvía automáticamente cada petición con la sesión de un usuario de menos privilegios y compara, para detectar fallos de autorización (IDOR, controles de acceso rotos, etc.).
• Awesome TLS: reescribe el fingerprint TLS (JA3) y el orden de las cabeceras de Burp para que se parezca a un navegador real. Muy útil contra algunos WAF que restringen el uso de proxies y podrían generar problemas al ejecutar Burp.
• Active Scan++: un potenciador para el escáner activo (se recomienda tener mucho cuidado con esta, ya que es particularmente ruidosa y disruptiva).
• Turbo Intruder: un motor de fuzzing que manda cantidades enormes de peticiones a gran velocidad, configurado con Python. Importa conocerlo sobre todo en la edición Community, donde el Intruder normal viene ralentizado a propósito: Turbo Intruder no arrastra esa limitación. Al igual que el Active Scan++, se debe usar con especial cuidado ya que puede ser incluso más potente que el Intruder de la versión Professional, lo cual puede derivar en una disrupción del servicio.
• Param Miner: descubre parámetros y cabeceras ocultos que la aplicación acepta pero no documenta.
• HTTP Request Smuggler: detecta y explota HTTP request smuggling (desincronización en HTTP/1.1 y por downgrade de HTTP/2).
• InQL: escáner y editor para GraphQL; enumera el esquema por introspección y facilita atacar sus endpoints.
• Hackvertor: es como un Decoder pero con esteroides y por etiquetas: codifica, decodifica, cifra y hashea payloads con etiquetas tipo XML que se pueden anidar. Útil para construir cargas complejas y para dejar documentado, de forma legible, qué transformación aplicas.
• Wsdler: parsea definiciones WSDL para trabajar servicios SOAP, generando la estructura de estas peticiones.
• ViewState Editor: inspecciona y edita el ViewState de aplicaciones ASP.NET.
• Brida: puente entre Burp y Frida, para llevar este mismo flujo al análisis de aplicaciones móviles.
• MCP Server: expone Burp a un cliente de IA mediante el Model Context Protocol, de modo que un asistente pueda consultar el historial, mandar peticiones o generar payloads de Collaborator. Es la puerta de Burp al trabajo asistido por IA.

Settings

En el apartado de Settings, existen muchas opciones para distintos escenarios que te recomiendo explorar; sin embargo, en esta oportunidad no nos detendremos en cada una de ellas. En cambio, mencionaremos dos configuraciones que tienen especial relevancia en el trabajo práctico.

En primer lugar, debemos entender que Burp negocia por defecto bajo el protocolo HTTP/2 cuando el servidor lo soporta, y a veces eso puede generar errores inesperados. Cuando esto sucede, conviene mirar con qué protocolo estás trabajando y, si hace falta, forzar la versión: desde el Inspector del Repeater podemos confirmar que el error viene del uso de esta versión del protocolo y para automatizar esta solución, existe la siguiente configuración para deshabilitar la versión 2.

En segundo lugar, te encontrarás en algunas situaciones en donde debas llegar a aplicaciones alojadas en redes internas. Para ello, en el menú Network, en Connections puedes enrutar todo el tráfico de Burp por un proxy SOCKS. De esta forma, se levanta un túnel SSH que abre un SOCKS local (ssh -D 1080 usuario@IP-servidor), y configuras Burp para atravesar dicho túnel en la dirección 127.0.0.1:1080, luego marcas Do DNS lookups over SOCKS proxy para que también la resolución del DNS viaje por aquí.

Alternativas — ZAP y Caido

Burp no es la única herramienta que hay, de hecho existe una alternativa muy conocida entre veteranos llamada ZAP (antiguamente OWASP ZAP). Así también y de manera novedosa, Caido es otra alternativa más moderna. En ambos casos, personalmente no considero que ninguna llegue al potencial que tiene Burp, este sigue siendo el rey, sin embargo, siempre pueden existir escenarios en los que Burp no sea una opción y debamos decantar por alternativas que más vale conocer.

• ZAP (Zed Attack Proxy): tiene la gracia de ser de código abierto y desarrollado actualmente por Checkmarx. Cubre lo mismo, proxy MITM, scan pasivo y activo, spider, automatización por API, etc. Es la elección natural cuando no hay licencia de Burp Professional.
• Caido: una alternativa más reciente, con filtrado de tráfico por consultas (HTTPQL) y automatización por flujos. Vale la pena tenerla en el radar si el volumen de peticiones de Burp se te hace lento de navegar.

La herramienta es secundaria; el criterio es lo que importa. Quien entiende qué es interceptar, reescribir y mantener una sesión, lo aplica en cualquiera de las tres.

Trabajando con las DevTools

A veces no puedes instalar nada: una máquina ajena, un entorno restringido, un navegador sin permisos. Para eso tenemos el plan B, que vive en las DevTools del propio navegador.

En Firefox, en la pestaña Red, haces clic derecho sobre una petición → Edit and Resend (o el botón Resend): entra un modo de edición donde cambias método, URL, cabeceras y cuerpo, y la reenvías. Es un Repeater pobre pero funcional, sin proxy ni certificado. En Chrome no hay un equivalente tan directo; lo más cómodo es Copy as fetch, editar la llamada y ejecutarla en la consola.

No reemplaza a Burp, no interceptas al vuelo ni automatizas, pero te saca del apuro cuando el entorno no te deja montar el set de herramientas de trabajo completo.