SQL Injection (SQLi)
Última actualización
Última actualización
Es una vulnerabilidad web crítica que permite a un atacante interferir en las consultas que una aplicación realiza contra su base de datos.
Este ataque consiste en la inyección de consultas SQL a través de los datos de entrada del cliente a la aplicación permitiendo a un atacante leer datos que normalmente no podría consultar y en muchos casos, también modificar o borrar.
Dentro de los riesgos de seguridad que presentan las aplicaciones web, esta técnica se encuentra en tercera posición, listada como dentro del informe de 2021, que facilitó el proyecto abierto de seguridad de aplicaciones web y categorizada dentro del sistema de debilidades y vulnerabilidades de software como .
Existen diferentes tipos de SQLi agrupados en los siguientes grupos:
El atacante utiliza el mismo canal de comunicación para enviar el ataque y recibir el resultado. En otras palabras el atacante inyecta el código SQL malicioso en la aplicación web y recibe el resultado del ataque a través del mismo canal usado para enviar el código.
Dentro de este grupo tenemos dos variaciones:
Error-Based: El atacante inyecta código malicioso para causar mensajes de error del lado de la aplicación web.
Union-Based: El atacante hace uso del operador UNION para combinar el resultado de dos o mas consultas SQL en un solo resultado.
En este apartado veremos una breve demostración de como se realiza un ataque simple SQLi. Para ponernos en situación, imaginemos que tenemos un panel de autenticación como podría ser el siguiente, que por detrás se esta realizando una consulta SQL a la base de datos para validar el proceso de autenticación.
Tenemos tanto la entrada de datos para el usuario como para la contraseña.
Viendo el panel login de acceso podemos intuir que por detrás se puede estar empleando una consulta SQL de validación como la siguiente:
Si la aplicación no trata el input de datos correctamente como en este caso una comilla simple, un atacante puede introducirla para cerrar la cadena de texto de la consulta y seguidamente inyectar su payload malicioso. Aquí podríamos ver un payload muy típico.
La posible consulta SQL que se podría emplear para la validar la autenticación, quedaría así:
Con este payload conseguimos las siguientes condiciones:
Se cerrará la cadena de texto del campo username gracias a la comilla simple. Esto significa que se seleccionarán todas las filas donde el campo username está vacío, es decir, se seleccionarán las filas donde no hay nombre de usuario (muy improbable que exista una entrada en la tabla users sin nombre de usuario).
1=1, esta parte siempre será verdadera (TRUE) en una sentencia SQL. Por lo tanto, esta parte de la condición siempre se cumple, independientemente del valor del campo username. Por lo que, se seleccionarán todas las filas de la tabla users.
Con el punto y coma ";" cerramos la consulta.
Por último, los caracteres "--" se utilizan para realizar comentarios en las consultas SQL por lo que todo lo que viene después de "--" será ignorado por el motor de la base de datos.
En resumen, esta consulta SQL seleccionará todas las filas de la tabla users, ignorando cualquier contraseña que pudiera haberse proporcionado en la consulta. Es un ejemplo de una inyección SQL potencialmente maliciosa, ya que está diseñada para evadir la autenticación y seleccionar todas las filas de la tabla de usuarios.
Para evitar ser vulnerables a SQLi es posible implementar una serie de medidas de seguridad.
Utilizar consultas parametrizadas o preparadas: En lugar de concatenar directamente los valores en la consulta SQL, utiliza parámetros o marcadores de posición. Esto evita que los datos de entrada se interpreten como parte del código SQL.
Validar y filtrar la entrada del usuario: Antes de ejecutar cualquier consulta SQL, valida y filtra la entrada del usuario. Esto implica verificar que los datos proporcionados por el usuario sean del tipo y formato esperados, y rechazar cualquier entrada que parezca sospechosa o maliciosa.
Escapar caracteres especiales: Si no es posible utilizar consultas parametrizadas, asegúrate de escapar los caracteres especiales dentro de las entradas del usuario antes de concatenarlos en la consulta SQL. Esto evita que los caracteres especiales se interpreten como parte del código SQL.
Utilizar listas blancas en lugar de listas negras: En lugar de intentar filtrar y bloquear cada posible ataque, utiliza listas blancas para permitir solo ciertos caracteres o patrones de entrada. Esto reduce la superficie de ataque y hace que el sistema sea más seguro.
