¿Qué es SQL Injection?

SQL injection es un ataque donde código SQL malicioso se inserta en los campos de entrada de aplicaciones para manipular o extraer datos de una base de datos sin autorización.

TL;DR SQL injection (SQLi) es un ataque de inyección de código en el que un atacante inserta instrucciones SQL maliciosas en campos de entrada que se pasan a una consulta de base de datos. Cuando la aplicación no sanitiza la entrada, la base de datos ejecuta los comandos del atacante en lugar de la consulta original. SQL injection es la vulnerabilidad #1 en el OWASP Top 10 y puede resultar en el compromiso total de la base de datos, exfiltración de datos, bypass de autenticación y, en algunos casos, ejecución remota de código. La prevención requiere consultas parametrizadas (prepared statements), no solo filtrado de entrada.

¿Qué es SQL injection?

SQL injection (SQLi) es una técnica de ataque en la que un atacante inserta o “inyecta” código SQL malicioso en una consulta que una aplicación envía a su base de datos. Cuando la aplicación concatena entrada de usuario no validada directamente en una consulta SQL, la base de datos interpreta la entrada del atacante como comandos SQL y los ejecuta.

SQL injection no requiere explotar una vulnerabilidad de software en el sentido tradicional — explota la falla de separar código de datos. Cualquier aplicación que construye consultas SQL usando concatenación de cadenas a partir de entrada proporcionada por el usuario es potencialmente vulnerable.

SQL injection ha estado en la lista OWASP Top 10 de riesgos críticos de seguridad en aplicaciones web desde que la lista fue publicada por primera vez en 2003. De acuerdo con el OWASP Top 10 de 2021, las fallas de inyección (incluyendo SQLi) ocupan el #3, afectando el 94% de las aplicaciones evaluadas.

Cómo funciona SQL injection

Considera un formulario de inicio de sesión que construye esta consulta:

SELECT * FROM users WHERE username = '$username' AND password = '$password';

Un usuario normal envía maria y contraseña123. La consulta se convierte en:

SELECT * FROM users WHERE username = 'maria' AND password = 'contraseña123';

Un atacante envía ' OR '1'='1 como nombre de usuario. La consulta se convierte en:

SELECT * FROM users WHERE username = '' OR '1'='1' AND password = 'cualquier_cosa';

Porque '1'='1' es siempre verdadero, la consulta retorna todos los usuarios — y el atacante queda autenticado como el primer usuario en la base de datos, generalmente un administrador.

Tipos de SQL injection

SQL injection in-band

El atacante usa el mismo canal para inyectar el ataque y recuperar los resultados. Es el tipo más común.

SQL injection inferencial (blind)

SQL injection out-of-band

El atacante hace que la base de datos envíe datos a un servidor externo (mediante solicitudes DNS o HTTP). Este tipo es menos común y depende de funcionalidades específicas de la base de datos — como procedimientos almacenados que realizan llamadas de red. Se utiliza frecuentemente cuando los canales in-band son lentos o inestables.

Qué puede lograr SQL injection

Cómo prevenir SQL injection

1. Usa consultas parametrizadas (prepared statements)

Las consultas parametrizadas son la defensa primaria y más efectiva contra SQL injection. Al separar el código SQL de los datos del usuario, eliminan la posibilidad de que la entrada sea interpretada como SQL.

Vulnerable:

query = "SELECT * FROM users WHERE username = '" + username + "'"

Seguro:

query = "SELECT * FROM users WHERE username = ?"
cursor.execute(query, (username,))

El mismo principio aplica en otros lenguajes:

// Java con PreparedStatement
PreparedStatement stmt = conn.prepareStatement(
    "SELECT * FROM users WHERE username = ?"
);
stmt.setString(1, username);
ResultSet rs = stmt.executeQuery();

// Node.js con mysql2
const [rows] = await connection.execute(
    'SELECT * FROM users WHERE username = ?',
    [username]
);

2. Usa un ORM

Los ORMs (Django ORM, Hibernate, ActiveRecord, Sequelize) construyen consultas parametrizadas por defecto, reduciendo el riesgo de SQL injection al abstraer la construcción manual de consultas. Sin embargo, aún es posible introducir vulnerabilidades al usar consultas SQL crudas dentro de un ORM — siempre prefiere la API de consulta del ORM.

3. Aplica el principio de mínimo privilegio

La cuenta de base de datos utilizada por la aplicación debe tener solo los permisos que necesita. Si la aplicación solo lee datos, el usuario de la base de datos no debería tener permisos de DELETE o DROP. Esto no previene SQL injection, pero limita el impacto si un ataque tiene éxito.

4. Implementa un Web Application Firewall (WAF)

Un WAF detecta y bloquea patrones de SQL injection en solicitudes HTTP antes de que lleguen a la aplicación. Un WAF de calidad analiza parámetros de URL, encabezados HTTP, cookies y el cuerpo de la solicitud en busca de payloads SQLi conocidos. Sin embargo, un WAF es una capa de defensa en profundidad — nunca un reemplazo para las consultas parametrizadas en el código de la aplicación.

