ATAQUES POR INYECCION DE CODIGO SQL

SQL es un lenguaje textual utilizado para interactuar con bases de datos relacionales. La unidad
tpica de ejecucin de SQL es la consulta "query", conjunto de instrucciones que permiten modificar
la estructura de la base de datos (mediante instrucciones del tipo Data Definition Language) o
manipular el contenido de la base de datos (mediante instrucciones del tipo Data Manipulation
Language). En los servidores Web se utiliza este lenguaje para acceder a bases de datos y ofrecer
pginas dinmicas o nuevas funcionalidades a los sistemas.
Se conoce como Inyeccin SQL, indistintamente, al tipo de vulnerabilidad, al mtodo de infiltracin,
al hecho de incrustar cdigo SQL intruso y a la porcin de cdigo incrustado.
El ataque por inyeccin de cdigo SQL se produce cuando no se filtra de forma adecuada la
informacin enviada por el usuario. Un usuario malicioso podra incluir y ejecutar textos que
representen nuevas sentencias SQL que el servidor no debera aceptar. Este tipo de ataque es
independiente del sistema de bases de datos subyacente, ya que depende nicamente de una
inadecuada validacin de los datos de entrada.
Como consecuencia de estos ataques y dependiendo de los privilegios del usuario de base de
datos bajo el cual se ejecutan las consultas, se podra acceder no solo a las tablas relacionadas
con la operacin de la aplicacin del servidor Web, sino tambin a las tablas de otras bases de
datos alojadas en el mismo servidor Web.
Tambin pueden propiciar la ejecucin de comandos arbitrarios del sistema operativo del equipo
del servidor Web.

Ejemplos
As, como ejemplos de ataques de inyeccin de cdigo SQL podramos considerar las siguientes:
Ejemplo 1:
Si en el servidor se va a ejecutar una sentencia SQL del tipo:
UPDATE tabla set PASSWORD='$INPUT[password]' WHERE user='$INPUT[user_id]';
pensada en principio para actualizar la contrasea de un determinado usuario registrado en el
sistema, se podra llevar a cabo un ataque por inyeccin de cdigo SQL con una direccin URL
preparada de forma maliciosa tal y como sigue:
http://www.servidor.com/script?pwd=clave%uid=1'+or+uid+like'%"admin%';
la cual tendra como consecuencia que el atacante conseguira acceder a la base de datos con el
perfil de administrador.
Ejemplo 2:
Si en el servidor se va a ejecutar una sentencia SQL del tipo:
SELECT nombre FROM productos WHERE id LIKE '%$INPUT[cod_prod]%';
pensada para devolver el nombre de un producto a partir de su cdigo identificador, se podra
producir un ataque por inyeccin de cdigo SQL con una direccin URL preparada as:
http://www.servidor.com/script?' EXEC+ master..xp_cmdshell(cmd.exe+/c)"

la cual tendra como consecuencia que el atacante podra ejecutar una aplicacin del sistema
operativo
del
equipo,
en
este
caso
el
propio
interprete
de
comandos
Ejemplo 3:
Si en el servidor se va a ejecutar una sentencia SQL del tipo:
SELECT * FROM usuarios WHERE username = " + username + "AND password=" +
password +";
se podra producir un ataque si el usuario especifica lo siguiente:
username: ; drop table users ;
password:
ya que entonces la tabla 'usuarios' seria borrada de la base de datos, denegando el acceso a todos
los dems usuarios (ataque de denegacin de servicio).
Ejemplo 4:
Por ejemplo, asumiendo que el siguiente cdigo reside en una aplicacin web y que existe un
parmetro "nombreUsuario" que contiene el nombre de usuario a consultar, una inyeccin SQL se
podra provocar de la siguiente forma:
El cdigo SQL original y vulnerable es:
consulta := "SELECT * FROM usuarios WHERE nombre = '" + nombreUsuario +
"';"
Si el operador escribe un nombre, por ejemplo "Alicia", nada anormal suceder, la aplicacin
generara una sentencia SQL similar a la siguiente, que es perfectamente correcta, en donde se
seleccionaran todos los registros con el nombre "Alicia" en la base de datos:
SELECT * FROM usuarios WHERE nombre = 'Alicia';
Pero si un operador malintencionado escribe como nombre de usuario a consultar:
Alicia'; DROP TABLE usuarios; SELECT * FROM datos WHERE nombre LIKE
'%
se generara la siguiente consulta SQL, (el color verde es lo que pretende el programador, el azul
es el dato, y el rojo, el cdigo SQL inyectado):
SELECT * FROM usuarios WHERE nombre = 'Alicia';
DROP TABLE usuarios;
SELECT * FROM datos WHERE nombre LIKE '%';

