Protegerse de las inyecciones SQL por URL

Stop Nos contaba el otro día el vecino de blog Gustavo Velez como su sitio, que corre sobre Sharepoint, ha sido atacado. Todos los que gestionamos algún tipo de comunidad online sabemos que Internet se ha convertido en un lugar peligroso donde un motón de delicuentes, amparándose en el anonimato, se dedican a hacer la vida imposible a todo aquel que quiere contar algo al mundo. Desde que gestiono Geeks.ms la cantidad de maldades que el sitio ha sufrido han sido incontables y de todo tipo. Todas con un mismo afán: colar spam en el sitio o lograr colar spam a los usuarios del sitio publicando URLs maliciosas en el mismo. Sin duda el spam es un lacra y una enorme amenaza para Internet. El ataque que ha sufrido el sitio de Gustavo también tenia ese mismo fin.

Uno de los ataques más frecuentes en los últimos tiempos es una variación de las clásicas inyecciones de SQL: la inyección de SQL por URL. Se trata en esencia de pasar en la URL una cadena SQL para tratar de que el sistema atacado la ejecute. La principal protección frente a este tipo de situaciones es un buen diseño de la aplicación, protegerse de cross site scripting, de los ataques de inyección en general, y de los de SQL en particular y utilizar un enfoque de continua defensa cuando se desarrollan soluciones. Por ejemplo, utilizar consultas parametrízadas siempre nos evitará un motón de quebraderos de cabeza relacionados con las inyecciones de SQL (sean por URL o no y sea la aplicación Web o de escritorio). El problema es que en una aplicación basta cometer un solo error para que sea comprometida. Como todos los desarrolladores cometemos errores (los desarrolladores, pese a lo que algunos piensen, tamibén somos humanos) la conclusión es que toda aplicación es probable que contenga errores explotables por terceros para hacer el mal. En resumen, aunque es sumamente importante, solo el ser cuidadoso en lo referente a la seguridad durante el desarrollo a menudo no es suficiente.

La buena noticia, es que contamos con una segunda táctica de defensa, que siempre debe ser adicional al buen diseño: la posibilidad una vez desplegada la aplicación asegurarla mediante otros sistemas adicionales. Los firewalls, los filtros antispam y los sitemas de detección de intrusiones son el ejemplo más conocido de estos sistemas adicionales de protección. Pero en el caso que nos ocupa, ninguno de estos tres sitemas nos serviran de ayuda. Esto me llevo a pensar ¿qué podríamos hacer para evitar las peticiones maliciosas que intentan ataques SQL por URL?.

La conclusión es evidente: si logramos detener esas peticiones maliciosas ‘en la puerta’, no pasará nada aunque nuestra aplicación sea vulnerable. Contaremos con una defensa adicional. Lo importante es que los ‘juanquers’ tienden a atacar aquellos sitios menos protegidos. Si un ‘juanquer’ ataca un sitio y ve que tiene ciertas protecciones recibe un mensaje claro: este sitio está administrado por alguien que va a tratar de ponerte las cosas dificiles. Por lo tanto el ‘juanquer’ moverá sus efuerzos a otro sitio. Muchos de estos ataques son llevados a cabo por bots automatizados, que comprueban si sus esfuerzos son productivos o no y si no lo son simplemente sacan el sitio de sus listas de sitios a explotar.

Bueno, ya tenemos nuestras táctica de defensa: evitar que ciertas peticiones, que contienen ciertos elementos en la URL que delatan su mala intención, alcancen la aplicación. Esta técnica, que se puede implementar de diferentes maneras y con diferentes utilidades se conoce como ‘URL sanitizing’ o validación de URLs. La idea es filtrar ciertas peticiones tan pronto alcanzan nuestro servidor Web y rechazarlas. En un entorno IIS contamos con varias opciones:

UrlScan 3.0 o Request Filtering: UrlScan es un filtro ISAPI que pemite restringir el tipo de URLs que nuestro servidor va a procesar. Bloqueando ciertos tipos de peticiones HTTP por URL vamos a poder para ciertos tipos de ataques que utilizan la URL como vector. UrlScan no solo aplica para los ataques de inyección de SQL por URL, sino también para inyecciones de otro tipo o inyecciones que usen cabeceras. Podéis descargar UrlScan gratuitamente, tanto para servidores de 32 como de 64 bits. Además el equipo de IIS ha publicado una configuración de UrlScan diseñada para evitar los ataques de inyección de SQL, entre muchas otras. Es importante destacar que se debe usar la versión 3.0 de UrlScan (actualmente en beta), pues versiones anteriores no analizaban lo que se pasaba en el query string, solo analizaban la URL. Se puede usar esta herramienta con IIS 5, 6 y 7, si bien es cierto que en IIS 7 la funcionalidad de UrlScan se ha incluido en un módulo llamado Request Filtering con el que podemos usar denyUrlSequence para especificar que elemento nos son permitidos en las URLs.

IIS 6 SQL Injection Sanitation ISAPI: Es un proyecto que podemos encontrar en Codeplex y que consiste en un filtro ISAPI especialmente dedicado a frenar ataques de inyección por SQL. En principio creo que la opción mas interesante es UrlScan, pero este proyecto nos proporciona el código fuente y es sin duda interesante para ante situaciones de ataques específicos saber como desarrollar una ‘antidoto’ especifico para la solución. Además este ISAPI es más simple de desplegar y configurar que UrlScan, aunque también es mucho menos flexible y potente.

Espero que estas dos utlidades os resulten útiles.

7 comentarios sobre “Protegerse de las inyecciones SQL por URL”

  1. Muy interesante Rodrigo y necesario para todo webmaster que gestione un sitio web con acceso a base de datos

    Los juanquers que dices se intentarán aprovechar del desconocimiento de algunos webmasters novatos 😉

    Saludos desde la otra punta del pais

    Sergio

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *