Introducción: La Vulnerabilidad que Permite Hablar con la Base de Datos
La Inyección SQL (SQLi) es, por su potencial destructivo, una de las vulnerabilidades más temidas y persistentes en el desarrollo de aplicaciones web. Ocurre cuando una aplicación web construye una consulta SQL utilizando datos de entrada no validados del usuario, permitiendo que el atacante “inyecte” comandos SQL maliciosos para modificar la lógica de la consulta.
El resultado de un ataque SQLi puede ser el robo masivo de datos de usuarios, credenciales, la modificación de precios o inventarios, o la eliminación total de la base de datos.
Tipos Clave de Inyección SQL (SQLi): Las Tres Caras del Riesgo
Las SQLi se clasifican según el método de entrega y la respuesta de la base de datos:
1. Inyección Basada en Errores (Error-Based SQLi)
El atacante utiliza comandos específicos (como UNION SELECT o funciones que fuerzan errores) para hacer que la base de datos devuelva mensajes de error que contienen información técnica valiosa (ej. el nombre de las tablas, columnas o el tipo de base de datos).
El atacante extrae datos de forma directa a través de la interfaz web.
2. Blind SQLi (Inyección Ciega)
La aplicación no devuelve datos directamente ni muestra errores. El atacante debe inferir la información haciendo preguntas binarias (Sí/No) y observando la respuesta.
Subtipos:
- Time-Based: La consulta contiene una función de retardo (SLEEP(5)). Si la página tarda 5 segundos en cargar, la condición fue verdadera.
- Boolean-Based: La consulta hace una pregunta cuya respuesta solo puede ser verdadera o falsa. Si la condición es verdadera, la página carga normalmente. Si es falsa, la página muestra un error o carga diferente.
3. Inyección UNION (Union-Based SQLi)
Permite al atacante usar el operador UNION para agregar los resultados de su propia consulta SQL a la consulta legítima de la aplicación, extrayendo datos de diferentes tablas.
Mitigación y Prevención: La Arquitectura de Defensa
La defensa contra SQLi debe ser una prioridad en el proceso DevSecOps
La defensa número uno y más efectiva son las Consultas Parametrizadas. Garantiza que el código SQL se defina por completo antes de que se le pasen los datos de entrada. El input del usuario siempre se trata como datos (string) y nunca como código ejecutable de SQL.
Implementar una estricta Validación del tipo de Datos. Si se espera un número entero (ID), rechazar cualquier entrada que contenga comillas o caracteres especiales que puedan usarse en una inyección.
Aplicar el Principio de Mínimo Privilegio. Limitar la cuenta de base de datos que usa la aplicación web para que solo tenga los permisos estrictamente necesarios (ej. solo leer, no eliminar). Esto minimiza el daño si ocurre una inyección.
