Burp Suite: cómo analizar aplicaciones web con ejemplos de consola

 

Burp Suite es una de las herramientas más utilizadas en auditorías de seguridad web, pruebas de penetración y programas de bug bounty. Su función principal es actuar como un proxy intermediario entre el navegador y una aplicación web, permitiendo observar, modificar y repetir las solicitudes HTTP y HTTPS.

A diferencia de un navegador convencional, Burp Suite muestra con precisión qué información se envía al servidor: encabezados, cookies, parámetros, tokens, cuerpos JSON, formularios y respuestas.

En este artículo veremos qué es Burp Suite, cuáles son sus módulos principales y cómo integrarlo con herramientas de consola como curl, Java y Python.

Todos los ejemplos deben ejecutarse exclusivamente sobre sistemas propios, laboratorios controlados o aplicaciones para las que se tenga autorización expresa.

¿Qué es Burp Suite?

Burp Suite es una plataforma creada para evaluar la seguridad de aplicaciones web. Dispone de una edición Community gratuita y una edición Professional con funciones adicionales de automatización.

El flujo normal de trabajo es el siguiente:

  1. El navegador envía una solicitud.
  2. Burp Suite intercepta la comunicación.
  3. El auditor examina o modifica la solicitud.
  4. Burp envía la solicitud al servidor.
  5. La respuesta vuelve a pasar por Burp Suite.
  6. El auditor analiza el comportamiento de la aplicación.

De esta manera, es posible estudiar cómo funciona una aplicación sin limitarse únicamente a lo que muestra su interfaz gráfica.

Principales módulos de Burp Suite

Proxy

Proxy es el módulo encargado de interceptar el tráfico entre el cliente y el servidor. Permite detener una solicitud antes de que llegue a la aplicación.

Desde este módulo se pueden analizar elementos como:

  • Métodos HTTP.
  • Parámetros GET y POST.
  • Cookies de sesión.
  • Tokens de autenticación.
  • Encabezados personalizados.
  • Contenido JSON.
  • Solicitudes de APIs.

Una solicitud interceptada podría verse así:

POST /login HTTP/1.1
Host: laboratorio.local
Content-Type: application/x-www-form-urlencoded
Content-Length: 31

username=usuario&password=clave

Antes de reenviarla, Burp permite modificar cualquiera de esos valores.

HTTP History

La sección HTTP History conserva un registro del tráfico que pasó por el proxy.

Incluso cuando la interceptación está desactivada, Burp puede seguir registrando las solicitudes realizadas por el navegador.

Este historial permite identificar:

  • Endpoints de una aplicación.
  • Parámetros utilizados.
  • Llamadas a APIs.
  • Archivos JavaScript.
  • Redirecciones.
  • Errores del servidor.
  • Solicitudes realizadas en segundo plano.

Repeater

Repeater permite enviar una misma solicitud varias veces, realizando pequeñas modificaciones en cada intento.

Por ejemplo, podemos observar el comportamiento de un endpoint local:

GET /perfil?id=10 HTTP/1.1
Host: laboratorio.local
Cookie: session=valor_de_prueba

Después podemos cambiar el identificador:

GET /perfil?id=11 HTTP/1.1
Host: laboratorio.local
Cookie: session=valor_de_prueba

El objetivo es comprobar si el servidor valida correctamente que el usuario autenticado tenga permiso para acceder al recurso solicitado.

Repeater es especialmente útil para analizar:

  • Controles de acceso.
  • Validación de parámetros.
  • Manejo de errores.
  • Sesiones.
  • APIs REST.
  • Encabezados HTTP.
  • Respuestas diferentes ante pequeñas modificaciones.

Decoder

Decoder permite codificar y decodificar información en diferentes formatos.

Algunos de los más frecuentes son:

  • URL encoding.
  • Base64.
  • Hexadecimal.
  • HTML entities.
  • Cadenas binarias.

Ejemplo de una cadena codificada en Base64:

YWRtaW46cGFzc3dvcmQ=

En Linux puede decodificarse desde la consola:

echo "YWRtaW46cGFzc3dvcmQ=" | base64 -d

Resultado:

admin:password