En la base de datos se ejecutara la consulta en el orden dado, se seleccionaran todos los

registros con el nombre 'Alicia', se borrara la tabla 'usuarios' y finalmente se seleccionara toda la
tabla "datos", que no debera estar disponible para los usuarios web comunes.
En resumen, cualquier dato de la base de datos puede quedar disponible para ser ledo o
modificado por un usuario malintencionado.

Ntese por qu se llama "Inyeccin" SQL. Si se observa el cdigo malicioso, de color rojo, se
notar que est insertado en el medio del cdigo bueno, el verde. As, el cdigo rojo ha sido
"inyectado" dentro del verde.
Ejemplo 5:
Si se tiene la siguiente pagina web

Simula una aplicacin que requiere identificacin de usuario y password. Si se intenta entrar un
usuario y password al azar la aplicacin dir Acceso denegado El login y password correcto son:
admin y admin1234. Se puede comprobar introducindolo.

Ahora se va a conseguir acceso PERMITIDO usando inyeccin SQL, sin conocer ni el Login ni el
Password.

Por qu permite la entrada?

Otras variantes a usar en el campo login podran ser:

Y variantes de consultas:

Ejemplos de ataques:
-Obtencin de la base de datos completa usando sentencias SELECT
-Modificacin o insercin de datos usando INSERT o UPDATE
-Borrado de la base de datos usando DELETE
-Ejecucin de comandos del sistema operativo usando EXEC master.dbo.xp_cmdshell por
ejemplo, el valor de pass sera pass=hack' EXEC master.dbo.xp_cmdshell'cmd.exe dir c:'--Apagado remoto del servidor pass=hack' EXEC master.dbo.xp_cmdshell'cmd.exe shutdown'--

Qu Bases de datos son susceptible a Inyeccin SQL?

La ms susceptible a ataques en MS SQL, dado que permite explotar el fallo ms fcilmente y
adems posee opciones que facilitan el acceso al sistema, como la ejecucin de comandos. En la
lista siguiente se detalla una relacin de posibilidades de explotacin de cada base de datos.
MySQL
Se ejecuta con privilegios de 'root' por defecto
Volcado a ficheros con INTO OUTFILE
La ejecucin de sentencias mltiples es POCO PROBABLE, pocos mdulos lo permiten
Oracle
La ejecucin de sentencias mltiples NO est permitida
Anidamiento de consultas SELECT Uso de UNION posible
Uso de procedimientos invocables desde la inyeccin
DB2 Igual que Oracle
Postgres
La ejecucin de sentencias mltiples SI est permitida
Anidamiento de consultas SELECT Uso de UNION posible
Uso de procedimientos invocables desde la inyeccin Uso de COPY posible como
superusuario

MS SQL
La ejecucin de sentencias mltiples SI est permitida
Anidamiento de consultas SELECT Uso de UNION posible
Uso de procedimientos invocables desde la inyeccin (mencion especial de 'xp_cmdshell' )

SEGURIDAD CONTRA SQL INJECTION

QUE HACER CONTRA ESTA VULNERABILIDAD?
Es muy difcil desarrollar una aplicacin segura a la primera. Ni siquiera las grandes aplicaciones
escritas por programadores expertos estn libres de fallos. La falta de tiempo y el nmero de
programadores implicados en la aplicacin son factores habituales que juegan en contra de la
seguridad. Por este motivo son necesarias las auditoras de cdigo, para localizar vulnerabilidades
en el cdigo.
En general, la auditora de cdigo se considera la tarea ms difcil y compleja a la que puede
enfrentarse un programador. Actualmente existen empresas de seguridad informtica que ofrecen
servicios de auditora de cdigo a precios extremadamente altos, dependiendo de la aplicacin. Sin
embargo, en lo que respecta a la inyeccin SQL, la labor es mucho ms fcil que con otros tipos de
vulnerabilidades.
La auditora puede realizarse manualmente o mediante herramientas existentes para tales fines.
Auditora de cdigo mediante herramientas
- Ofrecen resultados satisfactorios en la deteccin de vulnerabilidades fciles de identificar, y
cuando nos enfrentamos a una inmensa cantidad de cdigo, usar estas herramientas nos
ahorrarn mucho tiempo.
- Sin embargo hay muchos errores de lgica que estas herramientas son incapaces de hallar
- Herramientas de auditora de inyeccin SQL tenemos Acunetix Web Vulnerability Scanner y
Netcraft, ambas de pago pero con versin de demostracin de 30 das
1. Magic_quotes
Es una variable que se encuentra en el fichero .ini de configuracin de PHP. Cuando su valor es
On, todas las entradas por parmetros sufrirn la adicin de la barra invertida delante de la comilla
simple.
Es lo mismo que realiza la funcin addslashes.
Si entra user=pe'dro se convertir en pe\'dro , de forma que el interprete SQL no tomar la comilla
como parte sintctica, sino como dato carcter.
La funcin inversa es stripslashes.
Estas prcticas son una medida de seguridad habitualmente recomendada por autores de cdigo.

