0Pricing
Cyber Security Academy · Lección

Defensa contra la inyección SQL

Prevenga los ataques de inyección

Defensa contra la inyección SQL es una lección gratuita de Cyber Security Academy en CoddyKit. Esta es la lección 1 de 4. Puedes leer la lección completa abajo gratuitamente — luego la practicas en el navegador con un editor de código integrado y un tutor de IA 24/7. Forma parte de la ruta de aprendizaje de Cyber Security Academy, y tu progreso se sincroniza en la web y la app de CoddyKit. El curso de Cyber Security Academy incluye 4 lecciones en total.

Qué es la inyección SQL

La inyección SQL (SQLi) ocurre cuando una entrada de usuario no confiable se concatena directamente en una consulta SQL. El atacante introduce sintaxis SQL en un campo que la aplicación espera que contenga datos simples y cambia el significado de la consulta.

Sigue siendo una de las vulnerabilidades web más dañinas, porque puede filtrar bases de datos completas, eludir inicios de sesión o destruir datos.

Una consulta vulnerable

El error clásico es concatenar cadenas. Si la entrada es tom, la consulta es correcta, pero una entrada manipulada reescribe la lógica.

  • La comilla simple cierra la cadena antes de tiempo.
  • Todo lo que viene después se convierte en SQL ejecutable.
query = "SELECT * FROM users WHERE name = '" + userInput + "'";
// userInput = tom' OR '1'='1
// becomes: SELECT * FROM users WHERE name = 'tom' OR '1'='1'

Elusión de autenticación

Los formularios de inicio de sesión son un objetivo prioritario. Al inyectar una condición siempre verdadera y comentar el resto, un atacante inicia sesión sin contraseña.

La secuencia -- comenta la cláusula restante, por lo que se ignora la comprobación de la contraseña.

-- attacker enters in the username field:
admin' --
-- resulting query:
SELECT * FROM users WHERE user = 'admin' --' AND pass = '...'

Consultas parametrizadas

La principal defensa son las consultas parametrizadas (sentencias preparadas). La estructura SQL se envía por separado de los datos, por lo que la entrada siempre se trata como un valor y nunca como código.

El controlador de la base de datos vincula de forma segura los marcadores ? con los valores proporcionados.

-- Python (sqlite3 / psycopg)
cur.execute(
  'SELECT * FROM users WHERE name = ? AND pass = ?',
  (username, password)
)

Sentencias preparadas en Java

Todos los lenguajes principales ofrecen parametrización. En Java, utilice PreparedStatement en lugar de crear cadenas con Statement.

Los parámetros vinculados no pueden salir de su posición, por lo que la inyección es estructuralmente imposible en este caso.

PreparedStatement ps = conn.prepareStatement(
  "SELECT * FROM users WHERE name = ?");
ps.setString(1, userInput);
ResultSet rs = ps.executeQuery();

Procedimientos almacenados

Los procedimientos almacenados pueden ser útiles cuando utilizan entradas parametrizadas internamente. Sin embargo, tenga cuidado: un procedimiento almacenado que construye SQL dinámico mediante concatenación es igual de vulnerable.

  • Seguro: parámetros pasados al procedimiento.
  • Inseguro: EXEC() de cadenas concatenadas dentro del procedimiento.

Validación de entradas y listas de permitidos

La validación es una segunda capa útil. Utilice listas de permitidos (aceptar únicamente patrones conocidos como válidos) en lugar de listas de bloqueados (intentar prohibir caracteres incorrectos).

Por ejemplo, un campo de ID numérico debería rechazar cualquier valor que no sean dígitos antes de que llegue a la consulta.

if not user_id.isdigit():
    raise ValueError('invalid id')
# only then use the value

El escape es el último recurso

Escapar las comillas manualmente es frágil y propenso a errores. Las distintas bases de datos tienen reglas de escape diferentes y algunos casos límite (trucos de codificación e inyección de segundo orden) pueden pasar inadvertidos.

