Inyección de encabezados HTTP mediante variaciones de mayúsculas y minúsculas: ejemplos de ataques y cómo protegerse

Las cabeceras HTTP no son simplemente líneas de servicio al inicio de una solicitud o respuesta. Controlan cómo el navegador o una aplicación cliente procesará los datos recibidos. Según el estándar, los nombres de las cabeceras no distinguen entre mayúsculas y minúsculas, y esto crea una zona de riesgo inesperada. Dos cabeceras idénticas, pero con distinto uso de mayúsculas —por ejemplo, Content-Length y content-length— pueden ser procesadas de manera diferente por distintos componentes de la cadena de entrega de datos. Precisamente en esta característica se basa la técnica de inyección de cabeceras HTTP —HTTP Header Injection— mediante la duplicación con diferentes registros.

Por qué el uso de mayúsculas no importa según el estándar, pero sí en la práctica

Según RFC 9110, los nombres de las cabeceras HTTP no distinguen mayúsculas de minúsculas. Esto significa que el servidor debe tratar de la misma manera a Host y a host. Sin embargo, la especificación no impone cómo debe actuar exactamente un servidor, un proxy o una aplicación si existen dos cabeceras con el mismo nombre aunque difieran en el uso de mayúsculas.

En arquitecturas reales la situación suele ser la siguiente:

• Un componente puede combinar los valores separados por comas.
• Otro puede conservar solamente la primera cabecera encontrada.
• Un tercero puede sobrescribir el valor con la última cabecera recibida.
• Un cuarto puede considerarlas cabeceras distintas y procesar ambas.

La falta de coherencia permite que un atacante inserte sus datos en un momento inesperado.

Mecánica del ataque

La esencia del método consiste en enviar una solicitud que contenga cabeceras idénticas con nombres en diferentes mayúsculas. Esto puede confundir a alguno de los componentes de la cadena de procesamiento.

1. El cliente envía una solicitud con dos cabeceras:

   Content-Length: 100
   content-length: 5
   

2. Uno de los nodos intermedios (CDN, balanceador) considera que la cabecera es única y usa el valor 100.
3. El siguiente nodo (servidor web) se orienta por la última variante y usa el valor 5.
4. Como resultado, parte de los datos puede ser interpretada como nuevas cabeceras o como una nueva solicitud, abriendo la posibilidad de inyectar cabeceras arbitrarias.

Este enfoque puede emplearse para:

• insertar cabeceras adicionales (Set-Cookie, Location, X-Forwarded-For);
• suplantar respuestas cacheadas;
• crear condiciones para otros ataques (por ejemplo, Request Smuggling).

Comportamiento de tecnologías populares

Diferentes servidores web y plataformas tratan los duplicados de cabeceras de forma distinta:

• NGINX — por defecto combina cabeceras iguales en un conjunto de valores, pero la lógica modular puede basarse en el primer o en el último elemento.
• Apache HTTP Server — según el módulo, puede sobrescribir el valor o combinar los valores con comas.
• Node.js (Express, Fastify) — la API estándar devuelve la última cabecera, pero middleware pueden trabajar solo con la primera.
• Java (Spring, Jakarta EE) — con frecuencia convierte las cabeceras en un mapa normalizando el registro, pero el orden de procesamiento depende del contenedor (Tomcat, Jetty, etc.).
• Python (Flask, Django) — normalmente acepta el último valor, aunque al emplear servidores WSGI externos pueden producirse diferencias.

Relación con otras vulnerabilidades

La duplicación de cabeceras con distinto uso de mayúsculas puede formar parte de ataques más complejos:

• HTTP Response Splitting — inserción de secuencias CRLF para añadir cabeceras o cuerpo propios en la respuesta.
• HTTP Request Smuggling — tratamiento discordante de la longitud o de los límites de la solicitud por nodos distintos en la cadena.
• Bypass Access Control — alteración de la lógica de autorización si se usan cabeceras como X-Forwarded-For para identificar al cliente.

Herramientas para comprobar

Para probar la vulnerabilidad son útiles:

• Burp Suite — permite modificar solicitudes de forma flexible, incluido el cambio de mayúsculas en las cabeceras.
• cURL — práctico para enviar solicitudes manuales:

  curl -v -H "Set-Cookie: a=1" -H "set-cookie: b=2" https://example.com
  

• Nuclei — escáner basado en plantillas que facilita describir comprobaciones de duplicados.

Cómo protegerse

Las recomendaciones de defensa se centran en la normalización y el filtrado:

• A nivel del servidor web — rechace solicitudes con cabeceras duplicadas, independientemente del uso de mayúsculas.
• En la aplicación — utilice API que devuelvan un único valor por cabecera.
• En proxy y CDN — active la normalización estricta de nombres de cabeceras y la comprobación de unicidad.
• En un WAF (por ejemplo, ModSecurity) — configure reglas para bloquear duplicados.

Conclusión

La inyección de cabeceras HTTP mediante la duplicación con distintos registros es un ejemplo de cómo una característica aparentemente segura del protocolo puede convertirse en una vulnerabilidad por discrepancias en las implementaciones. El problema no reside en el uso de mayúsculas en sí, sino en que los distintos participantes de la cadena de procesamiento pueden interpretar de forma distinta esas cabeceras. La mejor defensa es una normalización estricta en todos los niveles y la verificación de la unicidad de cada cabecera en las solicitudes.