Inyeccion SQL

Inyección de SQL

Muchos desarrolladores web son desprevenidos de cómo las consultas SQL pueden ser manipuladas, y asumen que una consulta SQL es un comando confiable. Esto significa que las consultas SQL están expuestas a que sean malversadas en controles de acceso, sobrepasando así las revisiones de autenticación y autorización estándar, y que algunas veces las consultas SQL aún podrían permitir el acceso de comandos a nivel de sistema operativo del ordenador.

Comandos directos de Inyección SQL es una técnica donde un atacante crea o altera comandos SQL existentes para exponer datos ocultos, sobreponerse a los que son importantes, o peor aún, ejecutar comandos peligrosos a nivel de sistema en el equipo donde se encuentra la base de datos. Esto se logra a través de la aplicación, tomando la entrada del usuario y combinándola 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 conectándose a la base de datos con privilegios de super usuario o de alguien con privilegios que puede crear usuarios, el atacante podría crear un super usuario en su base de datos.

Ejemplo #1 Dividiendo el conjunto de resultados en páginas ... y haciendo super usuarios (PostgreSQL)

<?php

$offset = $argv[0]; // Cuidado, no hay validación en la entrada de datos!

$query = "SELECT id, name FROM products ORDER BY name LIMIT 20 OFFSET $offset;";

$result = pg_query($conn, $query);

?>

Los usuarios normales dan clic en los enlaces 'siguiente' o 'atras' donde $offset está codificado en la URL. El script espera que el $offset entrante sea un número décimal. Sin embargo, qué pasa si alguien intenta irrumpir añadiendo una función urlencode() al formulario de la siguiente URL

0;

insert into pg_shadow(usename,usesysid,usesuper,usecatupd,passwd)

select 'crack', usesysid, 't','t','crack'

from pg_shadow where usename='postgres';

--

Si esto sucedió, entonces el script podría presentarle un acceso de super usuario al atacante. Nótese que 0; es para proveer un offset válido a la consulta original y para finalizarla.

Nota:

Esta es una técnica común para forzar al analizador SQL a que ignore el resto de la consulta escrita por el desarrollador con dos guiónes: -- los cuales representan 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 usadas en declaraciones SQL las cuales no sean manejadas apropiadamente. Esos filtros pueden ser puestos comunmente en un formulario anterior para personalizar las cláusulas WHERE, ORDER BY, LIMIT y OFFSET en las declaraciones SELECT. Si su base de datos soporta el constructor UNION, el atacante podría intentar añadir una consulta entera a la consulta original para listar contraseñas de una tabla arbitraria. Utilizar campos de contraseña encriptadoslds es fuertemente recomendado.

Ejemplo #2 Listando nuestros artículos ... y algunas contraseñas (de cualquier servidor de base de datos)

<?php

$query = "SELECT id, name, inserted, size FROM products

WHERE size = '$size'";

$result = odbc_exec($conn, $query);

?>

La parte estática de la consulta puede ser combinada con otra declaración SELECT la cual revela todas las contraseñas:

'

union select '1', concat(uname||'-'||passwd) as name, '1971-01-01', '0' from usertable;

--

Si esta consulta (ejecutándose con ' y --) fuera asignada a una de las variables utilizadas en $query, la consulta reaccionará bestialmente.

Las consultas de actualización de SQL, también son susceptibles a ataques. Estas consultas también son amenazadas por acortamiento y adición en una consulta completamente nueva a esta. Sin embargo el atacante podría manipularla con la cláusula SET. En este caso, algunos esquemas de información deben ser procesados para manipular la consulta exitosamente. Este puede adquirirse examinando la forma de nombres de las variables, o simplemente forzarlo con un ataque de fuerza bruta. No hay muchas convenciones de nombres para campos que almacenan contraseñas o nombres de usuarios.

Ejemplo #3 Desde re-establecer una contraseña ... hasta ganar más privilegios (en cualquier servidor de bases de datos)

<?php

$query = "UPDATE usertable SET pwd='$pwd' WHERE uid='$uid';";

?>

Pero 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 hehehe', trusted=100, admin='yes para obtener más privilegios. Entonces, la consulta sería cambiada:

<?php

// $uid: ' or uid like '%admin%

$query = "UPDATE usertable SET pwd='...' WHERE uid='' or uid like '%admin%';";

// $pwd: hehehe', trusted=100, admin='yes

$query = "UPDATE usertable SET pwd='hehehe', trusted=100, admin='yes' WHERE

...;";

?>

...