El estado de la inyección SQL

La inyección SQL (SQLi) tiene una historia más antigua que Internet Explorer (que, según la Generación Z, fue el inicio 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, seguramente, aprendimos la lección de estas brechas y la SQLi ya no es un problema.

Hemos estado monitoreando el número de inyecciones SQL descubiertas en proyectos de código abierto y cerrado para ver si estamos mejorando. Con las recientes noticias de que los datos robados de la brecha por inyección SQL de MOVEit se están vendiendo a empresas como Amazon, decidimos ofrecerte un adelanto de nuestro próximo informe 'Estado de la Inyección' para 2025.

Spoiler, resulta que seguimos siendo terribles a la hora de prevenir la inyección SQL.

¿Qué es la inyección SQL?

SQLi es una vulnerabilidad que ocurre cuando un programa utiliza directamente una entrada de usuario no confiable en una consulta a una base de datos SQL. Un usuario malicioso puede entonces insertar su propio código y manipular la consulta, permitiéndole acceder a datos privados, eludir la autenticación o eliminar 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 la SQLi, específicamente, ha desempeñado un papel destacado en las brechas de seguridad durante mucho tiempo y resulta sorprendente para muchos que todavía tengamos que discutir esto en 2024.

Cómo ocurre un ataque SQLi

1. Consulta vulnerable
Ejemplo de una consulta vulnerable donde la entrada del usuario se utiliza directamente en la consulta

2. Ataque de inyección SQL
Se inyecta SQL en el campo de entrada de usuario de una página de autenticación

3. Consulta ejecutada con payloadEl payload comenta la verificación de contraseña para que la consulta ignore este paso

SQL injection en cifras:

• El 6.7% de todas las vulnerabilidades encontradas en proyectos de código abierto son SQLi
• ¡10% para proyectos de código cerrado!
• Se espera un aumento en el número total de inyecciones SQL en proyectos de código abierto (CVE’s que involucran SQLi) de 2264 (2023) a 2400 (2024).
• Como porcentaje del total de vulnerabilidades, la inyección SQL está perdiendo popularidad: un descenso del 14% y 17% para proyectos de código abierto y código cerrado, respectivamente, de 2023 a 2024.
• Más del 20% de los proyectos de código cerrado escaneados son vulnerables a la inyección SQL cuando empiezan a utilizar herramientas de seguridad
• Para organizaciones vulnerables a la inyección SQL, el número promedio de sitios de inyección SQL es de casi 30 ubicaciones separadas en el código

Revisamos cuántas vulnerabilidades de SQLi se descubrieron en paquetes de código abierto en 2023 y lo que va de 2024. Luego comparamos eso con proyectos de código cerrado que han sido descubiertos por Aikido Security. Como era de esperar, seguimos viendo cifras sorprendentes de inyección SQL tanto en proyectos de código cerrado 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 sorprendente que en 2024 sigamos luchando por hacer frente a algunas de las vulnerabilidades más básicas que conocemos.

La única buena noticia que tenemos es que esta cifra representa una disminución del 14% respecto a 2023 en proyectos de código abierto y una reducción del 17% en proyectos de código cerrado como porcentaje del total de vulnerabilidades encontradas. Sin embargo, se espera que el número total de inyecciones SQL (SQLi) encontradas aumente de 2264 en 2023 a más de 2400 para finales de 2024 en proyectos de código abierto.

Prevención de inyección SQL

Al parecer, todavía no hay suficiente información en internet sobre cómo prevenir la inyección SQL, así que aquí se presenta un resumen de las opciones disponibles en 2025:

Utiliza sentencias preparadas y consultas parametrizadas

En el ejemplo al inicio de esta publicación de blog, mostramos código vulnerable porque toma la entrada de usuario no confiable y la usa directamente en una consulta. Para evitar esto, deberíamos usar sentencias preparadas (prepared statements), lo que significa definir tu consulta primero y luego añadir la entrada del usuario. Esto separa el flujo de comandos y datos, solucionando el problema por completo. ¡Una gran solución, pero no siempre posible o utilizada!

import sqlite3
conn = sqlite3.connect('example.db')
cursor = conn.cursor()
user_id = 5  # Ejemplo de entrada segura
# Consulta segura usando una consulta parametrizada

cursor.execute("SELECT * FROM users WHERE id = ?", (user_id))

2. Validación de entrada/esquema en el lado del servidor

La validación de entradas puede ser efectiva para prevenir SQLi. Por ejemplo, si su 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. Utilice herramientas SAST y DAST para descubrir SQLi

Uno de los elementos más aterradores de la SQLi es que es fácilmente descubierta por los adversarios, a menudo descrita como una vulnerabilidad fácil de explotar. Parte de esta razón es que herramientas como DAST pueden descubrirlas automáticamente. Esto puede utilizarse a nuestro favor y podemos introducir estas herramientas en nuestro proceso de desarrollo para detectarlas a tiempo.

Las herramientas SAST de próxima generación como Aikido también le permiten corregir automáticamente los problemas directamente desde la plataforma.

4. Implemente un firewall integrado en la aplicación

Un firewall integrado en la aplicación monitoriza el tráfico y la actividad dentro de su aplicación y puede detectar ataques, incluyendo inyección y SQLi. Esto es más eficaz que un WAF tradicional, ya que se encuentra dentro de su aplicación y es capaz de tokenizar las consultas esperadas y bloquear las solicitudes que modifican la estructura de comandos de la consulta.

Publicidad descarada ;) para el nuevo lanzamiento de Aikido: Zen, el firewall integrado en la aplicación para su tranquilidad en tiempo de ejecución. Obtenga 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 SQL dinámico siempre que sea posible

