Un ataque de Inyección SQL consiste en la inserción o “inyección” de datos en una consulta SQL desde un cliente de la aplicación. El éxito en una inyección SQL puede leer datos sensibles de la base de datos, modificar los datos (insertar/actualizar/borrar), realizar operaciones de administración sobre la base de datos (como reiniciar el DBMS), recuperar el contenido de un archivo del sistema de archivos del DBMS y, en algunos casos, ejecutar comandos en el sistema operativo.
Los ataques de de Inyección SQL están divididos en las tres siguientes clases:
Inband: los datos son extraídos usando el mismo canal que es usado para inyectar el código SQL. Este es el tipo de ataque más simple, en el que los datos recibidos se muestran en la propia aplicación web.
Out-of-band: los datos son extraídos usando un canal diferente (por ejemplo, un correo con el resultado de la consulta es generado y enviado al auditor).
Inferential: no hay transferencia de datos, pero el auditor puede reconstruir la información enviando peticiones y observando el comportamiento que mantiene el servidor de bases de datos.
Independientemente del tipo de ataque, una Inyección SQL correcta requiere que el atacante pueda construir una consulta SQL correcta. Si la aplicación devuelve un mensaje de error a causa de una consulta incorrecta, entonces en fácil reconstruir de forma lógica la consulta original y, por lo tanto, entender cómo realizar una inyección correctamente.
Sin embargo, si la aplicación oculta los mensajes de error, un auditor puede conseguir por medio de ingeniería inversa la lógica de la consulta original. Este último caso se conoce como “Inyección SQL Ciega” (Blind SQL Injeccion).
Detección
El primer paso en esta prueba es entender cuando nuestra aplicación conecta a un servidor de bases de datos (BBDD) para acceder a algún dato. Los ejemplos típicos de casos en los que una aplicación necesita comunicarse con una BBDD incluyen:
Formularios de autenticación: cuando la autenticación es realizada usando un formulario web, es probable que las credenciales de un usuario sean comprobadas contra una BBDD que contenga todos los usuarios y claves (o mejor, el hash de las claves).
Motores de búsqueda: la cadena enviada por el usuario puede ser usada en una consulta SQL que recupere todos los registros relevantes de la BBDD.
Webs de E-Commerce: los productos y sus características (precio, descripción, disponibilidad,…) son siempre almacenados en una BBDD relacional.
Un auditor tiene una lista de todos los campos que pueden ser usados para crear una consulta SQL, incluyendo los campos ocultos de una petición POST y entonces los prueba por separado, intentando modificar la consulta real y producir un error.
La prueba más básica consiste en añadir una comilla simple (‘) o un punto y coma (;) al campo que se quiere probar. Lo primero es usado como fin de cadena y, si la aplicación no está filtrada puede llevar a una consulta incorrecta. Lo segundo es el fin de una sentencia SQL y, si no está filtrado, puede generar un error. La salida de un campo vulnerable puede ser similar a lo siguiente.
error: You have an error in your SQL syntax; check the manual that corresponds to your
MySQL server version for the right syntax to use near ””’ at line 1
Query: SELECT * FROM accounts WHERE username=’juan’ AND password=”’ (0)
También los comentarios (–) y otras palabras reservadas como ‘AND’ y ‘OR’ pueden ser usadas para intentar modificar una consulta. Una técnica muy simple pero aún efectiva es insertar una cadena en un campo donde se espera un número.
Un mensaje de error, como los ejemplos anteriores, ofrece una gran cantidad de información al auditor con el fin de crear una inyección con éxito. Sin embargo, las aplicaciones a menudo no ofrecen mucho detalle: un simple ‘500 Server Error’ o una página de error preparada puede ser lo que se muestre, lo que significa que necesitamos usar técnicas de inyección SQL ciega (Blind SQL Injection).
En cualquier caso, es muy importante probar cada campo por separado: solo una variable debe variar mientras que todas las demás se mantienen constantes, con el fin de entender correctamente qué parámetros son vulnerables y cuáles no lo son.
Si quieren profundizar sobre SQL Injections, pueden ingresar a W3SCHOOLS.
