La inyección SQL (SQLi) tiene una historia más antigua que Internet Explorer (que según la Generación Z fue el comienzo de la civilización). Ha habido miles de brechas causadas por la inyección SQL y una cantidad interminable de mejores prácticas y herramientas bien documentadas para ayudar a prevenirla. Así que seguro, seguro que hemos aprendido la lección de estas brechas y SQLi ya no es un problema.
Hemos estado monitorizando el número de inyecciones SQL descubiertas en proyectos de código abierto y de código cerrado para ver si estamos mejorando. Con la reciente noticia de que los datos robados de la brecha de inyección SQL de MOVEit se están vendiendo a empresas como Amazon, hemos decidido darte un adelanto de nuestro próximo informe sobre el estado de las inyecciones para 2025.
Spoiler, resulta que seguimos siendo terribles en la prevención de la inyección SQL.
¿Qué es la inyección SQL?
SQLi es una vulnerabilidad que se produce cuando un programa utiliza entradas de usuario no fiables directamente en una consulta a una base de datos SQL. Un usuario malintencionado puede entonces insertar su propio código y manipular la consulta permitiendo al usuario malintencionado acceder a datos privados, saltarse la autenticación o borrar datos. El siguiente ejemplo muestra cómo una consulta SQL insegura para una página de inicio de sesión de usuario es vulnerable a un ataque de omisión de autenticación SQLi.
Existen muchos tipos diferentes de ataques de inyección, como la inyección de código o el cross-site scripting (XSS). Pero SQLi en concreto ha desempeñado un papel destacado en las brechas durante mucho tiempo y a muchos les sorprende que todavía tengamos que hablar de ello en 2024.
Cómo se produce un ataque SQLi
1. Consulta vulnerable
Ejemplo de consulta vulnerable en la que la entrada del usuario se utiliza directamente en la consulta
2. Ataque de inyección SQL
Se inyecta SQL en el campo de entrada del usuario de una página de autenticación.
3. La consulta ejecutada con payloadPayloadcomenta la comprobación de la contraseña, por lo que la consulta ignora este paso.
La inyección SQL en cifras:
- El 6,7% de todas las vulnerabilidades detectadas en proyectos de código abierto son SQLi
- 10% para proyectos de código cerrado
- Se esperaun aumento del número total de inyecciones SQL en proyectos de código abierto (CVE que implican SQLi) de 2264 (2023) a 2400 (2024) .
- Como porcentaje de todas las vulnerabilidades, la inyección SQL es cada vez menos popular: una disminución del 14% y el 17% para los proyectos de código abierto y de código cerrado, respectivamente, de 2023 a 2024.
- Más del 20% de los proyectos de código cerrado analizados son vulnerables a la inyección SQL cuando empiezan a utilizar herramientas de seguridad.
- Para las organizaciones vulnerables a la inyección SQL, el número medio de sitios de inyección SQL es de casi 30 ubicaciones distintas en el código
Revisamos cuántas vulnerabilidades SQLi se descubrieron en paquetes de código abierto en 2023 y lo que va de 2024. Luego lo comparamos con los proyectos de código cerrado que han sido descubiertos por Aikido Security. Como era de esperar, seguimos observando cifras escandalosas de inyección SQL tanto en proyectos cerrados como de código abierto. El 6,7% de todas las vulnerabilidades descubiertas en proyectos de código abierto en 2024 son vulnerabilidades de inyección SQL, mientras que el 10% de las vulnerabilidades descubiertas en proyectos de código cerrado fueron vulnerabilidades de inyección SQL. Esto puede no parecer mucho, pero es francamente chocante que en 2024 todavía estemos luchando para hacer frente a algunas de las vulnerabilidades más básicas que conocemos.
La única buena noticia que tenemos es que esta cifra supone un descenso del 14% con respecto a 2023 en proyectos de código abierto y una reducción del 17% en proyectos de código cerrado como porcentaje de todas las vulnerabilidades encontradas. Sin embargo, se espera que el número total de SQLi encontradas aumente de 2264 en 2023 a más de 2400 a finales de 2024 en proyectos de código abierto.
Prevención de inyecciones SQL
Por lo visto, todavía no hay suficiente información en Internet sobre cómo evitar la inyección SQL, así que aquí tienes un resumen de las opciones disponibles en 2025:
1. Utilizar sentencias preparadas y consultas parametrizadas
En el ejemplo al principio de este Blog Post, mostramos código vulnerable porque toma datos no confiables del usuario y los usa directamente en una consulta. Para evitar esto debemos usar sentencias preparadas, lo que significa definir tu consulta primero y añadir la entrada del usuario después. Esto separa el flujo de comandos y el de datos, solucionando el problema por completo. Una gran solución, pero no siempre posible o utilizada.
import sqlite3
conn = sqlite3.connect('ejemplo.db')
cursor = conn.cursor()
user_id = 5 # Ejemplo de entrada segura
# Consulta segura mediante consulta parametrizada
cursor.execute("SELECT * FROM users WHERE id = ?", (user_id))
2. Validación de entradas/esquemas en el servidor
La validación de entradas puede ser eficaz para evitar SQLi. Por ejemplo, si tu API espera una dirección de correo electrónico o un número de tarjeta de crédito, es fácil añadir validación para esos casos.
3. Utilizar las herramientas SAST y DAST para descubrir SQLi
Uno de los elementos más aterradores de SQLi es que es fácilmente descubierta por los adversarios, a menudo descrita como una vulnerabilidad de bajo riesgo. Parte de esta razón se debe a que herramientas como DAST pueden descubrirlas automáticamente. Esto se puede utilizar a nuestro favor y podemos introducir estas herramientas en nuestro proceso de desarrollo para detectarlas a tiempo.
Las herramientas SAST de última generación, como Aikido, también permiten autocorregir los problemas desde la propia plataforma.
4. Implantar un cortafuegos en la aplicación
Un cortafuegos integrado en la aplicación supervisa el tráfico y la actividad dentro de la aplicación y puede detectar ataques como inyecciones y SQLi. Es más eficaz que un WAF tradicional, ya que se sitúa dentro de la aplicación y es capaz de tokenizar las consultas esperadas y bloquear las solicitudes que cambian la estructura de comandos de la consulta.
Shameless plug ;) parael nuevo lanzamiento de Aikido: Zenel cortafuegos integrado en la aplicación para mayor tranquilidad en tiempo de ejecución. Consigue Zen y bloqueará automáticamente los ataques de inyección críticos y las amenazas de día cero en tiempo real, antes de que lleguen a su base de datos.
5. Evitar el SQL dinámico siempre que sea posible
La generación dinámica de SQL mediante la concatenación de cadenas es muy vulnerable a la inyección de SQL. Siempre que sea posible, utilice consultas estáticas predefinidas y procedimientos almacenados que no dependan del contenido generado por el usuario para la estructura SQL.
6. Permitir listas y escapes
En algunos casos, no se puede evitar el SQL Dinámico, como cuando se consultan tablas dinámicas, o cuando se desea ordenar por una columna y dirección definidas por el usuario. En esos casos, no le queda más remedio que recurrir a las listas de expresiones regulares permitidas o a la evasión. Escapar es tomar la entrada del usuario que contiene caracteres peligrosos usados en código como '>' y convertirlos en una forma segura. Ya sea añadiendo barras invertidas delante de ellos o transformándolos en un código de símbolos. Tenga en cuenta que esto es diferente no sólo para cada tipo de base de datos, sino que también puede depender de la configuración de la conexión, como el conjunto de caracteres.
¿Veremos algún día el fin de SQLi?
Aunque el hecho de que hayamos visto una disminución significativa en el número de vulnerabilidades SQLi encontradas es algo prometedor, sigue siendo desalentador ver que una vulnerabilidad anterior al juego DOOM sigue siendo una amenaza tan importante para el panorama. La verdad es que no veo que esto vaya a mejorar mucho. A medida que introducimos más herramientas para ayudarnos a codificar más rápido, los desarrolladores están cada vez menos en contacto con los principios básicos de codificación y estas herramientas de IA son notoriamente malas a la hora de sugerir código vulnerable con vulnerabilidades de inyección incluidas.
Sin embargo, no todo es pesimismo, ya que estamos asistiendo a mejoras significativas en una nueva generación de herramientas SAST mucho más eficaces a la hora de descubrir y corregir estas vulnerabilidades, lo que puede cambiar drásticamente el panorama de las amenazas.
Me despido por ahora, no lo olvides:
Descubra y corrija automáticamente las inyecciones SQL con Aikido AI SAST Autofix
Pago Zen y evite los ataques de inyección en el momento
Bonificación: Historia de SQL a lo largo de la historia
Desde que empezamos a hablar de seguridad en nuestras aplicaciones hemos hablado de la inyección SQL. Incluso apareció en el número 7 de la primera lista de los 10 principales de OWASP en 2003, en 2010 se incluyó en la categoría de inyección y ocupó el puesto número 1 hasta 2021. Uno de los primeros ataques a gran escala documentados con inyección SQL fue el de la empresa de ropa Guess, que dio lugar a la filtración de números de tarjetas de crédito. Desde entonces, la inyección SQL ha sido un invitado habitual entre los titulares de seguridad.
Bonus Pt 2 - Echa un vistazo a Inyección Ataques 101 para obtener la una introducción a las inyecciones SQL, inyecciones de código, y XSS
.png)
.svg)
.png)
.png)
.png)
.jpg)
.jpg)
.jpg)
.jpg)
.png)