La generación dinámica de SQL mediante la concatenación de cadenas es altamente vulnerable a la inyección 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. Listas blancas y escape

En algunos casos, no se puede evitar el SQL Dinámico, como al consultar tablas dinámicas o cuando se desea ordenar por una columna y dirección definidas por el usuario. En esos casos, no tienes otra opción que recurrir al allowlisting de expresiones regulares o al escaping. El escaping consiste en tomar la entrada del usuario que contiene caracteres peligrosos utilizados en el código, como '>' y convertirlos en una forma segura. Ya sea añadiendo barras invertidas antes de ellos o transformándolos en un código de símbolo. Ten en cuenta que esto no solo es diferente para cada tipo de base de datos, sino que también puede depender de la configuración de conexión, como el charset.

¿Veremos alguna vez el fin de SQLi?

Aunque hay cierta esperanza en el hecho de que hemos visto una disminución algo significativa en el número de vulnerabilidades SQLi encontradas, sigue siendo desalentador ver que una vulnerabilidad que precede al juego DOOM sigue siendo una amenaza tan importante para el panorama. La verdad es que no veo que esto mejore mucho. A medida que introducimos más herramientas para ayudarnos a codificar más rápido, los desarrolladores están perdiendo contacto con los principios fundamentales de la 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 (juego de palabras intencionado); estamos viendo mejoras significativas en una nueva generación de herramientas SAST que son mucho más eficaces en el descubrimiento y la corrección de estas vulnerabilidades, lo que tiene la capacidad de cambiar drásticamente el panorama de amenazas.

Por ahora, me despido, no olvides:

Descubra y corrija automáticamente la inyección SQL con Aikido AI SAST Autofix

Prueba Zen y previene los ataques de inyección en el momento en que ocurren

Bonus: 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 Top 10 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 que involucraron inyección SQL fue cuando la empresa de ropa Guess fue atacada, lo que resultó en la filtración de números de tarjetas de crédito. Desde entonces, la inyección SQL ha sido un invitado habitual en los titulares de seguridad.

Bonus Parte 2 - Consulta Ataques de Inyección 101 para obtener una introducción a las inyecciones SQL, inyecciones de código y XSS