Injection Is Broken. Que no te inyecten tu base de datos.
Antonio Froufe Gutierrez Colaboraciones 08/11/2018
En todas las aplicaciones sean del tipo que sea tenemos bases de datos en las que poder guardar información necesaria para su funcionamiento o modelo de negocio, esa información no solo puede ser muy valiosa para la aplicación o la empresa, además puede contener datos de carácter confidencial los cuales en caso de una fuga de información podría acarrear a la empresa responsable una multa de gran cuantía señaladas dentro del RGPD (Reglamento General de protección de Datos). En esta entrada vamos a ver de qué trata un ataque que podrían realizar contra nuestra base de datos, para ex filtrar información llamado SQL Injections y como intentar mitigar los errores de código para intentar protegernos de este tipo de ataques.
Comillas con los codos ¿Que es SQL Injections?
Toda aplicación que interactúa con datos de usuarios o de la empresa, además de un sitio donde guardarlos (llámese Base de datos) va tener también un método de introducción de dichos datos, ahí es donde se puede producir lo que en seguridad informática llamamos “introducir comillas con los codos”, refiriéndonos a introducir código propio de consultas SQL los cuales contienen comillas, y se dice con los codos porque un atacante ni tan siquiera tiene por qué saber que consulta debe realizar para extraer la información.
En definitiva una inyección SQL es una debilidad en los sistemas de bases de datos relacionales, accediendo a sus datos mediante Lenguaje SQL. El uso de los caracteres pertenecientes al lenguaje pueden permitir a usuarios no autorizados manipular, borrar o leer entradas en la base de datos.
Este método se a convertido en uno de los preferidos por los cibercriminales ya que los servidores de bases de datos son muy fáciles de encontrar y fácil de probar si son vulnerables al ataque, por que utilizan unos determinados patrones de ataque bien definidos.
¿Cómo identificar si somos vulnerables?
Las aplicaciones que se comunican mediante bases de datos normalmente no ofrecen el nivel de seguridad más indicado principalmente las que utilizan
SQL. Son altamente conocidas la vulnerabilidades de este lenguaje y para conocer si una aplicación es vulnerable un atacante lo que suele utilizar son los mensajes de error, tan solo con introducir una comilla en la URL podemos saber que lenguaje de base de datos utiliza la aplicación.
[Nombre].es /script.php?id = 10’
Esta manipulación podría darnos como error lo siguiente:
Lo que nos dejaría al descubierto el tipo de base de datos que utiliza la aplicación.
¿Cómo sería un ataque?
El ataque más simple que se puede realizar es en la pantalla de inicio de una aplicación donde se nos pide que nos autentiquemos podemos intentar introducir password’ OR 1= ‘1 lo que podría dar lugar a la siguiente consulta:
Como la anterior sentencia es siempre verdadera nos daría acceso a los datos de usuario de la aplicación, después de dicho acceso el atacante se registraría como administrador pudiendo realizar cualquier tipo de operación en la base de datos.
Otra forma de ataque sería aprovechándose de las consultas que se realizan utilizando el ID de usuario, el cual es un método habitual en las aplicaciones WEB pero no a salvo de debilidades, un ID transmitido en una URL permite a un servidor saber la información que tiene que enviar pero también permite a un atacante utilizarlo en su beneficio, por ejemplo una URL que contenga un script en PHP como el siguiente:
<? php
$ id = $_REQUEST[ ‘id’];
$ resultado = mysql_query(“SELECT * from tabla WHERE id = $id”);
?>
Una URL esperada podría ser …../script.php?id = 45 la cual se podría manipular cambiando el id y de esa manera poder acceder a otros datos de los diferentes usuarios contenidos en la tabla, o en el caso más grave realizar una consulta falsa del siguiente tipo:
….../script.php? Id = 45+or+1 = 1
Lo cual resultaría verdadera en todos los casos devolviendo como resultado todas las entradas de la base de datos.
¿Cómo protegernos de la inyección?
Existen múltiples formas de proteger las aplicaciones de estas vulnerabilidades, pero debemos de tener en cuenta todos los componentes entran en juego para el funcionamiento de las mismas, como son configuración de servidores y otras partes de código de la aplicación. Sin entrar en detalle puesto que sería muy extenso el explicar cada una de ellas vamos a enumerar las más importantes:
-Controlar las enumeraciones automáticas de las aplicaciones.
-Bastionado completo del servidor.
Pero lo más importante es asegurar la base de datos utilizando código seguro como por ejemplo el siguiente código:
$query = “SELECT * FROM usuarios
WHERE nombreUsuario= ‘” . $_POST[‘nombreUsuario’] . “’”
AND contraseña = ‘” . $_POST[‘contraseña’] . “’”;
Lo implementamos añadiéndole una función quedando el código como sigue:
$query = “SELECT * FROM usuarios
WHERE nombreUsuario=‘”.mysql_real_escape_string($_POST[‘nombreUsuario’]) .”
AND contraseña=’” . mysql_real_escape_string($_POST[‘contraseña’]). “’”;
De esta manera se cambian los caracteres vulnerables por una variante SQL más segura. Espero que todas estas recomendaciones te sean de utilidad.