90-60-90, Desarrollos a medida...

Muchas aplicaciones Web utilizan partes de las URLs como parámetros de entrada de la propia aplicación. Un ejemplo de ello son los Sistemas de Gestión de Contenidos o CMS.

En Drupal, por ejemplo, todos los contenidos son denominados nodos y pueden ser accedidos a través de URLs como la siguiente:

http://www.example.com/node/21947

De este modo, 21947 es un parámetro de entrada que le dice al CMS qué contenido tiene que recuperar de la Base de Datos.

Al ser un parámetro de entrada que además se utiliza para consultar una Base de Datos... en principio podría ser susceptible a inyecciones de código. Por "desgracia", la mayor parte de los CMS ya contemplan esta posibilidad y están protegidos contra este vector de ataque.

¿Pero qué pasa con los desarrollos a medida que imitan este funcionamiento? Hace poco me he encontrado con una aplicación Web que utilizaba URLs como la anterior en la que se puede ver que una parte de la misma es un parámetro de entrada.

Así, se me ocurrió probar a acceder a recursos como:

http://www.example.com/node/21947'%20and%20'a'='a
http://www.example.com/node/21947'%20and%20'a'='b

y... ¡¡bingo!! La aplicación tenía una inyección de código SQL en una de las partes que formaba la propia URL.

De hecho, la URL era más compleja que la anterior. La inyección estaba más o menos por la mitad y tenía parámetros por GET, pero todos estaban cabreantemente limpios:

http://www.example.com/user/21947'%20and%20database()%20like%20'mydb'%20and%20'a'='a/getProfile?a=b&c=d

¿Quién les iba a decir a los desarrolladores de la aplicación que se habían dejado un punto de entrada sin validar? Y no sólo eso, sino ¿a qué herramienta de análisis automático se le ocurriría realizar este tipo de pruebas? Las pruebas que tendría que realizar por cada URL se multiplicarían y el tiempo de análisis sería mucho mayor.

En resumen, desde el punto de vista del auditor, las herramientas automáticas sólo sirven para dar una primera impresión del estado de seguridad de un sistema pero siempre hay que escavar mucho más profundo para hacer un análisis exhaustivo.

Desde el punto de vista de los desarrolladores, siempre hay que validar absolutamente todos los parámetros de entrada de la aplicación, por muy recónditos que puedan parecer. Hay que pensar que es imposible prever todos los usos que hará un usuario (legítimo o no) de la aplicación, por lo que hay que intentar no dejar nada al azar.