Climens Codelog

Hoy, además de saberse ya oficialmente que se ha aprobado OOXML (ahorraré comentarios sobre el tema), han empezado las Jornadas de Testeo de Software 2008 organizadas por el ITI.

Para empezar han contado con la participación de Lee Copeland de Software Quality Engineering y autor del libro A Practitioner's Guide to Software Test Design explicando casos de testeo de tipo caja negra (black box). Ha estado interesante como resumen práctico y organizado de lo que algunos hemos ido descubriendo con la práctica.

Primero ha explicado lo que son este tipo de tests, que se basan únicamente en comprobar las salidas de un elemento (caja negra, que puede ser una función, un sistema, etc...) a partir de unas entradas.

Después se ha centrado en la parte científica:

• Particionado en clases de equivalencia
• Valores de contorno
• Tablas de decisión
• Diagramas de estados-transiciones
• All-pairs (no sé como traducirlo)

Para terminar con una explicación de la parte "artística": es decir, usar todas estas técnicas combinadas con la experiencia y cierta mala leche para encontrar fallos y errores.

Se he hecho bastante hincapié en que no se puede testar todo. Hay que decidir sobretodo basándose en las experiencias previas y en el riesgo que conllevaría un fallo de dichas partes.

En conclusión, en el término medio está la virtud: ni una aproximación totalmente basada en la ciencia del testado ni confiar plenamente en nuestras habilidades (o las de otros) para encontrar fallos por intuición y práctica.

Ha dejado un enlace interesante a la página de James Bach, donde hay alguna herramienta para calcular tablas de All-pairs y información sobre testeo.

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.

Hacía tiempo que tenía pendiente en mi trabajo probar el Selenium, pero era una de esas cosas que uno lo mira un día, no le acaba de ver el punto y lo deja para más adelante. Y no es que no sea útil, realmente es completo, funciona en varias plataformas, tanto de navegadores como de sistemas operativos. Tiene un IDE sencillo que genera scripts e incluso es ámpliamente usado en Ruby on Rails, el framework de moda. Pero aun así, no me acabó de entrar por el ojo.

Una de las pegas que siempre le encontré fue que la integración en los proyectos web de .NET y en tests de NUnit no era lo más cómodo ni simple. Barreras, en definitiva. Pero he descubierto que no era el único que tenía esta impresión: he visto una comparativa de WatiN, Watir y Selenium (siempre hay alguien que te facilita el trabajo). Leyéndolo he decidido probar WatiN.

Y la verdad que la experiencia ha sido muy positiva. Los tests son sencillos de escribir, funcionan como es de esperar y con un lenguaje sencillo y claro. He probado primero algo parecido al ejemplo que hay en su página de inicio y por desgracia no ha funcionado a la primera. Pero estaba claro que algo estaba haciendo mal porque todo se colgaba a la hora de cerrar el Internet Explorer... Después de darle un par de vueltas he desactivado todos los plugins y voilà: funcionaba perfectamente. Al final era el Flashget que interactuaba de forma un tanto extraña.

Después me he puesto a jugar validando alerts de javascript y se ha complicado un poquillo, pero recurriendo a las listas de correo, alguien había preguntado ya mis dudas, como siempre. Al final el uso del DialogHandler ha quedado algo tal que así:

 
        [Test]
        public void BasicTest()
        {
            using(IE ie = new IE("http://intranet/formulario.aspx"))
            {
                AlertDialogHandler alertHandler = new AlertDialogHandler();
                ie.DialogWatcher.Add(alertHandler);
 
                ie.Button(Find.ByName("Continuar")).ClickNoWait();
 
                alertHandler.WaitUntilExists(5);
                alertHandler.OKButton.Click();
            }
        }
 

Realmente es duro y laborioso escribir este tipo de tests, pero como puede que mi futuro pase por diseñar un nuevo producto más o menos complejo durante unos cuantos meses, el testado de la interfaz de usuario será importante para validar que todo funciona como es debido.

• Link: WatiN, Watir and Selenium reviewed