Qué es HTTP Parameter Contamination y por qué es un riesgo real

Cuando hablamos de seguridad en aplicaciones web, mucha gente piensa solo en SQL Injection, XSS o fallos de autenticación. Sin embargo, desde hace años existe una técnica bastante silenciosa que sigue pasando desapercibida en muchas auditorías: la contaminación o polución de parámetros HTTP, conocida como HTTP Parameter Pollution (HPP) o HTTP Parameter Contamination.

Este tipo de vulnerabilidad aprovecha cómo distintas tecnologías de servidor y frameworks gestionan parámetros duplicados en una misma petición HTTP. Si la aplicación no está preparada para ello, un atacante puede alterar la lógica interna, saltarse validaciones, engañar a cortafuegos de aplicaciones web (WAF) e incluso llegar a tomar el control de funcionalidades críticas como la autenticación o la gestión de permisos.

Concepto de parámetros HTTP y precedencia

En prácticamente cualquier sitio web moderno, los usuarios envían datos mediante parámetros HTTP en la URL o en el cuerpo de la petición. Estos parámetros sirven para que el navegador pase información a la aplicación: búsquedas, datos de formularios, elecciones en encuestas, comentarios, credenciales de acceso, etc.

En una petición típica GET, esos datos viajan en la query string (todo lo que va tras el signo ? en la URL) y los pares clave/valor se separan por el símbolo &. En una petición POST, pueden ir en el cuerpo, pero la lógica de la aplicación en el servidor suele tratarlos de forma muy parecida: claves con uno o varios valores asociados.

Muchos lenguajes de programación y frameworks proporcionan métodos para obtener tanto un único valor de un parámetro como la lista completa de valores si ese parámetro aparece repetido. Esto es habitual, por ejemplo, con checkboxes que permiten selección múltiple, donde el mismo nombre de parámetro aparece varias veces.

El problema viene cuando el desarrollador asume que solo habrá un valor por parámetro y utiliza funciones que devuelven un único valor, mientras que el navegador (o el atacante) envía varios valores con el mismo nombre. En ese punto entra en juego un concepto clave: la precedencia de valores.

Dependiendo del lenguaje, del framework y del servidor web, ante múltiples apariciones del mismo parámetro se pueden dar varios comportamientos: que se use el primer valor recibido, que se coja el último valor o que se genere una combinación de todos (por ejemplo, concatenados con comas). No existe un estándar único, así que cada stack tecnológico puede comportarse de manera diferente, lo que abre la puerta a situaciones muy peligrosas.

Que una función devuelva un solo valor no es una vulnerabilidad en sí misma, pero cuando hay parámetros duplicados y el desarrollador no es consciente de cómo actúa esa precedencia, la aplicación puede obtener un valor inesperado. Ese comportamiento anómalo es justo lo que explotan las técnicas de HTTP Parameter Pollution.

¿Qué es HTTP Parameter Pollution (HPP)?

La contaminación de parámetros HTTP es una técnica que consiste en inyectar parámetros adicionales o delimitadores de query string (codificados) dentro de otros parámetros ya existentes. Cuando ese parámetro inyectado se decodifica y se reutiliza para generar una nueva URL o para construir otra petición, la aplicación acaba incorporando parámetros extra que el desarrollador no esperaba.

En otras palabras, HPP explota la forma en la que la aplicación reconstruye URLs, procesa formularios y maneja parámetros repetidos. Si no se valida correctamente la entrada, un atacante puede forzar a la aplicación a interpretar valores distintos a los previstos o a incluir parámetros adicionales en enlaces, formularios y redirecciones.

Las técnicas de HPP fueron introducidas públicamente por Stefano Di Paola y Luca Carettoni en la conferencia OWASP AppSec 2009. Desde entonces se han documentado muchos escenarios de ataque, pero aún hoy no tienen la misma visibilidad que otras vulnerabilidades más conocidas, ni están cubiertas de forma completa por todas las herramientas automáticas.

El impacto de un ataque de HTTP Parameter Pollution depende en gran medida de la lógica particular de la aplicación, del framework y del servidor web. En algunos casos las consecuencias son menores (errores de presentación, fallos de impresión de etiquetas, etc.), pero en otros puede suponer bypass de autenticación, alteración de permisos o manipulación de operaciones críticas.

