HOME » Sql Injection 💉: Amenaza #1 en aplicaciones Web

Sql Injection 💉: Amenaza #1 en aplicaciones Web

¿Sabías que la profesión de experto en seguridad informática es una de las más demandas en el mercado? Vivimos en una era de transformación digital en la que cada vez hay más sistemas informatizados, más información, más imágenes, más post, más tweets… ¡más de todo!

Entre las aplicaciones web hay innumerables vulnerabilidades que pueden ser atacadas por los malos y dejar al descubierto información privilegiada…
No queremos eso, ¿verdad?

Trolldad experto en CiberSeguridad de redes salchichoneras

💻 ¿Qué es el Sql Injection (SQLi)?

Entre todas las vulnerabilidades web y desde hace unos años, Sql Injection es la vulnerabilidad más común entre aplicaciones web. Puedes ver en OWASP (Open Web Application Security Project) el TOP10 de vulnerabilidades.

Es un tipo de ataque que permite ejecutar sentencias SQL maliciosas contra bases de datos. Estas consultas se ejecutan a través de la aplicación web, que hace de interfaz para el atacante.

Puede utilizarse Sql Injection para saltarse el logado de un usuario y obtener todo lo que contiene la base de datos a la que no deberías tener acceso. Los ataques no solo sirven para obtener información, también puede modificarse o eliminarse.

📑 Ejemplo de Sql Injection

Ahora que ya conocemos la teoría, vamos con un ejemplo práctico. Este es muy sencillo, servirá para hacernos a la idea.

Imagina el típico formulario de acceso/login en una plataforma de contenidos. Puede ser el acceso a una suscripción de pago de un periódico, a una zona de un foro limitada a usuarios premium o a cualquier otra plataforma que seguro tienes en mente:

Típico formulario de login

Cuando un usuario legítimo entra normalmente a la plataforma sucede lo siguiente:

🌐 Comportamiento de la aplicación

  1. El usuario escribe su usuario y password en el formulario y pulsa «LOGIN»
  2. Un lenguaje de la parte de servidor, como puede ser php, montará una sentencia sql concatenando usuario/contraseña que se ha introducido desde el formulario
  3. Se ejecuta la sentencia en la base de datos y esta otorga el permiso en función de si encuentra el registro del usuario o no.

Bien, ahora imagina que en la base de datos hay una tabla de usuarios y contraseñas. La sentencia sql que se ejecutará contra el servidor normalmente de un usuario que intenta entrar es la siguiente:

select acceso from usuarios where usuario='Pedro' and password='LaPasswordDePedro';

☑️ La base de datos devolverá o no un registro en función de si Pedro se encuentra entre sus filas. Tanto si Pedro es un usuario que tiene acceso como si no, la aplicación no fallará.

💉 Inyectando Sql al formulario

Pensando en la query que se ejecuta contra la base de datos… en vez de poner una posible password, con Sql Injection podemos utilizar operadores lógicos que se concatenen a la sentencia sql y ejecutarlo contra la base de datos.

¿Te has perdido? No te preocupes, lo vas a ver mejor con el ejemplo de Pedro. Si en el campo password del formulario ponemos:

password' OR 1=1

La sentencia sql que se ejecute contra la base de datos será:

select acceso from usuarios where usuario='Pedro' and password='password' OR 1=1';

Como uno es igual a uno siempre, aunque la contraseña de Pedro no la conozcamos, la condición siempre encontrará el primer registro en la base de datos, que normalmente es el administrador.

IDUSUARIOPASSWORD
1AdminLacontraseniadificil123
2PedroLacontrasenadePedroLOL
3TrolldadAyQuemeLOL!
Ejemplo de los valores que podría tener la tabla de usuarios

⚠️ El atacante no solo accede a la aplicación, también gana los privilegios de administración.

👨‍🦯 Blind Sql Injection

Blind Sql Injection es un tipo de ataque a una vulnerabilidad en el que la aplicación no devuelve los resultados de la consulta sql que le estamos haciendo, ni detalles de los errores de la base de datos.