Base64 no es cifrado. Es solamente un sistema de representación de datos y puede revertirse fácilmente.

Comparer

Comparer permite comparar dos solicitudes o respuestas y resaltar sus diferencias.

Puede resultar útil cuando una aplicación devuelve respuestas muy similares, pero cambia determinados elementos según:

  • El usuario autenticado.
  • El parámetro enviado.
  • El estado de la sesión.
  • Los permisos disponibles.
  • La validez de un token.

Intruder

Intruder automatiza el envío de múltiples variaciones de una solicitud.

Puede emplearse en un entorno autorizado para comprobar:

  • Validación de entradas.
  • Comportamiento ante diferentes identificadores.
  • Límites de longitud.
  • Parámetros opcionales.
  • Controles de velocidad.
  • Respuestas ante datos inesperados.

La edición Community limita la velocidad de este módulo. Para pruebas iniciales, Repeater suele ser más apropiado porque ofrece mayor control sobre cada solicitud.

Ejecutar Burp Suite desde la consola

Cuando Burp Suite se distribuye como archivo JAR, puede iniciarse utilizando Java.

java -jar burpsuite_community.jar

También se puede asignar una cantidad determinada de memoria:

java -Xmx2G -jar burpsuite_community.jar

En este ejemplo, Java puede utilizar hasta dos gigabytes de memoria.

Para verificar la instalación de Java:

java -version

Una salida posible sería:

openjdk version "21"
OpenJDK Runtime Environment
OpenJDK 64-Bit Server VM

La versión exacta dependerá del sistema operativo y de la instalación disponible.

Enviar tráfico de curl a través de Burp Suite

Burp no solo puede interceptar solicitudes realizadas desde un navegador. También puede recibir tráfico generado desde la consola.

Por defecto, el proxy suele escuchar en:

127.0.0.1:8080

Podemos enviar una solicitud HTTP mediante curl:

curl -x http://127.0.0.1:8080 http://laboratorio.local

La opción -x indica el proxy que utilizará curl.

Si la interceptación está activada, la solicitud aparecerá en:

Proxy > Intercept

Para mostrar también los encabezados de la respuesta:

curl -i -x http://127.0.0.1:8080 http://laboratorio.local

Para obtener información detallada sobre la conexión:

curl -v -x http://127.0.0.1:8080 http://laboratorio.local

La opción -v activa el modo verbose y muestra datos como:

  • Dirección de conexión.
  • Encabezados enviados.
  • Encabezados recibidos.
  • Redirecciones.
  • Negociación del protocolo.
  • Información TLS.

Interceptar una solicitud HTTPS con curl

Para enviar tráfico HTTPS a través de Burp Suite:

curl -x http://127.0.0.1:8080 https://laboratorio.local

En un laboratorio puede aparecer un error relacionado con el certificado de Burp. Para una prueba controlada es posible utilizar:

curl -k -x http://127.0.0.1:8080 https://laboratorio.local

La opción -k desactiva la validación del certificado TLS.

No debe utilizarse como configuración permanente, porque elimina una verificación de seguridad importante. Una solución más correcta consiste en exportar el certificado de la autoridad certificadora de Burp y configurarlo como certificado confiable únicamente en el entorno de pruebas.

Enviar una solicitud POST desde la consola

Supongamos que existe un formulario de laboratorio en:

http://laboratorio.local/login

Podemos enviar datos utilizando curl:

curl -x http://127.0.0.1:8080 \
  -X POST \
  -d "username=usuario&password=clave" \
  http://laboratorio.local/login

La solicitud aparecerá en Burp con una estructura similar a esta:

POST /login HTTP/1.1
Host: laboratorio.local
Content-Type: application/x-www-form-urlencoded
Content-Length: 31

username=usuario&password=clave

También podemos enviar datos JSON:

curl -x http://127.0.0.1:8080 \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"username":"usuario","password":"clave"}' \
  http://laboratorio.local/api/login

Burp mostrará el cuerpo JSON y permitirá modificarlo antes de que llegue al servidor.

Enviar encabezados personalizados

Los encabezados HTTP pueden controlarse desde la consola mediante la opción -H.