Para que la vulnerabilidad HPP sea realmente explotable, es necesario que el mecanismo de lectura de parámetros del servidor o framework devuelva un valor distinto al esperado cuando se encuentra con parámetros duplicados. A partir de ahí, el atacante puede jugar con esa precedencia para dirigir el flujo de la aplicación a su favor.

Cómo gestionan los servidores los parámetros duplicados

La clave técnica que hace posible HPP está en el comportamiento desigual de los diferentes servidores web y lenguajes de backend al procesar parámetros repetidos. No todos hacen lo mismo, y esa variedad es justamente lo que permite a los atacantes encontrar huecos.

En algunos entornos, si enviamos una URL del tipo variable1=val1&variable1=val2, el servidor se quedará únicamente con el primer valor (val1). En otros, tomará el último valor recibido (val2). Y en ciertos casos, como sucede con determinadas configuraciones de IIS, los dos valores se concatenan internamente en una lista, por ejemplo separados por comas, que después la aplicación tendrá que interpretar.

Un ejemplo típicamente citado es que Apache en su comportamiento por defecto suele quedarse con el primer valor de un parámetro y descartar los siguientes, mientras que otras tecnologías generan una lista CSV (Comma Separated Values) con todos los valores de ese parámetro polucionado. Si la aplicación del backend solo está adaptada a uno de esos casos, los escenarios no controlados pueden provocar efectos inesperados.

Este manejo de parámetros duplicados no solo afecta a la lógica visible para el usuario, sino también a controles de seguridad internos, validadores de entrada, rutinas de autenticación y autorización. Un mismo parámetro puede ser comprobado en un punto de la aplicación utilizando un valor, y utilizado en otro punto con un valor distinto, todo dentro de la misma petición.

Además, los HPP pueden emplearse para aprovechar transformaciones internas de caracteres que hace el propio servidor. Se ha documentado, por ejemplo, cómo algunos servidores cambian ciertos caracteres concretos (como el carácter «]» sustituido por «_») durante el procesamiento, lo que puede utilizarse para evadir reglas de filtrado o firmwares de WAF basados en expresiones regulares.

Consecuencias y escenarios de explotación de HPP

Las técnicas de HTTP Parameter Pollution permiten generar un abanico bastante amplio de situaciones de riesgo, tanto en el lado del servidor como en el lado del cliente. Su gravedad depende de la función del parámetro afectado y del punto del flujo de la aplicación en el que se vea alterado.

Entre las consecuencias más destacadas que se han observado en aplicaciones vulnerables se encuentran la sobrescritura de parámetros protegidos. Un atacante puede añadir más de un valor para un parámetro crítico y forzar a la aplicación a utilizar precisamente el valor malicioso gracias a cómo funciona la precedencia en ese entorno concreto.

También es habitual que la HPP permita la modificación del comportamiento esperado de la aplicación. Por ejemplo, cambiando filtros en buscadores internos, alterando identificadores de recursos, manipulando operaciones de voto o variando parámetros que controlan la lógica de negocio (como flags de tipo admin, modos de depuración o estados de transacción).

Otra consecuencia importante es la evasión de validaciones de entrada. Si el código que valida la seguridad examina la primera ocurrencia de un parámetro, pero la operación real se realiza con otra ocurrencia posterior, el atacante puede superar controles de seguridad aparentemente bien implementados. Esto se ha visto en casos de bypass de autenticación y control de acceso.

En contextos más complejos, la HPP puede desencadenar errores internos de la aplicación, exposición de información sensible, acceso a variables fuera del alcance previsto e incluso el uso de parámetros concatenados que, una vez reensamblados, forman cargas útiles que un WAF no detectó al analizar cada parámetro por separado.

A nivel de impacto, se han observado ataques tanto del lado del servidor (saltándose WAF, alterando reescritura de URLs, forzando rutas internas diferentes) como del lado del cliente (inyección de parámetros en enlaces y formularios para engañar a las víctimas a través de URLs especialmente manipuladas).

Ejemplo clásico de HPP en una aplicación de votaciones

Para entender mejor cómo funciona un ataque de HTTP Parameter Pollution, resulta muy ilustrativo el ejemplo de una aplicación web de votaciones escrita en JSP, donde se permite a los usuarios votar a su candidato favorito en distintas elecciones.

