En las Aplicaciones ASP, SQL Injection suele producirse habitualmente a través de aplicaciones que utilizan una variable sobre la que construyen la cadena SQL que posteriormente ejecutará sobre el motor de base de datos a través del modelo de objetos de ADO (ej: ADODB.Connection, ADODB.Recordset, ADODB.Command, etc.). Para entenderlo mejor, hemos desarrollado un ejemplo en el Laboratorio de GuilleSQL, en el que vamos a suponer el caso típico, es decir, un formulario ASP utilizado para que los usuarios de una Aplicación ASP se autentiquen, empleando para ello dos cajas de texto (txtUsuario y txtPassword) y un botón, de tal modo que al hacer click sobre el botón se ejecutará un código ASP similar al siguiente:
<%
strUsuario = Request.Form("txtUsuario")
strPassword = Request.Form("txtPassword")
strSQL=""
strSQL = strSQL + "SELECT * FROM GuilleSQL.USUARIOS"
strSQL = strSQL + " WHERE USU_ID='" & strUsuario & "'"
strSQL = strSQL + " AND USU_PWD='" & strPassword & "'"
Set miCon = Server.CreateObject("ADODB.Connection")
miCon.ConnectionString = "Provider=SQLOLEDB;Data Source=GuilleXP;trusted_connection=yes;Initial Catalog=GuilleSQL"
miCon.Open
Set miRS = Server.CreateObject("ADODB.Recordset")
miRS.Open strSQL, miCon
'****
'**** (c) www.guillesql.es
'**** Controlar aquí si existe el Usuario con miRS.EOF en un IF
'**** y tomar los datos del Usuario (desde miRS), si miRS.EOF es falso
'****
miRS.Close
miCon.Close
Set miRS = Nothing
Set miCon = Nothing
%>
|
Como puede observarse en el siguiente código, en principio al introducir un usuario y contraseña correctos, la consulta SQL devolverá una fila, y al introducir un usuario y contraseña incorrectos la consulta SQL no devolverá ninguna fila, luego parece ser que dicha consulta SQL devuelve una fila o ninguna en función de las credenciales especificadas, ¿verdad? PUES NO, lo hemos probado en el Laboratorio de GuilleSQL, y evidentemente NO es así. Supongamos que un usuario introduce los siguientes valores de entrada:
- txtUsuario: ' OR 'A'='A
- txtPassword: ' OR 'A'='A
Entonces, si sustituimos estos valores en la expresión que se utiliza para generar la consulta SQL que se ejecutará contra la base de datos, obtendremos la siguiente consulta:
SELECT * FROM GuilleSQL.USUARIOS
WHERE USU_ID='' OR 'A'='A'
AND USU_PWD='' OR 'A'='A'
|
Teniendo en cuenta que la expresión 'A'='A' es verdadera para todas las filas de la tabla (al ser una comparación de constantes), la anterior consulta SQL resulta equivalente a la siguiente consulta SQL:
SELECT * FROM GuilleSQL.USUARIOS
WHERE USU_ID='' OR TRUE
AND USU_PWD='' OR TRUE
|
La cual, debido al orden de evaluación de los operadores, y teniendo en cuenta que la expresión loquesea OR TRUE siempre será TRUE (es decir, será TRUE para todas las filas de la tabla), la anterior consulta SQL resulta equivalente a la siguiente consulta SQL:
SELECT * FROM GuilleSQL.USUARIOS
WHERE TRUE AND TRUE
|
Y como TRUE AND TRUE siempre será TRUE, puesto que es una expresión lógica que se cumple y evalúa como cierta para todas las filas de la tabla, habremos conseguido alterar la consulta SQL original debilitando la cláusula WHERE con la introducción de los anteriores operadores OR (disyunciones lógicas con expresiones constantes que se evalúan como ciertas). De este modo, muy probablemente podamos conseguir iniciar sesión en dicha Aplicación Web bajo la identidad del primer Usuario almacenado en la tabla de Usuarios. Lo hemos probado en el Laboratorio de GuilleSQL, y efectivamente es así. También lo hemos probado en alguna otra Web disponible en Internet, y aunque la inmensa mayoría están protegidas ante este tipo de ataques, aún queda alguna (casi imposible encontrarlas) en la que sí hemos conseguido iniciar sesión. Confío que este ejemplo de SQL Injection quede claro, pues sin duda se trata del ejemplo de SQL Injection más típico y representativo.
Sin embargo, el problema de SQL Injection no se limita a debilitar la cláusula WHERE de una consulta SQL. Continuando con el anterior ejemplo del formulario de autenticación de una Aplicación ASP, supongamos que un usuario introduce los siguientes valores de entrada:
- txtUsuario: ' OR 'A'='A
- txtPassword: ' OR 'A'='A'; DELETE GuilleSQL.USUARIOS; SELECT * FROM GuilleSQL.USUARIOS WHERE 'A'='A
Entonces, si sustituimos estos valores en la expresión que se utiliza para generar la consulta SQL que se ejecutará contra la base de datos, obtendremos la siguiente consulta:
SELECT * FROM GuilleSQL.USUARIOS
WHERE USU_ID='' OR 'A'='A'
AND USU_PWD='' OR 'A'='A';
DELETE GuilleSQL.USUARIOS;
SELECT * FROM GuilleSQL.USUARIOS
WHERE 'A'='A'
|
Como puede observarse en este caso de ejemplo, SQL Injection no sólo ha debilitado la cláusula WHERE de una consulta SQL, sino que además ha permitido introducir un código SQL malicioso (código SQL invasor) que será ejecutado en la base de datos SQL Server del ejemplo (también probado en el Laboratorio de GuilleSQL).
Pongamos un ejemplo más. Supongamos que un usuario introduce los siguientes valores de entrada:
- txtUsuario: '; DROP TABLE GuilleSQL.USUARIOS; --
- txtPassword:
Entonces, si sustituimos estos valores en la expresión que se utiliza para generar la consulta SQL que se ejecutará contra la base de datos, obtendremos la siguiente consulta:
SELECT * FROM GuilleSQL.USUARIOS
WHERE USU_ID='';
DROP TABLE GuilleSQL.USUARIOS;
--' AND USU_PWD=''
|
Como puede observarse en este caso de ejemplo, SQL Injection ha inhabilitado parte de la consulta SQL original al convertirla a un simple comentario, y además ha introducido un código SQL malicioso (código SQL invasor) que será ejecutado en la base de datos (en este caso, un DROP TABLE).
SQL Injection permitirá diferentes tipos de ataques, en caso de que la aplicación y base de datos víctimas lo permitan. Resulta vital conocer el motor de base de datos que se está atacando, lo cual permitirá aprovechar en los ataques el acceso al catátolo de la base de datos, realizar llamadas a procedimientos almacenados del sistema, etc. En consecuencia, es importante tener en cuenta que:
- Es cierto que el usuario puede no conocer la estructura de tablas y campos, pero la introducción de un código SQL invasor incorrecto y una descuidada gestión de errores de la aplicación, podría permitir al atacante visualizar total o parcialmente la consulta SQL que se está intentando ejecutar, o bien, visualizar un mensaje de error que permita identificar algunos datos del esquema de la base de datos (nombre de tablas, nombre de campos, tipos de datos, etc.), identificar qué motor de base de datos se está atacando, etc., lo que podría conseguir desvelar total o parcialmente el esquema de la base de datos que se está atacando, facilitando la labor del atacante (Hacker).
- Del mismo modo que se ha utilizado en los ejemplos sentencias DELETE y DROP TABLE como código invasor, se pueden utilizar una o varias sentencias SQL de diversos tipos con fines dispares. Por ejemplo, en el caso particular de SQL Server, se podrían introducir bucles FOR infinitos que llenasen la base de datos TEMPDB para tirar el servidor de base de datos (ataque de Denegación de Servicio), ejecutar comandos del símbolo del sistema a través de llamadas al procedimientos almacenados del sistema xp_cmdshell, acceder al Registro de Windows a través de los procedimientos almacenados del sistema existente para dicho propósito (xp_regaddmultistring, xp_regdeletekey, xp_regdeletevalue, xp_regenumkeys, xp_regenumvalues, xp_regread, xp_regremovemultistring, xp_regwrite), ejecutar objetos ActiveX (procedimientos almacenados sp_OACreate, sp_OAMethod y sp_OAGetProperty), parar o iniciar servicios de Windows a través del procedimiento almacenado del sistema xp_servicecontrol, etc.
Es importante tener en cuenta que la mayoría de los procedimientos almacenados del sistema mencionados en el párrafo anterior, así como otros muchos que también pueden ser utilizados en ataques de SQL Injection, requieren acceder a SQL Server con un Inicio de Sesión con privilegios elevados (miembro de sysadmin), premisa que puede que no se cumpla siempre (también resulta vital realizar el acceso a base de datos con un usuario con mínimos privilegios posibles).
Y hasta aquí llega la primera explicación práctica de SQL Injection con SQL Server, aunque queda mucho más, como es la utilización de Procedimientos Almacenados de SQL Server para el acceso a base de datos, ADO.Net, etc.
