Inyección de SQL
Muchos desarrolladores web no son conscientes de cómo las consultas SQL pueden ser manipuladas,
y asumen que una consulta SQL es una orden fiable. Esto significa que las consultas
SQL son capaces de eludir controles de acceso, evitando así las comprobaciones de
autenticación y autorización estándar, e incluso algunas veces, que las consultas SQL
podrían permitir el acceso a comandos al nivel del sistema operativo del equipo anfitrión.
La inyección directa de comandos SQL es una técnica donde un atacante crea o
altera comandos SQL existentes para exponer datos ocultos, sobrescribir los
valiosos, o peor aún, ejecutar comandos peligrosos a nivel de sistema en el equipo que hospeda
la base de datos. Esto se logra a través de la práctica de tomar la entrada del usuario y
combinarla con parámetros estáticos para elaborar una consulta SQL. Los siguientes ejemplos
están basados en historias reales, desafortunadamente.
Debido a la falta de validación en la entrada de datos y a la conexión a la base de datos
con privilegios de superusuario o de alguien con privilegios para crear usuarios, el atacante
podría crear un superusuario en la base de datos.
Ejemplo #1
Dividir el conjunto de resultados en páginas ... y crear superusuarios
(PostgreSQL)
<?php
$índice = $argv[0]; // ¡Cuidado, no hay validación en la entrada de datos!
$consulta = "SELECT id, name FROM products ORDER BY name LIMIT 20 OFFSET $índice;";
$resultado = pg_query($conexión, $consulta);
?>
Un usuario común hace clic en los enlaces 'siguiente' o 'atrás' donde el
$índice
está codificado en el
URL. El script espera que el
$índice
entrante sea un número décimal. Sin embargo, ¿qué pasa si alguien intenta
irrumpir anteponiendo a la
URL algo como lo siguiente empleando
urlencode()?
Si esto sucediera, el script podría otrogar un acceso de superusuario al atacante.
Observe que
0;
es para proveer un índcie válido a la
consulta original y así finalizarla.
Nota:
Es una técnica común forzar al analizador de SQL a ignorar el resto de la
consulta escrita por el desarrollador con --
, lo cual
representa un comentario en SQL.
Una forma factible de obtener contraseñas es burlar las páginas de búsqueda de resultados.
Lo único que el atacante necesita hacer es ver si hay variables que hayan sido enviadas
y sean empleadas en sentencias SQL que no sean manejadas apropiadamente. Estos filtros se pueden establecer
comunmente en un formulario anterior para personalizar las cláusulas WHERE, ORDER BY,
LIMIT
y OFFSET
en las sentencias SELECT
.
Si la base de datos admite el constructor UNION
,
el atacante podría intentar anteponer una consulta entera a la consulta original para enumerar las
contraseñas de una tabla arbitraria. Se recomienda encarecidamente utilizar campos de
contraseña encriptadas.
Ejemplo #2
Enumerar artículos ... y algunas contraseñas (cualquier servidor de bases de datos)
<?php
$consulta = "SELECT id, name, inserted, size FROM products
WHERE size = '$tamaño'";
$resultado = odbc_exec($conexión, $consulta);
?>
La parte estática de la consulta se puede combinar con otra sentencia
SELECT
la cual revelará todas las contraseñas:
Si esta consulta (jugando con
'
y
--
) fuera asignada a una de las variables utilizadas en
$consulta, despertaría a la consulta "monstruo".
Las sentecias UPDATE de SQL también son susceptibles a ataques. Estas consultas también
están amenazadas por el corte y la anteposición de una consulta completamente nueva.
El atacante podría juguetear con la cláusula SET
, aunque en este
caso, debe poseer algo de información sobre los esquemas para manipular la consulta
con éxito. Esta información puede adquirirse examinando los nombres de las variables del formulario, o
sencillamente mediante la fuerza bruta. No hay muchas convenciones de nombres para
campos que almacenen contraseñas o nombres de usuarios.
Ejemplo #3
Desde restablecer una contraseña ... hasta obtener más privilegios (cualquier servidor de bases de datos)
<?php
$consulta = "UPDATE usertable SET pwd='$pwd' WHERE uid='$uid';";
?>
Pero si un usuario malicioso podría enviar el valor
' or uid like'%admin%
a
$uid para
cambiar la contraseña del administrador, o simplemente cambiar
$pwd a
jejeje', trusted=100, admin='yes
para obtener más
privilegios, entonces, la consulta se tornaría:
Un ejemplo turbador de cómo se puede acceder a los comandos a nivel del sistema operativo
en algunos equipos anfitriones de bases de datos.
Ejemplo #4 Atacar el sistema operativo que hospeda la base de datos (Servidor MSSQL)
<?php
$consulta = "SELECT * FROM products WHERE id LIKE '%$prod%'";
$resultado = mssql_query($consulta);
?>
Si un atacante envía el valor
a%' exec master..xp_cmdshell 'net user test testpass /ADD' --
a
$prod, la
$consulta será:
El servidor MSSQL ejecuta la sentencia SQL en el lote incluyendo un comando
para añadir un usuario nuevo a la base de datos de cuentas local. Si esta aplicación
estuviera ejecutándose como
sa
y el servicio MSSQLSERVER se estuviera
ejecutando con los privilegios suficientes, el atacante ahora podría tener una cuenta
con la cual acceder a esta máquina.
Nota:
Algunos de los ejemplos citados están vinculados a un servidor de bases de datos específico.
Esto no significa que un ataque similar sea imposible en otros productos.
Su servidor de base de datos también podría ser vulnerable de otra manera.
Imagen cortesía de
» xkcd
Técnicas de evitación
Pese a que pueda parecer obvio que un atacante debe tener al menos algún
conocimiento de arquitecturas de bases de datos para poder realizar un ataque
con éxito, la obtención de esta información suele ser muy sencilla. Por ejemplo,
cuando la base de datos forma parte de un software de código abierto o disponible
públicamente con una instalación predefinida, dicha información se encuentra
completamente libre y utilizable. Esta información podría haber sido divulgada
en proyectos de código cerrado (incluso si está codificada, ofuscada o compilada),
o incluso por el propio código mediante la visualización de mensajes de error.
Otros métodos incluyen el uso de nombres frecuentes de tablas y columnas. Por ejemplo,
un formulario de inicio de sesión que utiliza una tabla 'usuarios' con los nombres
de columna 'id', 'username', y 'password'.
Estos ataques se basan principalmente en explotar el código que no ha sido escrito
teniendo en cuenta la seguridad. Nunca se ha de confiar en ningún tipo de entrada, especialmente
la que viene del lado del cliente, aún cuando esta venga de un cuadro de selección,
un campo oculto o una cookie. El primer ejemplo muestra cómo una inofensiva consulta
puede causar desastres.
-
Nunca se conecte como superusuario o como propietario de la base de datos.
Siempre utilice usuarios personalizados con privilegios muy limitados.
-
Emplee sentencias preparadas con variables vinculadas. Son proporcionadas por
PDO,
MySQLi
y otras bibliotecas.
-
Compruebe si la entrada proporcionada tiene el tipo de datos previsto. PHP tiene
un amplio rango de funciones para validar la entrada de datos, desde las más simples,
encontradas en Funciones de variables y en
Funciones del tipo carácter
(p.ej., is_numeric(), ctype_digit()
respectivamente), hasta el soporte para
Expresiones regulares compatibles con Perl.
-
Si la expresión espera una entrada numérica, considere verificar los datos
con la función ctype_digit(), o silenciosamente cambie su tipo
utilizando settype(), o emplee su representación numérica
por medio de sprintf().
Ejemplo #5 Una forma más segura de componer una consulta para paginación
<?php
settype($índice, 'integer');
$consulta = "SELECT id, name FROM products ORDER BY name LIMIT 20 OFFSET $índice;";
// Observe %d en el string de formato; el uso de %s podría no tener un resultado significativo
$consulta = sprintf("SELECT id, name FROM products ORDER BY name LIMIT 20 OFFSET %d;",
$índice);
?>
-
Si la capa de la base de datos no admite variables vinculadas,
entrecomille cada valor no numérico proporcionado por el usuario que sea pasado a la
base de datos con la función de escapado de cadenas específica de la base de datos (p.ej.
mysql_real_escape_string(),
sqlite_escape_string(), etc.).
Las funciones genéricas como addslashes() son útiles solamente
en un entorno muy específico (p.ej., MySQL en un juego de caracteres monobyte
con NO_BACKSLASH_ESCAPES deshabilitada), por lo que es
mejor evitarlas.
-
Sea como sea, no muestre ninguna información específica de la base de datos,
especialmente sobre el esquema. Vea también Notificación de errores y Manejo de errores y funciones de registro.
-
Su pueden utilizar procedimientos almacenados y cursores previamente definidos para abstraer
el acceso a datos para que los usuarios no tengan acceso directo a las tablas o vistas, aunque
que esta solución tiene otros impactos.
Además, se puede beneficiar del registro de consultas, ya sea dentro de un script
o mediante la base de datos en sí misma, si es que lo soporta. Obviamente, llevar un registro no
previene los intentos dañinos, aunque puede ser útil para realizar un seguimiento de las
aplicación que han sido eludidas. El registro no es útil por sí mismo, sino
por la información que contiene. Normalmente cuantos más detalles, mejor.