La aplicación recibe mediante un parámetro llamado eleccion_id el identificador de la elección en curso. Con este valor, el servidor genera una página donde se listan los candidatos disponibles, cada uno de ellos con un enlace para emitir el voto. El método Request.getParameter(«par») de JSP, en presencia de múltiples valores para un mismo parámetro, devuelve siempre el primer valor.

Imaginemos una URL del tipo: http://servidor/eleccion.jsp?eleccion_id=4568. La página resultante muestra un enlace para votar a cada candidato, por ejemplo:

Enlace 1: <a href=»votar.jsp?eleccion_id=4568&candidato=white»>Voto para Mr. White</a>
Enlace 2: <a href=»votar.jsp?eleccion_id=4568&candidato=green»>Voto para Mrs. Green</a>

Supongamos que un usuario malicioso, que apoya a una candidata concreta, se da cuenta de que la aplicación no valida correctamente el parámetro eleccion_id. Aprovechando una vulnerabilidad HPP, decide inyectar el parámetro candidato dentro de ese eleccion_id, codificando los delimitadores de query string.

La URL que construye podría ser algo como: http://servidor/eleccion.jsp?eleccion_id=4568%26candidato%3Dgreen. Obsérvese que el atacante ha codificado el símbolo & como %26 y el signo = como %3D, de forma que, tras la decodificación, se convierten en un nuevo parámetro candidato incrustado dentro del valor de eleccion_id.

Cuando la víctima hace clic en esa URL manipulada, accede aparentemente a la elección correcta. Sin embargo, como la aplicación utiliza el valor de eleccion_id para construir los enlaces de voto, al decodificar el valor inyectado, acaba incluyendo un candidato extra en la query string resultante.

El resultado es que los enlaces generados internamente pasan a ser algo así como:

Enlace 1: <a href=»votar.jsp?eleccion_id=4568&candidato=green&candidato=white»>Voto para Mr. White</a>
Enlace 2: <a href=»votar.jsp?eleccion_id=4568&candidato=green&candidato=green»>Voto para Mrs. Green</a>

Da igual en cuál de los dos enlaces pinche la víctima: el script votar.jsp recibe siempre dos instancias del parámetro candidato, donde el primer valor es green. Como el desarrollador utiliza la funcionalidad estándar de Java para obtener un único valor, solo obtiene el primer valor del parámetro candidato y descarta el segundo, que recogería el voto real del usuario.

Gracias a este comportamiento, la vulnerabilidad HPP permite al atacante forzar que todos los votos emitidos en esa página vayan para su candidata, independientemente de lo que elija la víctima en el interfaz. Se trata de un ejemplo muy claro de cómo una supuesta “simple” gestión de parámetros puede tener un impacto directo en la integridad de los datos y la lógica de negocio.

Bypass de autenticación: el caso de Blogger

Uno de los ejemplos más sonados de explotación de HTTP Parameter Pollution se dio en el sistema de blogs de Blogger. Una vulnerabilidad en el manejo de parámetros permitió a atacantes llegar a convertirse en administradores de blogs ajenos, simplemente manipulando los parámetros de una petición POST.

La petición problemática era algo de este estilo (simplificando la sintaxis):

POST /add-authors.do HTTP/1.1
security_token=attackertoken&blogID=attackerblogidvalue&blogID=victimblogidvalue&authorsList=attackermail%40gmail.com&ok=Invite

El fallo residía en que el mecanismo de autenticación y comprobación de seguridad solo miraba el primer parámetro blogID que llegaba en la petición, comprobando que el usuario tenía permisos sobre ese blog. Sin embargo, la operación real que añadía el autor invitado se realizaba utilizando la segunda ocurrencia de blogID, que correspondía al blog de la víctima.

Gracias a esta contradicción interna y a la forma en que el servidor manejaba los parámetros duplicados, el atacante lograba pasar las comprobaciones de seguridad para su propio blog pero ejecutar la acción sobre el blog ajeno. El resultado era un bypass completo de autenticación con una sola petición bien construida.

Este caso demuestra muy bien cómo la HPP no es solo una “curiosidad técnica”, sino una técnica con impactos reales en sistemas de grandes proveedores. Además, pone de manifiesto la importancia de que las comprobaciones de seguridad y la ejecución de operaciones usen exactamente los mismos valores de parámetro, sin depender de precedencias no controladas.

HPP y cortafuegos de aplicaciones web (WAF)