Sin embargo, NO ACONSEJA DEL TODO SU USO, pues a menudo lleva a errores una mala
gestin de las barras.
En su lugar se propone usar la siguiente funcin.

2. Mysql_real_scape_string( $cadena)
Evita todos los caracteres especiales de la $cadena argumento, teniendo en cuenta el juego de
caracteres usado en la conexin, de forma que sea segura usarla con Mysql_query.
Coloca barras en los siguientes 7 caracteres:\x00 \n \r \ ' \x1a que se consideran peligrosos pues
pueden ser usados para varios tipos de ataques.
La funcin retorna la cadena con barras, pero la variable original $cadena entrada no se modifica.
Algo parecido a esta funcin se puede realizar colocando comillas dobles de la
forma $sql=SELECT * FROM tabla WHERE usuario =' $_POST[usuario ] ' ;

3. Delimitar siempre los valores en las consultas.

Aunque el valor de la consulta sea un entero, delimitarlo siempre entre comillas simples. Una
sentencia del estilo

SELECT user FROM table WHERE iduser= $id

es mucho ms fcilmente
inyectable que
SELECT user FROM table WHERE iduser= ' $id '

4. Verificar siempre los datos que introduce el usuario

Si se espera recibir un entero, no confiar en que lo sea, es mejor verificar con is_int(). Igualmente
si es un long con is_long(), o un char, un varchar, o cualquier tipo con gettype(). Si se prefiere
tambin se puede convertir al tipo de dato que se espera con intval() settype().
Comprobar tambin la longitud de las cadenas con strlen() o su formato con strpos(). Con esto se
evitar posibles tcnicas avanzadas de inyeccin SQL.

5. Crear libreras propias

Es muy pesado programar vigilando y revisando constantemente cada variable, cada tipo, cada
caracter. Es mejor crear libreras propias, una clases que acten como capa de abstraccin de

todas estas ideas necesarias a tener en cuenta constantemente. Se programar ms rpido, se

evitarn descuidos, y simplemente se usa la seguridad que ya se program.
6. PEAR Package DB - Paquete Bases de Datos PEAR
El paquete DB del grupo PEAR va ms all de la seguridad. Es una capa de abstraccin para
bases de datos. El inconveniente es que se depende siempre de sus paquetes. Pero la ventaja es
la despreocupacin.
7. Filtrando los datos enviados por el usuario antes de que estos sean procesados por el servidor,
para evitar que se puedan incluir y ejecutar textos que representen nuevas sentencias SQL.
8. As mismo, es conveniente no utilizar las consultas SQL basadas directamente en cadenas de
texto enviadas desde el navegador del usuario, sino que se deberan construir todas las consultas
en el servidor con sentencias preparadas y/o procedimientos almacenados parametrizados, que
encapsulen los parmetros que deberan evitar los caracteres especiales que hubieran podido ser
introducidos
dentro
de
ellos
por
un
usuario
malicioso.
Es, de hecho, un error de una clase ms general de vulnerabilidades que puede ocurrir en
cualquier lenguaje
de
programacin o script que
est
embebido
dentro
de
otro.
9. Valide siempre los datos especificados por el usuario mediante comprobaciones de tipo,
longitud, formato e intervalo. A la hora de implementar medidas de precaucin frente a la
especificacin de datos dainos, tenga en cuenta la arquitectura y los escenarios de
implementacin de la aplicacin. Recuerde que los programas diseados para ejecutarse en un
entorno seguro pueden copiarse en un entorno no seguro. Las sugerencias que se muestran a
continuacin deben considerarse prcticas recomendadas:

No haga suposiciones sobre el tamao, tipo o contenido de los datos que recibir la
aplicacin. Por ejemplo, debe hacer la siguiente evaluacin:

Cmo se comportar la aplicacin si un usuario (malicioso o no) especifica un

archivo MPEG de 10 megabytes cuando la aplicacin espera un cdigo postal.

Cmo se comportar la aplicacin si se incrusta una instruccin DROP TABLE en

un campo de texto.

Compruebe el tamao y el tipo de los datos especificados y aplique unos lmites

adecuados. Esto puede impedir que se produzcan saturaciones deliberadas del bfer.

Compruebe el contenido de las variables de cadena y acepte nicamente valores

