Por qué el navegador te miente: 6 trucos de peticiones que destapan bugs ocultos

TL;DR

El navegador no es una herramienta de pruebas de seguridad. Sanea tu entrada, sigue redirecciones por su cuenta y te muestra una página de error limpia mientras descarta sin hacer ruido los stack traces, los errores de base de datos y los parámetros ocultos que el servidor devuelve. Burp Suite te muestra la verdad en crudo, y el hueco entre ambos es donde se esconden los bugs de verdad. Domina estos 6 trucos de manipulación de peticiones HTTP y dejarás de adivinar si un objetivo es seguro para empezar a leer lo que el servidor te dice de verdad:

1. Lee la respuesta en crudo que el navegador esconde (divulgación de información).
2. Manipulación de parámetros que dispara una inyección SQL basada en errores.
3. Manipulación de métodos HTTP que evade la autenticación.
4. Cambio de Content-Type que habilita una asignación masiva.
5. Spoofing de cabeceras de IP que sortea un 403.
6. Caza de los parámetros POST y PUT que tu URL nunca muestra.

Cada truco de abajo viene con la petición real y la respuesta real, igual que trabajo yo un objetivo.

El navegador lo sanea todo, y ese es el problema

La mayoría de los principiantes prueba aplicaciones web tecleando en formularios del navegador y mirando la pantalla. Sueltan una comilla simple en un cuadro de búsqueda, ven un error genérico, deciden que el objetivo es seguro y siguen adelante. Por eso la mayoría de los principiantes no encuentra nada.

El navegador hace mucho trabajo antes de que tu entrada llegue siquiera al servidor. Codifica caracteres especiales, añade cabeceras que no pediste, sigue redirecciones automáticamente y reemplaza los errores feos del servidor por una página amable. Luego, cuando vuelve la respuesta, un frontend moderno de JavaScript parsea el JSON y normalmente te muestra un solo campo, el message, mientras ignora todo lo demás. El campo stack, el error de base de datos, el detalle de depuración: la página lo recibe todo y elige no renderizar nada.

Burp Suite no tiene frontend. Se sitúa entre tu navegador y el servidor como un proxy de interceptación y te muestra la petición completa y la respuesta completa, byte a byte. El servidor está filtrando secretos constantemente en esas respuestas. El navegador simplemente no te los pasa. Aprender manipulación de peticiones HTTP es aprender a leer lo que dice el servidor cuando dejas de permitir que el navegador traduzca por ti.

Lo aprendí por las malas. Al principio de mi andadura en bug bounty pasé meses probando a través del navegador, encontré un error limpio en cada página de login y marqué objetivo tras objetivo como seguro. No encontré ni un solo bug así. En el momento en que empecé a interceptar cada petición y a leer las respuestas en crudo, mis resultados cambiaron por completo. Ese hábito es como llegué a más de 250 entradas en salones de la fama de organizaciones como la OMS, la UNESCO, la BBC, Boeing y Cambridge, y como conseguí el CVE-2025-56697.

1. Lee la respuesta en crudo que el navegador esconde

El primer truco no es un payload. Es un hábito: intercepta la petición, envíala y lee la respuesta entera en lugar de la página.

Estaba probando una página de login. Formulario estándar, campo de email, campo de contraseña, botón de login. En el navegador probé una comilla simple y un clásico ' OR '1'='1-- en el campo de email. Cada vez, el navegador respondía con la misma línea limpia:

The email or password provided is incorrect.

Sin stack trace. Sin pista de base de datos. Nada. Un principiante lee eso y lo deja. Ahí es exactamente donde el objetivo deja de hablarle al navegador y empieza a hablarle a Burp Suite.

Activé la interceptación y envié el mismo login con el mismo payload. La petición parecía corriente, un POST a /api/users/login. La respuesta no:

HTTP/1.1 401 Unauthorized
Server: nginx
Content-Type: application/json; charset=utf-8

{
  "errors": [
    {
      "message": "The email or password provided is incorrect",
      "stack": "AuthenticationError: The email or password provided is incorrect.\n  at login (/home/app/node_modules/payload/dist/auth/operations/login.js:62:19)\n  at process.processTicksAndRejections (node:internal/process/task_queues:95:5)\n  at async loginHandler (/home/app/node_modules/payload/dist/auth/requestHandlers/login.js:20:24)"
    }
  ]
}

