¿Otro post de SQL injection? Sí, otro post de SQLi, el motivo es que no aprendemos y siguen apareciendo vulnerabilidades de este tipo, la última que me encontré fue bastante grave, de ahí que vuelva a poner sobre la mesa esta vulnerabilidad, tanto los hackers como los ciberdelincuentes se aprovechan de ella.
¿Qué es el SQL Injection?
El SQl injection es una vulnerabilidad que puede poseer cualquier aplicación (no solo las web aunque estas, están más expuestas) consistente en "romper" una instrucción SQL que genera la aplicación y por el cual podemos acceder a información de una base de datos que a priori no deberíamos poder acceder.
Un ejemplo muy simple, supongamos que una aplicación ejecuta la siguiente instrucción SQL:
select nombre,apellidos from empleados where id='1′;
Esto nos devolvería el nombre y apellidos de un empleado cuyo identificador (id) sea '1'
Imaginemos que ese '1' lo hemos introducido nosotros en un campo de nuestra aplicación, ¿qué sucedería si introdujésemos en ese campo en lugar de un 1 esta secuencia 1′ or '1'='1?
Que entonces nuestra aplicación (si es vulnerable) ejecutaría:
select nombre,apellidos from empleados where id='1′ or '1'='1';
En negrita he marcado lo que hemos tecleado en nuestro campo, como veis esta sentencia SQL retornaría todos los nombres y apellidos de todos los empleados, ya que, aunque la primera condición solo nos retornase uno (o ninguno), la segunda parte del OR siempre se cumple, por lo que retorna todo el contenido fácil ¿no?
¿Cómo explotar esta vulnerabilidad?
Lo primero de todo, para explotar esta vulnerabilidad, tenemos que tener cierto conocimiento de SQL, y saber sobre qué motor de base de datos se está ejecutando la sentencia, dado que, dependiendo del motor de base de datos, las sentencias pueden variar.
Pero, ¿cómo saber si mi aplicación tiene esta vulnerabilidad?
La respuesta es "sencilla", intentando que nuestra aplicación nos devuelva un error que nos indique que la sentencia SQL no es correcta.
Para ello hay mucho métodos, el más clásico, es añadir una comilla simple a la URL o campo, de esta forma, si existe vulnerabilidad, el motor de base de datos nos devolverá un error; en nuestro ejemplo equivaldría a ejecutar:
select nombre,apellidos from empleados where id=''';
Como hemos introducido un carácter delimitador, la sentencia falla.
Como he dicho antes esto se puede producir tanto en una aplicación web como de escritorio, y en las aplicaciones web, tanto en la URL como a nivel de campo.
Una vez descubierta la vulnerabilidad, hay diferentes maneras de atacarla, estas serían las más habituales:
Ejemplo 1
' or '1'='1
La más clásica, sacamos la información gracias a que un operador siempre se cumple, 1=1
Ejemplo 2
'%020or%020'1'='1
Igual que la anterior, pero en este caso se sustituyen los espacios en blanco por su codificación HTML
Ejemplo 3
'/**/or/**/'1'='1
En este caso se hace uso de una vulnerabilidad mediante los caracteres para indicar comentarios
Si queréis trastear un poco con sentencias SQL sin tener que instalar una base de datos ni nada, hay múltiples webs que podemos usar para jugar, como:
¿Cómo prevenirla?
Tanto si es una aplicación web como de escritorio, cuidado con los mensajes de error, no debemos dar nunca más información de la que se deba dar.
Si en nuestro mensaje de error mostramos:
"Error en la sentencia SQL generada sobre la tabla EMPLEADOS — ORA-01756: quoted string not properly terminated"
Con este mensaje estamos indicando que:
- Se usa una base de datos Oracle.
- Existe una tabla EMPLEADOS.
- La sentencia ejecutada retorna un error con el entrecomillado (posible vulnerabilidad de SQL injection)
Así que ojo con los mensajes que ponemos, pueden facilitarnos la vida en algunos aspectos, pero nos la pueden complicar en otros.
"Escapar" los caracteres especiales, es decir añadir una barra \ delante de ellos para delimitarlos y así que no se "rompa" tan fácilmente la sentencia SQL.
Comprobar los tipos de datos que se van a consultar, si el campo es un numérico, ¿porqué permitir que se puedan introducir otros caracteres? Así que dependiendo del lenguaje de la aplicación, hacer todas las validaciones que consideréis oportunas.
Verificar los privilegios de los usuarios, si un usuario únicamente debe hacer consultas sobre unas tablas, no se le debe permitir el acceso al resto ni la ejecución de sentencias SQL que no deba.
Para finalizar existen muchas herramientas que nos permiten detectar vulnerabilidades SQLi:
- SQLmap
- Arachni
- Owasp-ZAP
- Wapiti
- …
Usad la que más cómoda os parezca.
¿Y ya está? No...
Os dejo un par de enlaces de OWASP muy interesantes, tanto para atacar esta vulnerabilidad como para prevenirla, seguro que todos conoceréis OWASP, si no lo conocíais, echadle un ojo, nos provee de mucha documentación y herramientas.
Por cierto, solo os he hablado de un tipo de SQLi,pero hay más...
Always Learning.