curl -x http://127.0.0.1:8080 \
  -H "User-Agent: Laboratorio-Seguridad" \
  -H "X-Test: prueba-controlada" \
  http://laboratorio.local

La solicitud interceptada contendrá:

User-Agent: Laboratorio-Seguridad
X-Test: prueba-controlada

Esto permite estudiar si una aplicación cambia su comportamiento según determinados encabezados.

Trabajar con cookies

Para enviar una cookie manualmente:

curl -x http://127.0.0.1:8080 \
  -b "session=valor_de_laboratorio" \
  http://laboratorio.local/perfil

Para guardar las cookies recibidas:

curl -x http://127.0.0.1:8080 \
  -c cookies.txt \
  http://laboratorio.local/login

Para reutilizarlas posteriormente:

curl -x http://127.0.0.1:8080 \
  -b cookies.txt \
  http://laboratorio.local/perfil

Este procedimiento puede ayudar a entender cómo una aplicación administra sesiones, siempre dentro de un entorno autorizado.

Crear un servidor web local para practicar

Podemos iniciar un servidor HTTP básico con Python:

mkdir laboratorio-burp
cd laboratorio-burp
echo "<h1>Laboratorio local</h1>" > index.html
python3 -m http.server 8000

El servidor estará disponible en:

http://127.0.0.1:8000

Podemos enviar una solicitud a través de Burp:

curl -x http://127.0.0.1:8080 http://127.0.0.1:8000

Si el proxy no intercepta correctamente el tráfico dirigido a localhost, puede utilizarse la dirección IP de la interfaz de red del equipo o revisar la configuración de exclusión de proxy de la herramienta utilizada.

Para consultar las direcciones IP en Linux:

ip address

Para consultar información de red en Windows:

ipconfig

Configurar variables de proxy en Linux

Algunas herramientas de consola reconocen las variables http_proxy y https_proxy.

export http_proxy="http://127.0.0.1:8080"
export https_proxy="http://127.0.0.1:8080"

Después de configurarlas, determinadas aplicaciones enviarán automáticamente su tráfico mediante Burp.

Podemos comprobarlas con:

echo $http_proxy
echo $https_proxy

Para eliminarlas:

unset http_proxy
unset https_proxy

Estas variables no son respetadas por todas las aplicaciones. Algunas herramientas requieren configurar el proxy mediante parámetros propios.

Ejemplo de análisis de una API

Supongamos que tenemos una API local con el siguiente endpoint:

http://laboratorio.local/api/productos/10

Podemos consultar el recurso mediante:

curl -x http://127.0.0.1:8080 \
  -H "Accept: application/json" \
  http://laboratorio.local/api/productos/10

Una respuesta podría ser:

{
  "id": 10,
  "nombre": "Producto de prueba",
  "precio": 1500
}

Desde HTTP History podemos enviar la solicitud a Repeater y modificar el identificador:

GET /api/productos/11 HTTP/1.1
Host: laboratorio.local
Accept: application/json

Durante una auditoría autorizada se analizaría si la aplicación:

  • Valida correctamente el identificador.
  • Controla los permisos del usuario.
  • Expone información innecesaria.
  • Devuelve errores demasiado detallados.
  • Utiliza métodos HTTP de manera segura.
  • Aplica límites de velocidad.

Guardar una solicitud de Burp para analizarla

Burp Suite permite copiar solicitudes completas. También podemos guardar manualmente una solicitud HTTP en un archivo:

nano solicitud.txt

Contenido:

GET /api/perfil HTTP/1.1
Host: laboratorio.local
Accept: application/json
Cookie: session=valor_de_prueba
Connection: close

Podemos visualizarla desde la consola:

cat solicitud.txt

O buscar determinados encabezados:

grep -i "cookie" solicitud.txt

También podemos calcular su hash para registrar la evidencia:

sha256sum solicitud.txt

Una salida posible sería:

a7432f4b...  solicitud.txt

El hash permite demostrar si el archivo fue modificado después de su almacenamiento.

Búsqueda de información en respuestas HTTP

Si guardamos una respuesta en un archivo:

curl -x http://127.0.0.1:8080 \
  http://laboratorio.local \
  -o respuesta.html

Podemos buscar palabras específicas:

grep -i "error" respuesta.html