El navegador mostró una línea. Burp Suite mostró el stack trace completo. En un único login fallido ya sabía que el servidor corre Node.js, que la aplicación usa el framework Payload, que el código vive en /home/app/ y los archivos y números de línea exactos donde sucede la autenticación.

Esto es divulgación de información, catalogada como CWE-200, y rara vez es el bug final. Es reconocimiento que el servidor te entrega gratis. Conocer el framework te permite buscar vulnerabilidades conocidas. Conocer las rutas de archivos te permite adivinar otros endpoints. Saber que es Node.js te dice qué sintaxis de inyección probar a continuación. El navegador lo llamó "una contraseña incorrecta". El servidor lo llamó un plano.

2. Manipulación de parámetros: una comilla, un error SQL

La manipulación de parámetros consiste en cambiar un valor en el que la aplicación confía y observar qué se rompe. Mi ejemplo favorito de una sesión reciente fue una página de reseñas en un sitio de comercio electrónico, de las que tienen un simple voto de pulgar hacia arriba.

Hice clic en "me gusta" y capturé la petición. Un cuerpo POST limpio:

POST /api/reviews/vote HTTP/2
Content-Type: application/x-www-form-urlencoded

reviewId=122825603&vote=1&apiKey=pubkey-XCodOia&sId=94323

La respuesta fue un pulcro {"voteUp":1,"voteDown":0}. No se filtró nada. La mayoría de los testers siguen adelante. En cambio, yo miré ese reviewId y me hice la única pregunta que importa: es numérico, así que ¿qué pasa si el backend construye una consulta SQL con él y le envío algo que no es un número? Cambié reviewId=122825603 por reviewId=122825603', una sola comilla, y lo reenvié.

La respuesta fue inmediata y estridente:

HTTP/2 500 Internal Server Error
Content-Type: application/json

{
  "message": "An error has occurred.",
  "exceptionMessage": "The INSERT statement conflicted with the FOREIGN KEY constraint \"FK_dbo.ReviewVotes_dbo.Review_ReviewId\". The conflict occurred in database \"shopry_shopifyproductaddons\", table \"dbo.Review\", column 'Id'.",
  "exceptionType": "System.Data.SqlClient.SqlException"
}

Ese único carácter reveló el motor de base de datos (Microsoft SQL Server), el nombre de la base de datos, la tabla Review, la columna Id y una relación de clave foránea con ReviewVotes. Esto es divulgación clásica por inyección SQL basada en errores, y es la puerta, no el destino. Ahora conozco el motor, así que conozco la sintaxis. Conozco nombres de tablas, así que puedo pensar en UNION SELECT. Conozco la estructura, así que puedo adivinar /api/reviews/delete y /api/reviews/edit. El navegador habría atrapado ese 500 en JavaScript y habría mostrado "Algo salió mal". Burp Suite me mostró OWASP Web Parameter Tampering en una sola petición.

Mientras estés en ese cuerpo, prueba también los demás parámetros. Los IDs numéricos como reviewId son además candidatos de primera para IDOR y BOLA: mete el ID de otro usuario y mira de quién son los datos que vuelven. Un solo cuerpo de petición puede esconder tres clases de bug distintas.

3. Manipulación de métodos HTTP para evadir la autenticación

Algunos controles de acceso solo vigilan las puertas por las que esperan que entres. La manipulación de métodos HTTP, también llamada manipulación de verbos, prueba las puertas que olvidaron.

En un objetivo, un panel de administración devolvía 401 Unauthorized en el navegador. La autenticación básica estaba activada y las credenciales comunes no hacían nada. La mayoría de la gente se detiene aquí. Capturé la petición y cambié solo el método:

GET  /admin   ->  401 Unauthorized
POST /admin   ->  401 Unauthorized
HEAD /admin   ->  200 OK

HEAD devolvió 200 OK. El servidor procesó la petición y la consideró válida. OPTIONS y TRACE hicieron lo mismo. La autenticación se aplicaba para GET y POST y nada más. La configuración tenía esta pinta:

<Limit GET POST>
  require valid-user
</Limit>

