Burp Suite para eJPT: Proxy, HTTP History y Repeater

1. El recorrido: observar, aislar y comprobar

Burp se coloca entre el navegador y el servidor. Proxy recibe el tráfico, HTTP History conserva el intercambio y Repeater permite repetir una petición después de editarla. El aprendizaje no está en cambiar muchos campos, sino en modificar uno y explicar qué diferencia produjo respecto a la línea base.

El resultado se clasifica como efecto confirmado, sin efecto observado o inconcluso. Que un parámetro aparezca en la URL no demuestra que la aplicación lo procese.

2. Prepara Burp y un objetivo local desechable

Descarga Burp Suite desde PortSwigger, ejecuta el instalador nativo de tu arquitectura y selecciona Community Edition. Inicia un proyecto temporal con la configuración por defecto. Para este ejercicio usa el navegador integrado: ya está preparado para el proxy y evita instalar una autoridad certificadora en tu navegador habitual. El listener predeterminado suele estar en 127.0.0.1:8080; por eso el pequeño servidor de práctica escucha en 8000.

Deja esa terminal abierta. Una respuesta como Serving HTTP on 127.0.0.1 port 8000 confirma que el servicio está listo; Ctrl + C lo detiene. Si python3 o py no existe, instala Python desde su distribución oficial antes de continuar, sin exponer el servidor a otra interfaz.

3. Captura una petición y luego deja navegar

En Burp abre Proxy → Intercept, pulsa Open browser y visita http://127.0.0.1:8000/index.html?term=alpha. Si Intercept está activado, la página esperará mientras Burp muestra la petición: léela y pulsa Forward. Después cambia a Intercept is offpara que el resto de recursos fluya sin detenerse.

La primera línea contiene método, ruta y query string; Host identifica el destino. En este GET no hay cuerpo. No edites todavía: esta petición será la línea base que permitirá atribuir cada cambio posterior.

4. Encuentra y lee la línea base en HTTP History

Abre Proxy → HTTP history. El historial registra el tráfico que cruza Proxy incluso con Intercept desactivado. Filtra por 127.0.0.1 o busca term=alpha, selecciona la fila y revisa las vistas de petición y respuesta. Los filtros cambian lo que ves; no borran el historial.

Si el listado tiene demasiado ruido, activa temporalmente los filtros «solo elementos con respuesta» o «solicitudes con parámetros». Para trabajos reales añade únicamente el host autorizado al scope y revisa que el filtro no esté ocultando una petición relevante.

5. Envía a Repeater y cambia una sola variable

Haz clic derecho en la petición base y elige Send to Repeater. Abre la pestaña Repeatery pulsa Send sin modificar nada: esa repetición debe aproximarse a la respuesta original. Después realiza estas tres pruebas en orden, restaurando la línea base entre ellas.

La prueba A confirma ausencia de efecto observado, no que el parámetro sea seguro en cualquier aplicación. Las pruebas B y C demuestran que Repeater sí está reenviando tus cambios. No alteres a la vez método, ruta, cookies, cabeceras y cuerpo: perderías la capacidad de atribuir el resultado.

6. Compara señales, no solo el aspecto visual

Para cada envío anota el valor cambiado y compáralo con la línea base. Repeater muestra la respuesta actual; el historial conserva la original para volver a consultarla. En esta práctica basta una tabla manual: no necesitas aprender Comparer ni otra herramienta de Burp.

Un cambio reproducible de estado, longitud o marcador confirma que la variable influye en la respuesta. No prueba por sí solo una vulnerabilidad: para eso harían falta una hipótesis de seguridad, impacto y autorización adicional.

7. Resuelve los fallos habituales sin cambiar de herramienta

8. Cierra el laboratorio con una evidencia explicable

• □El objetivo es local o está incluido expresamente en el alcance autorizado
• □Burp Community se abrió con un proyecto temporal y la configuración por defecto
• □El navegador integrado cargó 127.0.0.1:8000 a través de Proxy
• □La primera petición se dejó intacta como línea base
• □HTTP History conserva solicitud, respuesta, estado y longitud originales
• □La petición base se envió a Repeater y se repitió sin cambios
• □Cada prueba modificó una sola variable y restauró la línea base después
• □El parámetro ignorado se clasificó como sin efecto observado, no como seguro
• □Los cambios de ruta produjeron un cuerpo distinto y un 404 reproducibles
• □La evidencia no contiene cookies, tokens, credenciales ni datos personales
• □Intercept quedó desactivado y el servidor local se detuvo con Ctrl+C

Ya tienes el ciclo manual esencial: capturar → localizar → repetir → cambiar → comparar. En un laboratorio posterior puedes aplicarlo a formularios o APIs autorizadas, manteniendo la misma disciplina de una variable por prueba. Cierra el navegador de Burp y el proyecto temporal; elimina la carpeta cubix-burp-lab cuando ya no necesites los dos archivos de práctica.

Glosario