Muchas organizaciones confían en un WAF como capa adicional para proteger sus aplicaciones web de ataques conocidos. Estos cortafuegos suelen basarse en reglas y firmas (expresiones regulares) que se aplican sobre los parámetros, cabeceras e incluso el cuerpo de las peticiones HTTP.

El problema es que, ante la presencia de parámetros duplicados, un atacante puede fragmentar una carga maliciosa en varios valores de un mismo parámetro. Mientras el WAF analiza cada parámetro por separado, es posible que ninguno de los valores aislados coincida con las firmas de ataque, por lo que la petición pasa los filtros sin ser bloqueada.

Una vez que esa petición llega al servidor web, el motor de la aplicación o el propio servidor reensambla los valores según su lógica interna (por ejemplo, concatenándolos con comas o tomando el último), dando lugar a una cadena que, en conjunto, sí constituye el ataque. De este modo, la misma técnica de polución de parámetros permite bypassear WAFs que no están preparados para analizar el conjunto de valores concatenados.

Además, algunos WAF que no funcionan como reverse proxy (proxy inverso) y que no tienen una visión completa del flujo entre cliente y servidor, sino que actúan más como filtros puntuales, pueden ser especialmente vulnerables a estos bypass mediante HPP. Aquellos basados en tecnologías como Apache con un motor de scoring de parámetros y análisis estadístico tienden a comportarse mejor frente a este tipo de técnicas.

En definitiva, HPP demuestra que incluso con un WAF correctamente configurado, la seguridad no está garantizada si la propia lógica de la aplicación y el servidor maneja mal los parámetros duplicados. La protección debe ser integral y tener en cuenta cómo se procesan las peticiones a todos los niveles.

Casos reales, herramientas y prevalencia de HPP

Investigaciones académicas y trabajos de expertos en seguridad han demostrado que la HTTP Parameter Pollution está lejos de ser una rareza. Proyectos como PAPAS (PArameter Pollution Analysis System), impulsado por investigadores como Carmen Torrano, se diseñaron precisamente para detectar automáticamente vulnerabilidades HPP en aplicaciones web a gran escala.

En experimentos realizados sobre más de 5000 sitios web de gran popularidad (según rankings como Alexa), se observó que casi un 30 % de los sitios analizados contenían al menos una página vulnerable a HPP. Es decir, era posible inyectar un parámetro codificado dentro de otro existente y comprobar que aparecía decodificado en alguna URL o formulario resultante.

Más llamativo aún es que cerca del 47 % de las vulnerabilidades encontradas (lo que equivale a alrededor del 14 % del total de sitios) eran realmente explotables, permitiendo ataques que iban más allá de simples fallos de presentación. Entre los sitios afectados se encontraban grandes nombres como Microsoft o Google, lo que deja claro que ni siquiera los gigantes tecnológicos están exentos de estos problemas.

Herramientas como PAPAS han servido para analizar y cuantificar el problema, pero también han puesto sobre la mesa la dificultad de detectar HPP de forma automática. Muchos de los escáneres de vulnerabilidades web tradicionales no contemplan de forma exhaustiva los escenarios de parámetros duplicados, o generan un volumen muy alto de falsos positivos.

Además de soluciones específicas como PAPAS, existen extensiones como HPP Finder para Google Chrome, orientadas a detectar posibles vectores de ataque HPP en URLs y formularios HTML. Aunque puede ayudar a identificar puntos sospechosos (por ejemplo, aquellos formularios que reutilizan parámetros sin validación adecuada), no constituye una solución completa ni un sustituto de una auditoría de seguridad en profundidad.

Otra herramienta muy utilizada en el ecosistema de pruebas de seguridad es OWASP ZAP, que incluye extensiones y scripts para probar diferentes vectores, entre ellos los relacionados con parámetros en la query string. No obstante, en el caso concreto de HPP, sigue siendo necesario combinar herramientas automáticas con análisis manual y comprensión del flujo de la aplicación.

HPP en buscadores internos y ejemplos como Apple.com

Los HPP no solo se han observado en sistemas de gestión de blogs o paneles de administración, también aparecen en funciones aparentemente inocuas como buscadores por etiquetas en foros y comunidades online. Un ejemplo llamativo se encontró en los foros de Apple, donde la gestión de etiquetas y parámetros polucionados mostraba comportamientos curiosos.