El desarrollador supuso que solo importaban GET y POST y olvidó que existen HEAD, OPTIONS, TRACE y PUT. Cambiando un verbo en Burp Suite, llegué al panel sin credenciales. Este es un caso de manual de control de acceso roto, el riesgo número uno del OWASP Top 10. Para un análisis más profundo de la técnica, la referencia clásica sigue siendo Tampering HTTP methods to bypass authentication, y la guía de explotación de cabeceras de YesWeHack cubre la familia más amplia.

4. Cambio de Content-Type y asignación masiva

Las APIs modernas aceptan más de un formato, y los desarrolladores rara vez validan todos por igual. Este truco encadena un cambio de Content-Type con una asignación masiva para escalar privilegios.

Estaba probando un endpoint de registro. El formulario del navegador mostraba tres campos, y la petición capturada era JSON limpio:

POST /api/auth/register HTTP/2
Content-Type: application/json

{ "username": "testuser", "email": "test@example.com", "password": "Test123!" }

El servidor validaba el JSON correctamente. Comprobaba el formato del email y saneaba frente a cross site scripting. Parecía seguro. Entonces cambié el Content-Type a application/xml y añadí un campo que el formulario nunca ofreció:

POST /api/auth/register HTTP/2
Content-Type: application/xml

<?xml version="1.0"?>
<user>
  <username>testuser</username>
  <email>test@example.com</email>
  <password>Test123!</password>
  <role>admin</role>
</user>

El parser de XML no imponía el mismo esquema, el campo <role> extra se asignó directo al objeto de usuario y la cuenta se creó con privilegios de administrador. Eso son dos bugs en una sola petición: el cambio de Content-Type evadió la validación, y la asignación masiva de un parámetro oculto escaló el privilegio. La referencia defensiva es la OWASP Mass Assignment Cheat Sheet, y PortSwigger tiene un laboratorio práctico de asignación masiva si quieres probarlo de forma segura. Si pruebas APIs a menudo, mi guía de seguridad de APIs profundiza en los campos ocultos y el OWASP API Top 10.

5. Falsificar cabeceras de IP para sortear un 403

Cuando un servidor restringe un endpoint por IP, normalmente lee la IP de una cabecera, y las cabeceras las controla el atacante.

Encontré /api/admin/backup devolviendo 403 Forbidden con el mensaje "Access denied. Admin IP required". El servidor comprobaba la IP del cliente. Así que le dije lo que quería que viera:

GET /api/admin/backup HTTP/2
Host: target.com
X-Forwarded-For: 127.0.0.1

La respuesta cambió de 403 Forbidden a 200 OK, con el archivo de copia de seguridad en el cuerpo. El servidor confiaba en X-Forwarded-For para identificar al cliente sin verificar que la cabecera viniera de un proxy de confianza, así que cualquiera que dijera ser 127.0.0.1 era tratado como localhost. No fue la única cabecera que funcionó:

X-Real-IP: 127.0.0.1        ->  200 OK
X-Originating-IP: 127.0.0.1 ->  200 OK
X-Remote-IP: 127.0.0.1      ->  200 OK
X-Client-IP: 127.0.0.1      ->  200 OK

Este es otro sabor del control de acceso roto, y un bypass de 403 fiable para tener en tu kit. Los trucos de cabecera y ruta como X-Original-URL y X-Rewrite-URL pertenecen al mismo conjunto de pruebas. La comunidad mantiene una buena lista al día en PayloadsAllTheThings, que vale la pena tener abierta mientras trabajas.

6. Caza los parámetros que tu URL nunca muestra

Aquí está la idea que ata las demás. Cuando lees la barra de direcciones, solo ves los parámetros GET:

https://target.com/search?q=test&page=1

Pero las aplicaciones modernas hacen su trabajo sensible en peticiones POST y PUT, y esos parámetros viven en el cuerpo, invisibles para la URL. Mira de nuevo la petición de voto del truco 2:

reviewId=122825603&vote=1&apiKey=pubkey-XCodOia&sId=94323

Si solo vigilaras la barra de direcciones del navegador, verías https://target.com/reviews y nada más. Ni reviewId, ni apiKey, ni sId. Todo se esconde en el cuerpo, y el cuerpo es justo donde vivía la inyección SQL. Como estos parámetros nunca aparecen en la URL, los desarrolladores suelen suponer que nadie los ve y los validan a la ligera. Burp Suite ve todos y cada uno de ellos, y los atacantes también.

