Por todos es conocido que los servidores web son uno de mayores objetivos de los ataques de hoy en día. El dinero y los datos accesibles a través de los portales web, con la finalidad de ofrecer un servicio, una vez más, se ven afectados por una nueva amenaza, un nuevo tipo de ataque.

En concreto, esta nueva técnica ha sido expuesta durante la conferencia OWASP Appsec Poland 2009 por parte de los expertos en seguridad Stefano Di Paola y Luca Carettoni y ha llegado en modo de correo a los suscritos a Bugtraq.

¿En qué consiste el ataque?
Pues una vez más (como sucede con un SQL Injection o una inyección de comandos) en la reacción que tiene el servidor web ante la manipulación de algún parámetro o cabecera en una aplicación web.

En este caso, consiste en la interpretación que tiene un servidor web cuando se repite el nombre de un parámetro dentro de la misma petición. Un ejemplo:

http://www.miaplicacion.com/index.asp&variable1=val1&variable2=val2

En este caso, cada variable recibiría su valor correcto por parte del servidor web y todo OK.

Sin embargo, supongamos que http://www.miaplicacion.com/index.asp&variable1=val1&variable1=val2

¿Qué valor tendría variable1 esta vez? Pues la respuesta es: depende del servidor web que lo interprete. Unos servidores asignarán el val1 y otros asignarán val2. En otros casos como IIS, su mecanismo interno los concatenará.

Por ejemplo, IIS se sabe que los concatena separándolos por comas. Apache solamente se queda con el primer valor que recibe un parámetro desechando el resto.

El impacto de este comportamiento por parte de los servidores Web puede ser enorme a la hora de procesar los argumentos, y puede dar lugar a múltiples posibilidades como sobreescritura de parámetros HTTP definidos por la aplicación en la URI, alteración del comportamiento de la aplicación, acceso y modificación de variables,... etc

Algo muy interesante es que aquellas empresas que como medidas preventivas de protección de sus aplicaciones web tengan un WAF (Web Application Firewall), que les permita sanitizar la entrada de las peticiones entrantes, tampoco estarán protegidas del todo.

En líneas generales, los Firewalls de Aplicaciones Web analizan las peticiones web basándose en firmas generalmente. Estas firmas son expresiones regulares que enfrentan contra las peticiones (los parámetros, las cabeceras, incluso el cuerpo de la página, etc...) de manera que, como si de un antivirus se tratara, si alguna de las "cadenas" coincide con la petición, la misma es bloqueada. Ahora bien, aprovechando esta nueva línea de ataque, es posible encapsular en la misma variable (repetida varias veces con diferente valor) un ataque, que si fuera en una sola variable, sería fácilmente detectada y bloqueada por cualquier WAF. De esta manera, al analizar cada parámetro, no se delimitaría como algo maliciosa la petición y sin embargo, al ser reensamblada e interpretada por el servidor web, sí que podría ser un riesgo en la seguridad de la aplicación.

Aquellos WAFs que no estén basados en tecnología de reverse proxy (proxy inverso) permitirán ser bypasseados ante este tipo de ataque.

Como ya indicamos en posts(1) anteriores( y 2), existe algún Firewall de Aplicaciones Web con un motor basado en ponderar los valores de los diferentes parámetros (con un funcionamiento parecido a un antispam) que en algunos de estos casos sería completamente efectivo (scoring list) además de porque está basado en tecnología de proxy inverso y en Apache, que como hemos visto sólo se quedaba con el primer valor asignado a un parámetro, reenviando sólo este valor al servidor final.

La presentación completa puede ser descargada aquí así como vista en Slideshare. Su lectura es altamente recomendable.

Fuente:http://www.securitybydefault.com/2009/05/seguridad-web-http-parameter-pollution.html

Muy buena, en la mayoría de los casos se produce un disclosure revelando parte de la sintaxis sql de un sitio o el error del proceso en java cuando filtra en forma numérica.

http://web-fantasma.xx/ff.asp?SPID=1&SPID=2