Polución de parámetros y cortafuegos de aplicaciones web

Igual es excesivamente técnico pero tiene que ver con cosas que ya habíamos comentado y por eso me gusta traerlo aquí: Bypassing WAF via HTTP Parameter Pollution. Y como recordatorio de que algunas herramientas nos ayudan, pero nada supera a haber hecho bien las cosas desde el principio.

Sobre polución de parámetros http: Contaminación de parámetros HTTP (HPP), Inyección de SQL a través de cabeceras HTTP y algunos más.

Anuncios

Inyección de SQL a través de cabeceras HTTP

Todo lo que viene del exterior es (potencialmente) inseguro. En SQL Injection through HTTP Headers nos recuerdan que las cabeceras del protocolo HTTP las proporciona el visitante y que pueden venir con ‘regalos’:

Cookies and other stored HTTP headers should be treated by developers as another form of user input and be subjected to the same validation routines.

Ya hablamos hace algún tiempo del tema de forma un poco más técnica, en:

Polución de parámetros del protocolo HTTP
PAPAS: ¿Somos vulnerables a la polución de parámetros HTTP?
Contaminación de parámetros Http
Contaminación de parámetros HTTP (HPP)

Contaminación de parámetros Http

Ya habíamos hablado del tema de la contaminación de parámetros Http (polución, decían) en Contaminación de parámetros HTTP (HPP), PAPAS: ¿Somos vulnerables a la polución de parámetros HTTP? y Polución de parámetros del protocolo HTTP.
Esencialmente, se trataba de añadir parámetros extra en las peticiones que, dependiendo del servidor y la aplicación podían utilizarse para obtener algún beneficio.

En [PDF] Http Parameter contamination, vemos cómo se puede llevar el tema por otro camino: aprovechar la forma en que interpretan los servidores web determinados caracteres para saltarse los cortafuegos de aplicaciones. Por ejemplo, algunos servidores y configuraciones cambiarían el caracter “]” por el carácter “_”.

Uno no puede fiarse de nada.

Contaminación de parámetros HTTP (HPP)

Ya hablamos en su día de la Polución de parámetros del protocolo http y de la herramienta que lanzaron para tratar de detecarlos en PAPAS: ¿Somos vulnerables a la polución de parámetros HTTP?.

En HPP: Http Parameter Pollution hay una notita explicando el problema en nuestro idioma de Carmen Torrano que está trabajando en la herramienta y que muchos encontrarán de interés (si es que no la han leido ya, claro).

PAPAS: ¿Somos vulnerables a la polución de parámetros HTTP?

Ya hablamos hace algún tiempo de Polución de parámetros del protocolo HTTP. Sus autores han seguido trabajando en el tema y ahora presentan un servicio para comprobar si somos vulnerables: HTTP Parameter Pollution. So how many flawed applications exist out there?! We go online with a new service.

El servicio está en PAPAS: PArameter Pollution Analysis System (Beta) y hay un artículo que lo explica en [PDF] Automated Discovery of Parameter Pollution Vulnerabilities in Web Applications.

Polución de parámetros del protocolo HTTP

Luca Carettoni y Stefano di Paola nos descubren un nuevo problema de validación de los datos de entrada (un clásico). Esencialmente, muchas aplicaciones no comprueban que los datos de entrada son los que tienen que ser (en número y forma) y eso puede ocasionar tratamientos ligeramente diferentes en distintas configuraciones y, en definitiva, problemas.

Cada uno de ellos lo cuenta en su bitácora, HTTP Parameter Pollution (HPP) y Http Parameter Pollution a new web attack category (not just a new buzzword :p) y se pueden ver y/o descargar las transparencias de su presentación en el OWASP 2009, en Http Parameter Pollution, a new category of web attacks.

De paso, como ellos mismos bromean, tenemos unas nuevas siglas en el panorama, HPP: HTTP Parameter Pollution.