Así que captura todo, no solo la URL. Haz clic en cada botón, dispara cada evento de JavaScript y observa cómo el historial del proxy se llena de endpoints que la documentación nunca mencionó. Leer el tráfico en crudo es la misma disciplina que hace que Wireshark y Nmap valgan la pena: la verdad está en el cable, no en la pantalla.

La metodología de 5 pasos que ejecuto en cada objetivo

Estos trucos no son suerte. Son un sistema. Aquí tienes el bucle que ejecuto en cada objetivo antes de perseguir ninguna vulnerabilidad concreta, y funciona igual de bien en un laboratorio casero que en un programa en vivo.

Primero, mapea todas las funciones. Dedica la primera hora a usar la aplicación como un usuario real. Haz clic en todo, envía cada formulario, cambia cada ajuste y deja que el historial de Burp Suite registre cada endpoint, incluidos los que dispara JavaScript y que ninguna documentación lista.

Segundo, identifica parámetros interesantes. Los IDs numéricos (userId, orderId) son candidatos para inyección SQL e IDOR. Los flags booleanos (isAdmin=false, verified=no) están pidiendo que los inviertas. Las claves de API, los parámetros de acción como action=delete y los campos ocultos merecen toda la atención.

Tercero, prueba cada parámetro de forma individual. No dispares payloads a lo loco. Cambia un valor cada vez. Para campos numéricos, prueba una comilla simple, un número negativo, un cero, un número enorme y el ID de otro usuario. Para cadenas, prueba una comilla, una barra invertida, un byte nulo y ../../etc/passwd. Para booleanos, inviértelos, quítalos y cambia su tipo.

Cuarto, prueba métodos y cabeceras HTTP. Para cada endpoint interesante, recorre GET, POST, PUT, DELETE, HEAD, OPTIONS y TRACE, y luego prueba X-Forwarded-For, X-Real-IP y X-Original-URL en cualquier cosa restringida.

Quinto, observa las respuestas con atención. El servidor te lo cuenta todo si escuchas. Lee los mensajes de error y los stack traces, compara las longitudes de las respuestas, fíjate en las diferencias de tiempo y presta atención a los códigos de estado. Un 401 no es un 403, y un 403 no es un 500, y cada uno significa algo distinto sobre cómo se manejó tu entrada.

Ese bucle es el núcleo de las verdaderas pruebas de penetración de aplicaciones web, y es exactamente el flujo de trabajo que entrenamos en el bootcamp de ciberseguridad de Unihackers. Si quieres aplicarlo en programas reales, empieza por mi guía sobre cómo elegir tu primer objetivo de bug bounty.

Preguntas frecuentes

Estas se corresponden con las preguntas que más hacen los recién llegados, y están escritas para sostenerse por sí solas.

¿Qué es la manipulación de peticiones HTTP? Es interceptar una petición después de que el navegador la construye y cambiar partes que el navegador nunca te dejaría editar: parámetros del cuerpo, el método, las cabeceras y el Content-Type. Lees la respuesta en crudo para ver qué hace realmente el servidor con tu entrada.

¿Por qué encontrar bugs así en lugar de en el navegador? Porque el navegador esconde las pruebas. Renderiza un message amable y descarta el stack trace, el error de base de datos y los campos ocultos. El proxy muestra la verdad sin filtrar, y el bug vive en la diferencia.

Conclusión

La manipulación de peticiones HTTP no va de memorizar diez mil payloads. Va de curiosidad. Miras una petición, te preguntas por qué existe un parámetro y descubres qué dice el servidor cuando lo confundes a propósito. El navegador está hecho para usuarios: sanea, esconde y embellece. Burp Suite está hecho para la verdad: te muestra exactamente lo que piensa el servidor.

Así que la próxima vez que pruebes un objetivo, no te fíes de la pantalla. Intercepta todo, modifica cada parámetro, envía valores raros, cambia el método, cambia el Content-Type y añade la cabecera inesperada. Luego lee la respuesta en crudo. Los secretos ya están ahí. Solo tienes que dejar de permitir que el navegador te mienta.

Sigue cazando. Mantén la curiosidad. Y recuerda: el navegador miente, Burp Suite dice la verdad.