Buscar direcciones de correo:

grep -Eio '[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}' respuesta.html

Buscar rutas de APIs dentro de código JavaScript o HTML:

grep -Eo '/api/[A-Za-z0-9_/?=&.-]+' respuesta.html

Estos comandos son útiles para organizar información obtenida legítimamente durante una evaluación.

Un flujo de trabajo básico con Burp Suite

Un procedimiento inicial puede organizarse de la siguiente manera:

1. Definir el alcance

Antes de realizar cualquier prueba se debe especificar:

  • Qué dominio puede analizarse.
  • Qué aplicaciones están autorizadas.
  • Qué cuentas pueden utilizarse.
  • Qué técnicas están permitidas.
  • Qué horarios deben respetarse.
  • Qué acciones están prohibidas.

2. Configurar el proxy

El cliente debe enviar el tráfico hacia:

127.0.0.1:8080

3. Navegar por la aplicación

Se recorren manualmente las funciones permitidas:

  • Inicio de sesión.
  • Registro.
  • Perfil.
  • Búsqueda.
  • Formularios.
  • Paneles.
  • APIs.

4. Revisar HTTP History

Se identifican solicitudes relevantes, parámetros y endpoints.

5. Enviar solicitudes a Repeater

Las solicitudes interesantes pueden enviarse haciendo clic con el botón derecho y seleccionando:

Send to Repeater

6. Modificar un elemento por vez

Es recomendable modificar una sola variable en cada prueba. De esa manera se puede determinar qué cambio produjo una respuesta diferente.

7. Registrar resultados

Cada hallazgo debe incluir:

  • Endpoint afectado.
  • Solicitud original.
  • Solicitud modificada.
  • Respuesta obtenida.
  • Impacto.
  • Evidencia.
  • Recomendación.
  • Condiciones necesarias para reproducirlo.

Buenas prácticas

Burp Suite es una herramienta poderosa, pero su eficacia depende de la metodología utilizada.

Algunas buenas prácticas son:

  • Trabajar únicamente con autorización.
  • Definir claramente el alcance.
  • Evitar pruebas destructivas.
  • No almacenar credenciales reales sin protección.
  • Utilizar cuentas específicas de laboratorio.
  • Registrar cada modificación.
  • Reproducir los resultados antes de reportarlos.
  • Diferenciar una anomalía de una vulnerabilidad confirmada.
  • Evitar automatizaciones agresivas sobre sistemas de producción.
  • Eliminar datos sensibles de capturas e informes.

Laboratorios recomendados

Para aprender Burp Suite sin afectar sistemas ajenos pueden utilizarse entornos creados específicamente para practicar:

  • PortSwigger Web Security Academy.
  • OWASP Juice Shop.
  • DVWA.
  • WebGoat.
  • Aplicaciones desarrolladas localmente.
  • Máquinas virtuales de laboratorio.

Estas plataformas permiten practicar interceptación, análisis de solicitudes, sesiones, validación de entradas y controles de acceso en condiciones controladas.

Conclusión

Burp Suite funciona como un microscopio para aplicaciones web. Permite observar comunicaciones que normalmente permanecen ocultas detrás del navegador y comprender cómo interactúan clientes, servidores, APIs, cookies y mecanismos de autenticación.

Su integración con herramientas de consola amplía considerablemente sus posibilidades. Comandos como curl, grep, sha256sum y el servidor HTTP de Python permiten crear laboratorios, generar solicitudes, conservar evidencia y analizar respuestas.

Aprender Burp Suite no consiste solamente en presionar botones o ejecutar pruebas automáticas. El verdadero valor está en comprender el protocolo HTTP, formular hipótesis, modificar solicitudes de manera controlada e interpretar correctamente las respuestas del servidor.

Utilizada de forma ética y dentro de un alcance autorizado, Burp Suite es una herramienta fundamental para desarrolladores, analistas de seguridad, pentesters y profesionales dedicados a proteger aplicaciones web.

Comentarios

Entradas populares de este blog

Contraseñas únicas y autenticación en dos pasos: dos hábitos que pueden salvar tus cuentas

John the Ripper: auditoría y recuperación de contraseñas desde la terminal