Headers HTTP que Todo Hacker y Pentester Debería Conocer

Cuando hablamos de seguridad web, normalmente pensamos en contraseñas débiles, inyecciones SQL o XSS. Pero hay un terreno menos visible, aunque igual de peligroso, los HTTP Headers. Estas cabeceras, que parecen inofensivas en un request, pueden ser manipuladas para evadir controles, engañar proxies o incluso obtener acceso directo a áreas restringidas de una aplicación.

Les compartimos una lista de headers claves que se utilizan en técnicas de bypass. Vamos a explicar qué son, cómo los atacantes los abusan y qué significa esto en un pentest o escenario real.

1. ¿Por qué los Headers son un vector tan poderoso?

El protocolo HTTP fue diseñado para ser flexible y extensible. Por eso existen decenas de headers estándar y otros personalizados (los que comienzan con X-). Servidores, proxies, balanceadores de carga y APIs confían en estas cabeceras para tomar decisiones críticas:

• ¿A qué ruta enviar la petición?

• ¿Desde dónde viene el cliente?

• ¿Es tráfico HTTPS o HTTP?

• ¿Cuál es la IP de origen?

• ¿Qué formato de datos acepta el navegador?

Ese nivel de confianza abre la puerta a que un atacante falsifique información en headers para manipular la lógica del backend.

2. Headers relacionados con rutas y reescrituras

Algunos headers buscan engañar al backend para que interprete rutas diferentes:

• X-Original-URL, X-Rewrite-URL, X-Forwarded-Path, X-Forwarded-Prefix
  Estos headers aparecen en entornos con reverse proxies o API gateways. Si la aplicación no valida bien, un atacante puede poner /admin en alguno de estos y acceder a rutas internas.

• X-Original-URI, X-Request-URL, X-Rewrite-URI
  Variantes similares. Algunos servidores como IIS o middlewares antiguos aún los procesan.

Estrategia de ataque: colocar /admin o cualquier endpoint restringido en estos headers y observar si el backend los interpreta por encima de la URL real.

3. Headers que apuntan al Host y a la IP de origen

Muchos controles de seguridad se basan en la dirección de origen. Aquí entran headers como:

• Host
  Manipular el header Host es un clásico para ataques SSRF (Server-Side Request Forgery) o para confundir virtual hosts.

• X-Forwarded-Host, X-Forwarded-For, X-Real-IP, X-Originating-IP
  Se usan en proxies y balanceadores para informar la IP real del cliente. Si la aplicación confía ciegamente en estos headers, basta con enviar 127.0.0.1 para hacerse pasar por localhost. Resultado: acceso a rutas internas o bypass de firewalls.

• X-Custom-IP-Authorization
  Algunas APIs obsoletas lo usan para determinar acceso admin.

Estrategia de ataque: probar estas cabeceras con 127.0.0.1 o internal.app.local para ver si se obtiene acceso a funciones restringidas.

4. Headers para saltar controles de CORS y Referer

La seguridad de muchas aplicaciones modernas depende de las políticas same-origin y validaciones de Referer o Origin:

• Referer
  Algunos sistemas solo permiten redirecciones o acciones críticas si el referer apunta al dominio legítimo. Alterar este header puede saltar esas validaciones.

• Origin
  Fundamental en CORS. Si la aplicación confía en lo que recibe y no valida contra una whitelist real, un atacante puede forzar que acepte requests desde un dominio malicioso.

• X-Forwarded-Scheme y X-Scheme
  Se usan para indicar si la conexión es http o https. Un bypass clásico es hacer creer al backend que la conexión es segura aunque en realidad no lo sea.

5. Headers que manipulan métodos HTTP

En muchos entornos, los proxies o firewalls limitan métodos peligrosos como DELETE o PUT. Pero hay headers que permiten “redefinir” el método:

• X-HTTP-Method-Override, X-HTTP-Method, _method
  Sirven para indicar que un request POST, en realidad, debe tratarse como DELETE.

Escenario práctico: un firewall bloquea DELETE, pero acepta POST. Si la aplicación respeta X-HTTP-Method-Override: DELETE, el atacante logra borrar recursos con un POST “disfrazado”.

6. Headers de manipulación a bajo nivel

Algunos headers permiten realizar ataques avanzados como smuggling o tunelización:

• Transfer-Encoding: chunked
  Usado en CLTE smuggling, donde un atacante confunde al servidor y al proxy con diferentes interpretaciones de la longitud del body.

• Content-Length: 0
  También útil en combinación con smuggling.

• Connection: close
  Puede alterar la forma en que el backend interpreta la persistencia de conexiones, útil en evasión.

7. Headers que combinan varios vectores

• X-Original-Scheme, Forwarded
  Permiten enviar información combinada como for=127.0.0.1;host=admin, engañando múltiples capas de validación (SSRF + spoofing de host + bypass de proxy).

8. Headers relacionados con el contenido

• Content-Type
  Alterarlo puede hacer que el backend procese datos con una lógica distinta (ej. enviar JSON en lugar de form-data para bypass de validaciones).

• Accept
  Puede forzar negociación de formato. Ejemplo: si un endpoint entrega JSON solo a clientes “válidos”, un atacante puede forzar esa respuesta enviando Accept: application/json.

9. Implicaciones en Pentesting

Durante un pentest, jugar con estos headers puede revelar:

• Rutas internas expuestas gracias a rewrite o proxy bypass.

• SSRFs críticos al hacerse pasar por localhost.

• Ejecución de métodos restringidos como DELETE o PUT.

• Saltos de CORS aceptando orígenes falsos.

• Ataques de request smuggling al manipular Transfer-Encoding y Content-Length.

• Acceso administrativo oculto gracias a headers poco documentados.

10. Mitigaciones y buenas prácticas

1. No confiar ciegamente en headers de cliente. Validar IP real en el nivel del balanceador.

2. Whitelists estrictas en CORS: nada de Origin: *.

3. Normalizar métodos HTTP y deshabilitar overrides.

4. Hardening de proxies y WAFs para prevenir smuggling.

5. Revisar configuraciones heredadas (Nginx, Apache, IIS) que aún interpreten headers obsoletos.

6. Monitoreo constante de logs para detectar headers sospechosos.

Los headers HTTP son como una navaja suiza en manos de un atacante: pequeños, invisibles al ojo no entrenado, pero capaces de abrir muchas puertas cerradas. Desde confundir un proxy hasta suplantar la IP de origen o saltar CORS, las técnicas basadas en cabeceras son un recurso que ningún pentester serio debería ignorar.

Lo más peligroso es que muchas de estas cabeceras se diseñaron con buena intención (compatibilidad, flexibilidad), pero con el tiempo se convirtieron en verdaderos agujeros.

La defensa empieza por reconocer que el cliente nunca es confiable. Validar, filtrar y registrar headers sospechosos debe ser una prioridad. Para los equipos de seguridad, comprender esta lista es vital; para los pentesters, es una guía práctica de vectores a probar en cada engagement.