Siendo éstos los tiempos de la Web 2.0, es muy habitual que una empresa ofrezca servicios a través de aplicaciones Web; éstas se convierten en la interfaz perfecta para que todo el mundo desde cualquier lugar acceda a información que muy probablemente se almacena en bases de datos. 
Esta entrada (y otras que le seguirán) viene a mostrar uno de los ataques más habituales hoy en día en este tipo de aplicaciones: el ataque de inyección SQL, por el que adquiere especial importancia el tratamiento de la información que fluye entre el aplicativo visible al usuario que la muestra (lo que podríamos llamar el frontend) y la base de datos que la almacena y gestiona (lo que vendría a ser el backend).
Dejando los detalles técnicos para más adelante, este ataque se basa en explotar la interacción con el usuario ofrecida por aplicaciones Web (formularios de petición de datos, por ejemplo) para hacer llegar a la base de datos consultas SQL manipuladas, que al no ser filtradas correctamente por el aplicativo web pueden tener efectos indeseados, como proporcionar información sobre el sistema, la estructura de la BD, o incluso acceso o borrado de los datos almacenados. Una variante muy interesante de este tipo de ataques es el “Blind SQL Injection“, o ataque a ciegas por inyección SQL, que aprovecha el resultado obtenido tras lanzar consultas que emiten páginas de error no tratadas por el desarrollador de la aplicación.
Se requiere de varias técnicas y algo de dedicación para poder filtrar este tipo de ataques. De nada sirve, por ejemplo, tener un servidor Web sirviendo páginas cifradas si el atacante puede insertar cualquier tipo de parámetros, lo que además invalidaría un sistema de detección de intrusos, puesto que no podría descifrar los accesos. Hay que tener en cuenta que el atacante intentará aprovechar cualquier información que le proporcione indicios de alguna vulnerabilidad, comenzando por algo tan simple como puede ser la versión de nuestro gestor de base de datos, el nombre de cada una de las tablas, usuarios por defecto,… y así sucesivamente, hasta conseguir en el peor de los casos usuarios con permisos de administración e incluso la ejecución a través de comandos en el propio sistema que soporta la base de datos.
Como en la mayoría de los casos, las tareas que hay que realizar orientadas a prevenir este tipo de ataques no suponen un gran esfuerzo en comparación con el trabajo que supondría restaurar la información de una base de datos que ha sido comprometida, así como la credibilidad de los usuarios al comprobar que se ha detectado un ataque culminado en una base de datos con información relevante, entre otros muchos factores negativos (¿… de cuándo dices que es la última copia …?). Como siempre, evitar el robo de información y el tratamiento no controlado ni permitido de ésta requiere una atención especial.
Sin extendernos más, y como cierre de esta introducción, la seguridad aplicada a la integridad y privacidad de los datos almacenados en las bases de datos no es trivial, pero podemos tener cierto grado de tranquilidad si aplicamos algunas recomendaciones para los distintos casos y métodos de ataque.
[Gráfico de Acunetix.com]