En estos foros, al seleccionar una etiqueta en la interfaz, se añadía un parámetro tags a la query string de la URL con el valor de la etiqueta elegida. La aplicación en el backend recogía ese valor, realizaba una búsqueda de temas con esa etiqueta y lo mostraba al usuario. Si se seleccionaban varias etiquetas, se añadían todas en el mismo parámetro tags, separadas por el operador de suma (+), de forma que el backend estaba preparado para procesar esa lista.

Cuando se probó a polucionar el parámetro tags con varios valores duplicados, se observó que la tecnología del backend generaba una lista separada por comas (CSV) con todos los valores de los parámetros polucionados. La aplicación era capaz de procesar parcialmente esa lista (descubrir las diferentes tags) pero no imprimía bien todas las etiquetas en el campo de texto del buscador.

En este contexto concreto no parecía existir un bug de seguridad explotable, pero sí quedaba claro que había escenarios no contemplados por los desarrolladores. En otras aplicaciones menos inocentes, un comportamiento similar podría derivar en desajustes entre lo que se valida, lo que se usa y lo que se muestra al usuario, con consecuencias más serias.

El análisis de las tecnologías subyacentes en foros como los de Apple (por ejemplo, Apache con J2EE en el backend) muestra que muchos stacks modernos se comportan de forma parecida a servidores como IIS o combinaciones como Apache con Python al gestionar parámetros polucionados, generando listas separadas por comas y delegando en la lógica de aplicación el tratamiento final de esos valores.

Este tipo de ejemplos sirve para recordar que no basta con que “parezca que funciona” en los casos normales: hay que probar sistemáticamente cómo reacciona la aplicación cuando se le envían parámetros duplicados, valores codificados de forma extraña, combinaciones inusuales, etc., porque ahí es donde la HPP encuentra su hueco.

Detección y mitigación de HTTP Parameter Pollution

Detectar y mitigar HPP requiere un enfoque mixto que combine buenas prácticas de desarrollo seguro, configuración adecuada del servidor y uso de herramientas específicas. No es suficiente confiar en que el WAF lo va a arreglar todo, porque como hemos visto, muchas veces es precisamente esa capa la que puede ser engañada.

Desde el punto de vista del desarrollo, es fundamental que los programadores sean conscientes de que un parámetro puede tener múltiples valores y que deben decidir explícitamente cómo tratar ese caso. No se debe depender de comportamientos por defecto del lenguaje o del framework sin entender bien cómo funciona la precedencia de valores.

También es recomendable que, en puntos críticos como autenticación, autorización, operaciones sensibles o cambios de estado importantes, se valide de forma estricta que los parámetros solo aparecen una vez, rechazando peticiones con parámetros duplicados o, al menos, registrándolas para su análisis.

En la parte de infraestructura, conviene revisar las configuraciones del servidor web y del framework para comprender exactamente qué ocurre cuando se recibe un parámetro repetido: si se conserva el primero, el último o todos concatenados. A partir de ahí se puede ajustar la lógica de aplicación para que no haya discrepancias entre validación y uso efectivo del valor.

En cuanto a herramientas, además de los escáneres de vulnerabilidades habituales, es útil incorporar soluciones focalizadas como PAPAS o extensiones tipo HPP Finder en el flujo de pruebas. Si se utiliza OWASP ZAP u otras herramientas de pentesting, es interesante diseñar scripts específicos que generen peticiones con parámetros duplicados y valores codificados de distintas formas para observar la reacción de la aplicación.

Finalmente, es importante asumir que la HPP es un problema mucho más extendido de lo que se suele pensar, especialmente en aplicaciones grandes y con muchos años de evolución. Combinar formación, revisión de código, pruebas automáticas y tests manuales bien planteados es la mejor forma de mantener estos fallos bajo control.

La contaminación de parámetros HTTP se ha ganado a pulso un lugar entre las técnicas de ataque web que cualquier equipo de desarrollo y de seguridad debería tener en su radar: es discreta, difícil de ver con una simple mirada a los logs y puede tener consecuencias muy serias si afecta a parámetros clave de la lógica de negocio o de los controles de seguridad. Entender cómo se gestionan los parámetros duplicados en tu stack, y probar activamente estos escenarios, es una de esas tareas que quizá dan algo de pereza al principio, pero que marcan la diferencia entre una aplicación simplemente funcional y una aplicación realmente robusta frente a ataques avanzados.