5. Valida y sanitiza la entrada

Valida el tipo, longitud y formato de las entradas. Por ejemplo, si un campo espera un entero, rechaza cualquier valor que no sea numérico. Este enfoque reduce la superficie de ataque, pero no es suficiente por sí solo — los atacantes pueden eludir las validaciones de entrada, especialmente en campos de texto libre.

6. Usa listas de permitidos en lugar de listas de bloqueados

Cuando sea posible, valida la entrada contra un conjunto conocido de valores válidos (lista de permitidos) en lugar de intentar bloquear patrones maliciosos (lista de bloqueados). Por ejemplo, si un parámetro orderby acepta solo name o date, rechaza cualquier otro valor.

Detección de SQL injection

Señales de que una aplicación puede ser vulnerable:

• Mensajes de error que contienen sintaxis SQL (p. ej., You have an error in your SQL syntax)
• Respuestas diferentes al agregar ' OR '1'='1 versus ' OR '1'='2
• Retrasos de tiempo al inyectar SLEEP(5) o WAITFOR DELAY '00:00:05'
• Errores HTTP 500 inesperados al enviar comillas simples (') o dobles (") en campos de entrada
• Diferencias en el comportamiento de la aplicación al modificar parámetros de URL con caracteres SQL especiales

Herramientas automatizadas como sqlmap son ampliamente utilizadas por investigadores de seguridad y atacantes para detectar y explotar vulnerabilidades de SQL injection. Las pruebas de penetración regulares y las revisiones de código son fundamentales para identificar SQLi antes de que lo hagan los atacantes.

SQL injection y el OWASP Top 10

El OWASP (Open Web Application Security Project) mantiene una lista de las diez categorías de vulnerabilidades de seguridad más críticas en aplicaciones web. Las fallas de inyección — incluyendo SQL injection — aparecen en esta lista desde su primera publicación en 2003.

La consolidación en el ranking 2021 refleja una reorganización de categorías, no una reducción de la amenaza. SQL injection sigue siendo una de las vulnerabilidades más explotadas en entornos de producción.

Preguntas frecuentes

¿Qué es SQL injection en términos simples? SQL injection es cuando un atacante engaña a un sitio web para que ejecute comandos de base de datos que no eran los previstos. Si un formulario de inicio de sesión pasa la entrada del usuario directamente a una consulta de base de datos sin verificarla, un atacante puede escribir comandos SQL en lugar de un nombre de usuario real y manipular la base de datos.

¿Sigue siendo SQL injection una amenaza en 2026? Sí. SQL injection ha sido la vulnerabilidad de aplicaciones web más crítica durante más de dos décadas. A pesar de ser bien entendida, persiste porque los desarrolladores continúan construyendo consultas usando concatenación de cadenas, especialmente en código heredado y en proyectos con baja madurez de seguridad.

¿Qué es una consulta parametrizada? Una consulta parametrizada es una instrucción SQL donde la entrada del usuario se pasa como un parámetro separado, no concatenada en la cadena de la consulta. La base de datos trata la entrada como datos — nunca como código SQL. Esto elimina fundamentalmente el vector de SQL injection.

¿Puede un WAF por sí solo detener SQL injection? Un WAF bloquea patrones conocidos de SQL injection y proporciona una importante capa de defensa en profundidad, pero no puede ser la única protección. La solución fundamental siempre son las consultas parametrizadas en el código de la aplicación. Los atacantes avanzados pueden eludir reglas de WAF usando variaciones de payload, codificación o fragmentación.

¿Qué bases de datos son afectadas por SQL injection? Todas las bases de datos relacionales que procesan SQL: MySQL, PostgreSQL, Microsoft SQL Server, Oracle, SQLite. La sintaxis SQL específica varía por base de datos — por ejemplo, SLEEP() en MySQL versus WAITFOR DELAY en MSSQL — pero la vulnerabilidad subyacente es la misma.

¿Cuál es la diferencia entre SQL injection y XSS? SQL injection tiene como objetivo la capa de base de datos — el atacante envía SQL malicioso para ser ejecutado por la base de datos. XSS tiene como objetivo a los usuarios — el atacante inyecta JavaScript malicioso que se ejecuta en los navegadores de otros usuarios. Ambos explotan fallas de validación de entrada, pero en diferentes capas de la aplicación.

¿Cómo funciona el SQL injection blind? En SQL injection blind (ciego), la aplicación no retorna datos de la base de datos en su respuesta. El atacante infiere información observando diferencias en el comportamiento (basado en booleano — por ejemplo, la página carga diferente para true versus false) o en el tiempo de respuesta (basado en tiempo — el servidor tarda más en responder cuando un SLEEP() se inyecta exitosamente).

¿Cuál es el ranking de OWASP para SQL injection? Inyección (incluyendo SQL injection) ocupa el #3 en el OWASP Top 10 2021, presente en el 94% de las aplicaciones evaluadas. En ediciones anteriores (2013, 2017), inyección ocupaba el #1. El cambio de ranking refleja una reorganización de categorías, no una disminución en la prevalencia o gravedad.