El atacante extrae información de una base de datos en función de si esta devuelva TRUE o FALSE a las «preguntas» que le hacemos, con lo que requiere de más paciencia.

Pongamos esta url.

http://urlparaesteproposito.com/content.php?id=3

Parece que id es un identificador de contenidos dinámico. Es decir, si cambiamos el 3 por 4 seguramente veamos otro contenido en la propia página, otro post.

Ahora inyectamos sql a esa misma query (and 1=0). Una concatenación que devolverá FALSE, pues 1 nunca es igual a 0, y observamos el comportamiento del servidor:

http://urlparaesteproposito.com/content.php?id=3 and 1=0

Si ahora no muestra contenido pero sí ha cargado la url sin mostrar error significa que ha ejecutado la query en la base de datos, no ha encontrado nada y ha cargado el html después mostrando un contenido vacío.

⚠️ A partir de aquí se abre la veda, pues ya podemos ejecutar querys contra la base de datos.

Piensa, ¿Qué empezarías preguntando a una base de datos que no tienes delante y solo puede responderte sí o no? Tendrás que empezar con las tablas del sistema para conocer el catálogo de tablas por ejemplo. También hay que tener intuición.

Esta url devolvería TRUE en caso de que el primer caracter de la primera tabla fuera a.

El valor Ascii de a es 97, de ahí el valor.
http://urlparaesteproposito.com/content.php?id=3 and Ascii(substring((Select table_name from information_schema.tables where table_schema=database() limit 0,1),1,1))>97%23

Si devolviera FALSE, habría que probar con el caracter Ascii que corresponde a la b, y así con todo el abecedario. Cuando tuvieras la primera letra, habría que averiguar la segunda, hasta dar con la cadena completa.

Es un trabajo muy tedioso, ¿verdad? Lo importante es que entiendas la vulnerabilidad y el método con que se explota. Hay herramientas como sqlmap que automatizan este trabajo, pero ninguna va a sustituir a tu intuición, experiencia y criterio.

⚔️ Como prevenirse de Sql Injection

Los ataques de Sql Injection se evitan parametrizando las consultas sql.

Consiste en preparar la sentencia que se va a ejecutar en la base de datos para evitar la concatenación de cadenas dentro de la consulta.

Cada lenguaje servidor tiene sus propias funciones para parametrizar las variables en las consultas. En PHP se utilizaría la función bind_param:

$sql= $mysqli->prepare("INSERT INTO users(id) VALUES (?)");
$id = 1;
$sql->bind_param("i", $id)
$sentencia->execute();

Estas consultas parametrizadas deberían usarse siempre para datos de entradas de usuarios, provengan de formularios, por querystring, ficheros u otros medios.

🔎 Google Dorks para Sql Injection

Aunque el título te suene a japonés la cosa es bastante seria. Básicamente hay operadores que, con una búsqueda en google encontramos webs vulnerables a Sql Injection.

No es que estemos comprobando que una web sea o no vulnerable, sino que el propio google sugiere sitios que es probable que tengan fallas de seguridad. Un ejemplo sería:

inurl:".php?cid=" intext:"Buy Now"

En internet hay cientos de google dorks para SQLi. Con algo de intuición es sencillo sacar tus propios dorks. Para no abrumar a nadie voy a poner solo un puñado para que conozcas la técnica y sepas por donde van los tiros:

content.php?ID=
noticias.php?ID=
content.php?arti_id=
default.php?loc=
default.php?read=
details.php?prodId=
download.php?id=
enter.php?get=
Puntuación
¡Haz clic para puntuar esta entrada!
(Votos: 2 Promedio: 5)
Summary
Sql Injection: Amenaza #1 en aplicaciones
Article Name
Sql Injection: Amenaza #1 en aplicaciones
Description
Entre todas las vulnerabilidades web y desde hace unos años, Sql Injection es la vulnerabilidad más común entre aplicaciones web.
Author
Publisher Name
tech4trolls.com
Publisher Logo

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *