Inyección de comandos SQL
Electiva II: Seguridad Informática
20 de octubre de 2021
INYECCIÓN DE COMANDOS
• ENDURECIMIENTO DE CÓDIGO: proceso de reducir las oportunidades
de los ataques mediante la identificación y eliminación de las
vulnerabilidades de los sistemas de software.
Etapas de este proceso:
• Saber dónde examinar
• Conocer lo que se está buscando
• Saber cómo mitigar la amenaza
• LÍNEA DE COMANDOS: es una interfaz de usuario donde este puede
escribir comandos a un intérprete, y estos comandos son ejecutados
en nombre del usuario.
INYECCIÓN DE COMANDOS (cont.)
• Las vulnerabilidades de inyección de comandos, conocidas también
como ejecución remota de comandos, surgen cuando un usuario es
capaz de enviar comandos a un intérprete cuando ese acceso está en
contra de una política del sistema.
• Se supone que los intérpretes de comandos no deben ser accedidos
directamente por los usuarios.
• Cuando existe una falla (bug) que permite a los usuarios tener acceso
directo a intérpretes de comandos, entonces existe el potencial para
que el usuario tenga acceso a recursos protegidos.
INYECCIÓN DE COMANDOS: ejemplo
Ejemplo: código en Perl.
my $fileName = <STDIN>
system(“cat /home/username/”, $fileName)
Suponiendo que es un usuario NO malintencionado, digitará:
notas.txt
Con esa información, el script de Perl creará un string que será ejecutado por el sistema:
cat /home/username/notas.txt
Por otra parte, un usuario con “otras” intenciones, podría digitar:
notas.txt; rm –rf *.*
En ese caso, lo que se va a ejecutar es:
cat /home/username/notas.txt; rm –rf *.*
INYECCIÓN DE COMANDOS:
MITIGACIÓN
COMPLETA (complete): remueve cualquier posibilidad de inyección de comandos.
FUERTE (strong): se utiliza cuando la opción completa es inviable.
En el caso del script en Perl, en lugar de permitir al usuario que ingrese cualquier texto en
$fileName, se recomienda restringir la entrada solamente a los archivos presentes en el
directorio (white list).
DÉBIL (weak): es el último recurso.
En el caso del script de Perl, se puede implementar buscando elementos peligrosos en la
entrada del usuario (black list).
¿Cuál es la dificultad? Que la lista incluya TODAS las opciones peligrosas.
INYECCIÓN DE COMANDOS SQL
(SQL Injection)
• SQL: Structured Query Language es una interfaz de comandos
desarrollada por IBM a comienzos de la década de 1970.
Operaciones que se hacen comunmente en una BD:
• Buscar un registro (usernamepassword)
• Traer datos (generar una lista de productos en una categoría dada)
• Adicionar datos (actualizar el precio de un ítem del inventario)
• SQL tiene el poder de permitir al usuario que interactúe con la BD de
muchas más maneras de lo que permitirían las políticas, por lo tanto,
queda en manos del desarrollador la conversión de las entradas en
un query seguro y válido.
INYECCIÓN DE COMANDOS SQL:
ejemplo
Una aplicación web simple que le pregunta al usuario por un término
de búsqueda y lo almacena en la variable searchQuery
SELECT * FROM world WHERE name LIKE ‘%searchQuery%’;
Supongamos que se inserta el término co en %searchQuery%, se
generará la siguiente sentencia SQL:
SELECT * FROM world WHERE name LIKE ‘%co%';
https://sqlzoo.net/wiki/UNION
INYECCIÓN DE COMANDOS SQL:
ejemplo (cont.)
Un usuario malintencionado intentará ejecutar una sentencia diferente.
En lugar de escribir co, digitará lo siguiente:
x’; UPDATE world SET name = ‘You have been hacked!!’
Con este string, el comando enviado al intérprete SQL será:
SELECT * FROM world WHERE name LIKE ‘%x’; UPDATE world
SET name = ‘You have been hacked!!’
Para que el ataque sea exitoso, el hacker debe conocer el formato
básico del query, así como tener una idea de cómo está organizada la
tabla.
TIPOS DE ATAQUES SQL Injection
1. UNION queries
2. Tautologías
3. Comentarios
4. Sentencias adicionales
ATAQUES MEDIANTE QUERIES
UNION
SENTENCIA UNION
SELECT * FROM world WHERE name LIKE 'br%' UNION SELECT * FROM
world WHERE name LIKE 'CO%'
• Vulnerabilidad: en el sistema deben estar presentes:
1. Intérprete de SQL
2. La entrada del usuario debe usarse para construir la sentencia SQL
3. Debe ser posible para el usuario insertar una cláusula UNION al final de una
sentencia SQL
4. El sistema debe pasar la sentencia al intérprete
ATAQUES MEDIANTE QUERIES
UNION (cont.)
Fuente:
https://aprendizdesysadmin.com/parametrizacion-de-las-consul
tas/#post-2566-_Toc500752512
ATAQUES MEDIANTE QUERIES
• Ejemplo:
UNION (cont.)
SELECT authenticate FROM passwordList WHERE
name=‘$username’ and passwd=’$password’
¿Cuál es la parte vulnerable de esta sentencia?
Es la variable $password, que se puede acceder desde la entrada del
usuario y es donde se puede inyectar el código
En un query de un usuario corriente, cuyo username es Carlos y su
contraseña es T0P_S3CR3T, el query sería:
SELECT authenticate FROM passwordList WHERE name=‘Carlos’
and passwd=’T0P_S3CR3T’
ATAQUES MEDIANTE QUERIES
UNION (cont.)
• Explotación:
El string $password recibe la siguiente entrada:
nothing’ UNION SELECT * FROM passwordList
• Query resultante:
SELECT authenticate FROM passwordList WHERE name=‘root’ and
passwd=’nothing’ UNION SELECT * FROM passwordList
ATAQUES MEDIANTE QUERIES
• Mitigación
UNION (cont.)
- Remover el intérprete de SQL
- Validar las entradas para remover las sentencias UNION
ATAQUES DE TAUTOLOGÍA
TAUTOLOGÍA
Expresión lógica que al evaluarse con cualquier valor de entrada SIEMPRE resulta
VERDADERA
• Vulnerabilidad: en el sistema deben estar presentes:
1. Intérprete de SQL
2. La entrada del usuario debe usarse para construir la sentencia SQL
3. Debe haber una expresión booleana involucrada en una decisión de seguridad
4. La expresión debe contener un OR o debe ser posible para el usuario insertar un OR en
la expresión
5. Debe ser posible para el usuario hacer que la expresión OR siempre resulte verdadera
6. El sistema debe pasar la sentencia al intérprete
ATAQUES DE TAUTOLOGÍA (cont.)
• Ejemplo:
SELECT authenticate FROM passwordList WHERE
name=‘$username’ and passwd=’$password’
¿Cuál es la parte vulnerable de esta sentencia?
Es la variable $password, que se puede acceder desde la entrada del
usuario y es donde se puede inyectar el código
En un query de un usuario corriente, cuyo username es Carlos y su
contraseña es T0P_S3CR3T, el query sería:
SELECT authenticate FROM passwordList WHERE name=‘Carlos’
and passwd=’T0P_S3CR3T’
ATAQUES DE TAUTOLOGÍA (cont.)
• Explotación:
El string $password recibe la siguiente entrada:
nothing’ OR 1=1
• Query resultante:
SELECT authenticate FROM passwordList WHERE name=‘root’ and
passwd=’nothing’ OR 1=1
Obsérvese que la expresión booleana siempre es verdadera
Ejemplo 2:
SELECT * FROM world WHERE name='brazil' and area='nothing' OR 1=1
https://sqlzoo.net/wiki/UNION
ATAQUES DE TAUTOLOGÍA (cont.)
Fuente:
https://aprendizdesysadmin.com/parametrizacion-de-las-consul
tas/#post-2566-_Toc500752512
ATAQUES DE TAUTOLOGÍA (cont.)
• Mitigación
- Remover el intérprete de SQL
- Validar la entrada para remover las comillas sencillas o la palabra OR
ATAQUES DE COMENTARIOS
COMENTARIOS
Los comentarios permiten al programador especificar un texto que será
ignorado por el intérprete. Si un usuario externo puede insertar un
comentario en una parte de una sentencia SQL, entonces el resto del query
será ignorado por el intérprete.
• Vulnerabilidad: en el sistema deben estar presentes:
1. Intérprete de SQL
2. La entrada del usuario debe usarse para construir la sentencia SQL
3. Debe ser posible para el usuario insertar un comentario al final de una sentencia
SQL
4. El sistema debe pasar la sentencia al intérprete
ATAQUES DE COMENTARIOS (cont.)
• Ejemplo:
SELECT authenticate FROM passwordList WHERE
name=‘$username’ and passwd=’$password’
¿Cuál es la parte vulnerable de esta sentencia?
Es la variable $username, que se puede acceder desde la entrada del
usuario y es donde se puede inyectar el código
En un query de un usuario corriente, cuyo username es Carlos y su
contraseña es T0P_S3CR3T, el query sería:
SELECT authenticate FROM passwordList WHERE name=‘Carlos’
and passwd=’T0P_S3CR3T’
ATAQUES DE COMENTARIOS (cont.)
• Explotación:
El string $username recibe la siguiente entrada:
root’;#
root’;--
• Query resultante:
SELECT authenticate FROM passwordList WHERE name=‘root’; # and passwd=’nothing’
El atacante simplifica el query.
Ejemplo 2:
SELECT * FROM world WHERE name='brazil’;--and area='nothing’
https://sqlzoo.net/wiki/UNION
ATAQUES DE COMENTARIOS (cont.)
• Mitigación
- Remover el intérprete de SQL
- Validar la entrada para remover los caracteres que denotan
comentarios (# o --)
ATAQUES DE SENTENCIAS
ADICIONALES
SENTENCIAS ADICIONALES
Adicionar una sentencia a un query de SQL es tan fácil como colocar un ; a la
entrada. Como ocurre en C++ y en muchos otros lenguajes, un punto y coma
indica el fin de una sentencia y el comienzo de la siguiente. Mediante la
adición de un punto y coma, sentencias adicionales se pueden concatenar a
un flujo de comandos SQL.
• Vulnerabilidad: en el sistema deben estar presentes:
1. Intérprete de SQL
2. La entrada del usuario debe usarse para construir la sentencia SQL
3. La entrada del usuario no valida la presencia de ;
4. El sistema debe pasar la sentencia al intérprete
ATAQUES DE SENTENCIAS
• Ejemplo:
ADICIONALES (cont.)
SELECT authenticate FROM passwordList WHERE
name=‘$username’ and passwd=’$password’
¿Cuál es la parte vulnerable de esta sentencia?
Es la variable $password,que se puede acceder desde la entrada del
usuario y es donde se puede inyectar el código
En un query de un usuario corriente, cuyo username es Carlos y su
contraseña es T0P_S3CR3T, el query sería:
SELECT authenticate FROM passwordList WHERE name=‘Carlos’
and passwd=’T0P_S3CR3T’
ATAQUES DE SENTENCIAS
ADICIONALES (cont.)
• Explotación:
El string $password recibe la siguiente entrada:
nothing’; INSERT INTO passwordList (name, passwd) VALUES
‘Bob’,’1234’
• Query resultante:
SELECT authenticate FROM passwordList WHERE name=‘root’ and
passwd=’nothing’; INSERT INTO passwordList (name, passwd)
VALUES ‘Bob’,’1234’
ATAQUES DE SENTENCIAS
• Mitigación
ADICIONALES (cont.)
- Remover el intérprete de SQL
- Validar la entrada para remover el carácter ;
Las sentencias adicionales son una de las más severas vulnerabilidades
de inyección de código SQL. Con esto, el atacante puede obtener
información confidencial contenida en la BD, puede alterar y remover
información, entre otros.
OTRAS OPCIONES PARA MITIGAR
ATAQUES DE SQL Injection
• Parametrización
Uso de sentencias preparadas (prepared statements)
El uso de parámetros bind permite al programador especificar a la base
de datos lo que debe ser tratado estrictamente como parámetro y lo
que debe ser tratado como comando.
(Fuente: https://aprendizdesysadmin.com/parametrizacion-de-las-consultas/#post-2566-_Toc500752512)
Fuente:
https://www.w3schools.com/php/php_mysql_prepared_statements.asp
OTRAS OPCIONES PARA MITIGAR
ATAQUES DE SQL Injection (cont.)
• Asignar mínimos privilegios al usuario que conectará con la BD
Nunca debe ser root
• Verificar el tipo de dato que ingresó el usuario
Si el query se va a realizar sobre columnas con datos de tipo numérico,
entonces se puede verificar que la entrada sea de ese tipo (is_numeric en
PHP)
• Utilizar funciones que permitan “escapar” los caracteres peligrosos
Los caracteres que implican un riesgo de inyección de código SQL, como
comilla sencilla, se pueden “escapar”, evitando que sean interpretados
como comandos. Por ejemplo, en PHP, esta acción se lleva a cabo mediante
la función mysql_real_escape_string.
Referencias
Heilfrich, James. “Security for sofware engineers”. CRC Press.
L. K. Shar and H. B. K. Tan, "Defeating SQL Injection," in Computer, vol. 46, no. 3, pp. 69-77,
March 2013. doi: 10.1109/MC.2012.283
URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6265060&isnumber=6489937