esperados. Rechace las especificaciones que contengan datos binarios, secuencias de
escape y caracteres de comentario. Esto puede impedir la inyeccin de scripts y puede
servir de proteccin frente a explotaciones de saturacin del bfer.

Cuando trabaje con documentos XML, valide todos los datos con respecto a su esquema a
medida que se vayan indicando.

No cree nunca instrucciones Transact-SQL directamente a partir de datos indicados por el

usuario.

Utilice procedimientos almacenados para validar los datos indicados por el usuario.

En entornos de varios niveles, todos los datos deben validarse antes de que se admitan en
la zona de confianza. Los datos que no superen el proceso de validacin deben
rechazarse, y debe devolverse un error al nivel anterior.

Implemente varias capas de validacin. Las precauciones que tome contra usuarios
malintencionados ocasionales pueden resultar ineficaces contra piratas informticos con
determinacin. Lo ms recomendable es validar los datos especificados por el usuario en
la interfaz de usuario y, despus, en todos los puntos posteriores en que atraviesen un
lmite de confianza.

Por ejemplo, la validacin de datos en una aplicacin de cliente puede evitar la inyeccin de
scripts. Sin embargo, si en el siguiente nivel se asume que ya se ha validado la entrada, cualquier
usuario malintencionado que sea capaz de eludir un cliente puede disfrutar de un acceso sin
restricciones a un sistema.

No concatene nunca datos especificados por el usuario que no se hayan validado. La

concatenacin de cadenas es el punto de entrada principal de una inyeccin de scripts.

No acepte las siguientes cadenas en campos a partir de los que puedan construirse
nombres de archivo: AUX, CLOCK$, COM1 a COM8, CON, CONFIG$, LPT1 a LPT8, NUL
y PRN.

Si es posible, rechace los datos que contengan los siguientes caracteres:

HERRAMIENTAS

http://www.taringa.net/posts/linux/15058932/Miedo-a-una-injeccion-SQL_-_-8Tool_s-para-enfrentarlas.html

SQLiHelper 2.7: SQL Injection

http://www.hacktimes.com/sqlihelper_2_7_sql_injection/
Se trata de una aplicacin cuyo objetivo es facilitar la extraccin de informacin procedente
de bases de datos, utilizando tcnicas de inyeccin de SQL.
La ltima versin, 2.7, cuenta con soporte para motores de bases de datos SQL Server,
Mysql y access. Aunque no se trata de una herramienta tan slida y potente como, por
ejemplo, Pangolin, s que tiene multitud de ventajas sobre todo para bases de datos
MySQL

Pangoln: Automatizacin de inyeccin SQL

http://www.hacktimes.com/pangolin_automatizaci_n_de_inyecci_n_sql/
Pangoln es una herramienta grfica para plataformas win32 programada en C++ destinada
a explotar vulnerabilidades del tipo inyeccin SQL e inyeccin SQL ciega (Blind SQL) muy
fcil de usar y muy rpida.
En aquellos motores donde la vulnerabilidad lo permita, la herramienta implementa
explotacin para conseguir informacin y datos del servidor, ejecucin de shell, acceso al
registro, escritura o descarga de ficheros del servidor, navegador de archivos, etc. Las
consultas y peticiones a la base de datos pueden efectuarse via Proxy y utilizar mtodos de
evasin contra firewalls e IDS.

SQLMap

http://sqlmap.org/
SQLMap es una herramienta para pruebas de acceso, de cdigo abierto que automatiza el
proceso de deteccin y explotacin de vulnerabilidades SQL, y control de los servidores de
bases de datos. Posee un poderoso motor de deteccin, caractersticas para pruebas de
acceso y un amplio rango de interruptores de duracin que van desde bases de datos con
toma de huellas dactilares, sobre captacin de datos, hasta el acceso a archivos del
sistema subyacentes y la ejecucin de comandos en el sistema operativo va conexiones
fuera de banda.

Enema: SQL Injection and Web Attack Framework

http://code.google.com/p/enema/

Enema no es un software de auto-hackeo. Es una herramienta dinmica para testers de

intrusin profesionales. Versin estable actual: 1.7

MultiInjector Herramienta Automtica de Inyeccin SQL

http://www.dragonjar.org/multiinjector-herramienta-automatica-deinyeccion-sql.xhtml
MultiInjector es una herramienta para realizar automticamente SqlInjection en un sitio
especificado, al ingresarle una url o una serie de estas, automticamente comprobara si
es/son vulnerable/s.

Videos de Inters
http://www.youtube.com/watch?v=PB7hWlqTSqs&feature=related
http://www.youtube.com/watch?v=-uqotuscuQE&feature=related