Prefiera las consultas parametrizadas. Utilice el escape solo cuando un ORM o controlador no pueda parametrizar un identificador concreto.

Mínimo privilegio para las cuentas de la base de datos

Limite los daños de cualquier inyección que tenga éxito aplicando el mínimo privilegio al usuario de la base de datos de la aplicación.

  • Conceda únicamente SELECT, INSERT y UPDATE en las tablas necesarias.
  • No utilice nunca una cuenta de superusuario/root para la aplicación.
  • Deniegue DROP, FILE y los privilegios administrativos.
GRANT SELECT, INSERT, UPDATE ON appdb.orders TO 'webapp'@'%';
REVOKE DROP, ALTER ON appdb.* FROM 'webapp'@'%';

ORM y constructores de consultas

Los ORM modernos (Hibernate, Sequelize, Django ORM, SQLAlchemy) parametrizan de forma predeterminada, lo que elimina la mayor parte del riesgo de inyección.

El peligro reaparece cuando los desarrolladores recurren a SQL sin procesar o utilizan interpolación de cadenas en un constructor de consultas. Pase siempre los valores como parámetros vinculados, incluso en el modo sin procesar.

Defensa en profundidad

Ningún control aislado es suficiente. Combine varias capas:

  • Consultas parametrizadas en todas partes (la principal).
  • Validación de entradas y listas de permitidos.
  • Cuentas de base de datos con mínimo privilegio.
  • Un firewall de aplicaciones web (WAF) que detecte patrones conocidos.
  • Gestión de errores que nunca revele SQL ni trazas de la pila.

Comprobación rápida

Compruebe que entiende la defensa principal.

Resumen

Ha aprendido cómo funciona la inyección SQL y cómo detenerla:

  • La SQLi surge al concatenar entradas no confiables en las consultas.
  • Las consultas parametrizadas son la defensa principal.
  • Añada validación mediante listas de permitidos, cuentas de base de datos con mínimo privilegio y un WAF.
  • Evite el escape manual y el SQL dinámico dentro de los procedimientos almacenados.

La defensa en profundidad evita que un solo error se convierta en una intrusión.

Preguntas frecuentes

¿La lección «Defensa contra la inyección SQL» es gratis?

Sí — el texto completo de «Defensa contra la inyección SQL» es gratis para leer aquí en la web. Para practicarla de forma interactiva (editor de código integrado y tutor de IA 24/7) y desbloquear el resto del curso de Cyber Security Academy, actualiza a CoddyKit PRO. El curso de Cyber Security Academy incluye 4 lecciones en total.

¿Qué aprenderé en «Defensa contra la inyección SQL»?

Prevenga los ataques de inyección Practicas Cyber Security Academy con código real que ejecutas directamente en el navegador, y un tutor de IA 24/7 responde tus preguntas mientras trabajas en la lección.

¿Necesito experiencia previa para empezar Cyber Security Academy?

No se requiere experiencia previa. Cyber Security Academy en CoddyKit está estructurado para principiantes hasta estudiantes avanzados, así que puedes empezar aquí o desde el inicio y avanzar a tu ritmo. Esta es la lección 1 de 4.

¿Cuánto tiempo toma la lección «Defensa contra la inyección SQL»?

La mayoría de las lecciones de CoddyKit toman alrededor de 5–10 minutos. Cada una es compacta e interactiva, así que avanzas constantemente y retomas exactamente por donde dejaste en la web y la app.

¿Puedo escribir y ejecutar código en esta lección de Cyber Security Academy?

Sí. Cada lección de Cyber Security Academy incluye un editor de código integrado, así que escribes y ejecutas código real directamente en tu navegador y obtienes retroalimentación instantánea de IA — sin configuración local necesaria.

Todas las lecciones de este curso

  1. Defensa contra la inyección SQL
  2. Control de acceso y cifrado
  3. Auditoría y supervisión
  4. Seguridad de copias de seguridad y recuperación
← Volver a Cyber Security Academy