Climens Codelog

De un tiempo a esta parte habían empezado a llegar a una cuenta de correo que tenemos configurada para recibir los informes de error de las distintas aplicaciones web una serie de errores bastante sospechosos. Eran todo URLs con cadenas de texto en parámetros numéricos que hacían fallar la página. Esto se producía evidentemente por nuestra pobre comprobación de los parámetros que producía que en algunos casos el valor numérico en cuestión llegase tal cual a una consulta en la base de datos, fallando estrepitosamente.

Lo curioso del caso es que solamente ocurría en algunas webs concretas y siguiendo siempre el mismo patrón: claramente usaban una herramienta que buscaba posibles vectores de inyección SQL o similares. Era un mecanismo bastante burdo pero seguro que en algún sitio algo encontraron. Además las IPs eran variadas así que posiblemente se debía a la aparición de alguna herramienta en algún foro de script kiddies.

Y me dije: yo quiero hacer lo mismo. Así que me puse a buscar y encontré algunas herramientas, siendo la más interesante Wapiti, un fuzzer sencillo hecho en Python con las siguientes funcionalidades:

• Detección de errores en la gestión de ficheros (fopen, includes...)
• Inyección SQL
• Inyección XSS
• Inyección LDAP
• Ejecución de comandos (eval(), system()...)
• Inyección CRLF (HTTP splitting)

Además muestra un mensaje de alerta cada vez que se produce un error 500, con lo que es ideal para analizar aplicaciones hechas en ASP (ehem).

Así pues hice un testado exhaustivo con esta herramienta a nuestro código base y la verdad que encontré cosas interesantes, como un error de lo más ingenuo que daba paso a un bonito ataque XSS o unas cuantas entradas sin proteger que proporcionaban posibles ataques SQL jugando con los parámetros. Otros errores no eran tan evidentes y se basaban en jugar con los datos enviados por POST, que por cierto para las pruebas encontré imprescindible la extensión Live HTTP Headers que permite ver el tráfico HTTP y luego repetir una llamada modificando las cabeceras (con calculadora automática del Content-Length, afortunadamente).

He de decir que esto evidentemente no es una herramienta de revisión de código pero si me tengo que poner a revisar toda nuestra base de código antiguo apaga y vámonos. Más vale un poco de protección que ninguna protección, por lo menos la valla un poco más alta que la del vecino.

Posiblemente aun queden muchos agujeros que tapar pero en general ya solemos usar protección para todos los parámetros que entran como comprobar que los números son valores numéricos y que las cadenas de texto son como deben ser y no tienen gato encerrado (ver el XSS FAQ para un método bastante competo de protección).

En resumen, que a lo largo de los años se ha descuidado muchas veces la seguridad de aplicaciones web (las prisas, la poca importancia atribuida, el desconocimiento, etc) y cada vez hay más y mejores técnicas para sacar provecho de nuestros fallos, por lo que cualquier comprobación no está de menos.

Actualización 08/03/2008: Kriptópolis se hace eco de un artículo interesante llamado "El mito de la seguridad web total". Interesante lectura.