SQL

SQL (Structured Query Language) es el lenguaje estándar utilizado para gestionar y manipular bases de datos relacionales. En el ámbito de la ciberseguridad, comprender SQL es fundamental para identificar vulnerabilidades, prevenir inyecciones maliciosas y asegurar la integridad de los datos.

Características

1. Jerárquico:

Estructura tipo árbol invertido (nodos primarios y secundarios).
Un nodo principal puede tener muchos secundarios, pero un nodo secundario solo un principal.
Datos organizados en nodos, equivalente lógico a tablas.
Limitaciones: inflexible, difícil manejar relaciones complejas.

Ejemplo: IMS de IBM, que añade características para superar limitaciones.

2. Red:

Mejora las limitaciones del modelo jerárquico.
Datos organizados en tipos de registro, equivalente lógico a tablas.
Relaciona pares de registros como propietarios y miembros, permitiendo relaciones más complejas.

Limitaciones: complejidad, requiere que el usuario conozca la estructura, difícil modificar sin afectar aplicaciones

3. Relacional:

Basado en tablas (relaciones) y relaciones entre ellas.
Independiente de la aplicación: cambios en la estructura no afectan la aplicación.
Permite definir relaciones complejas sin necesidad de navegar por estructuras jerárquicas o de red.
Ventaja: acceso directo a cada tabla sin las limitaciones de jerarquía o propietario/miembro.

Mejora la flexibilidad y mantenibilidad respecto a jerárquico y en red.

Conceptos Fundamentales

Base de datos (Database) — Colección organizada de información.
Tabla (Table) — Estructura que almacena los datos en filas y columnas.
Registro (Row) — Una entrada individual dentro de una tabla.
Campo (Field) — Un atributo específico dentro de una tabla.
Clave primaria (Primary Key) — Identificador único de cada registro.
Índice (Index) — Estructura que acelera búsquedas sobre columnas.
Normalización — Proceso de diseñar tablas para reducir redundancia y mejorar integridad.
Transacción — Conjunto de operaciones que se ejecutan de forma atómica (ACID).

Ejemplo de creación de tabla:

CREATE TABLE usuarios (
    id INT PRIMARY KEY AUTO_INCREMENT,
    nombre VARCHAR(50),
    correo VARCHAR(100),
    contraseña VARCHAR(100)
);

Estructura y Diseño

Normalización: aplicar formas normales (1FN, 2FN, 3FN...) para evitar datos redundantes y anomalías de actualización.
Desnormalización: a veces usada por motivos de rendimiento en consultas analíticas o sistemas OLAP.
Constraints (Restricciones): NOT NULL, UNIQUE, CHECK, FOREIGN KEY para mantener la integridad referencial.
Índices: deben diseñarse con cuidado; ayudan a acelerar SELECT pero pueden ralentizar INSERT/UPDATE/DELETE.
Particionamiento y Sharding: técnicas para distribuir datos en varias unidades físicas para escalabilidad.
Backups y recuperación: estrategias (completos, incrementales, logs de transacción) y pruebas periódicas de restauración.

Consultas SQL Básicas

SELECT: Utilizado para consultar información dentro de una base de datos.

SELECT * FROM usuarios;

INSERT: Añade nuevos registros a una tabla.

INSERT INTO usuarios (nombre, correo, contraseña)
VALUES ('user', 'user@darfe.es', 'clave123');

UPDATE: Modifica registros existentes.

UPDATE usuarios
SET contraseña = 'claveNueva'
WHERE nombre = 'Darfe';

DELETE: Elimina registros de una tabla.

DELETE FROM usuarios WHERE id = 3;

Operaciones Avanzadas

JOINs: INNER JOIN, LEFT/RIGHT JOIN, FULL OUTER JOIN para combinar datos de varias tablas.
Subconsultas: consultas dentro de otras consultas para operaciones complejas.
Funciones de agregación: COUNT(), SUM(), AVG(), MIN(), MAX() y GROUP BY para resúmenes.
Views (Vistas): consultas guardadas que simplifican acceso y encapsulan lógica.
Stored Procedures y Triggers: lógica almacenada en la BD — cuidado con la complejidad y permisos.
Optimización de consultas: EXPLAIN/EXPLAIN ANALYZE para revisar planes de ejecución y refinar índices.

Seguridad y Buenas Prácticas

Validación de entradas: Evita la inyección SQL usando consultas preparadas y validación estricta de tipos y longitudes.
Principio de menor privilegio: Las cuentas que acceden a la BD deben tener solo los permisos necesarios (no usar root/sa en la app).
Cifrado: Almacenar contraseñas usando hash con sal (por ejemplo, bcrypt o Argon2). No almacenar contraseñas en texto plano.
Auditoría y logging: Monitorear accesos, cambios en esquemas y operaciones en tablas sensibles.
Configuración segura: Deshabilitar funciones innecesarias, aplicar parches y mantener la BD actualizada.
Seguridad de red: Aislar la infraestructura de BD en segmentos privados, usar TLS/SSL para conexiones y VPNs cuando corresponda.
Pruebas regulares: Integrar escaneos de seguridad y pruebas de penetración en el ciclo de desarrollo.

Inyección SQL (tema desarrollado)

Definición

La inyección SQL (SQL Injection) es una vulnerabilidad que permite a un atacante insertar, manipular o alterar consultas SQL construidas dinámicamente por una aplicación. Sucede cuando datos controlados por el usuario se incorporan directamente en una consulta sin separación clara entre código y datos.

Ejemplo representativo

' OR '1'='1

Si esta cadena se concatena en una consulta de autenticación sin protección, la condición lógica puede resultar siempre verdadera y permitir acceso no autorizado. Este ejemplo se usa para ilustrar el concepto; la exposición real siempre depende del contexto de la consulta y del tratamiento que haga la aplicación de la entrada.

Tipos comunes de inyección (visión general)

Basada en errores (Error-based): El atacante provoca errores que pueden revelar información sobre la estructura de la BD.
Basada en booleanos (Boolean-based / Blind): El atacante envía consultas que devuelven true/false y deduce información a partir de la respuesta de la aplicación.
Basada en tiempo (Time-based / Blind): Se inyectan operaciones que tardan en ejecutarse para inferir datos según la latencia observada.
UNION-based: Combinar resultados de consultas adicionales usando UNION para extraer datos.
Stacked queries (consultas apiladas): Ejecutar múltiples sentencias en una sola petición (no soportado por todas las BD o APIs).

> Nota: aquí no se proporcionan payloads avanzados ni instrucciones para explotar sistemas — el objetivo es entender los vectores para diseñar defensas efectivas.

Indicadores y detección

Comportamiento inesperado en formularios (logins, búsquedas).
Mensajes de error SQL reveladores en la interfaz (evitar mostrarlos a usuarios).
Respuestas distintas al introducir caracteres especiales (' " ; -- /*).
Auditoría que muestra consultas construidas dinámicamente con concatenación de inputs.
Pruebas automatizadas y herramientas de escaneo (SAST/DAST) que señalan puntos de inyección.

Consecuencias potenciales

Acceso no autorizado a datos sensibles (usuarios, contraseñas, registros financieros).
Exfiltración masiva de datos.
Alteración o borrado de información crítica.
Escalada de privilegios o ejecución de código si la BD o entorno lo permite.
Compromiso del sistema completo si la aplicación y la BD están integradas sin separación.

Prevención y mitigación (prácticas recomendadas)

1. Mantener separación entre código y datos

Consultas preparadas / parámetros enlazados (prepared statements): la forma más efectiva de evitar que la entrada del usuario sea interpretada como código SQL.

Ejemplo en PHP (PDO):

$stmt = $pdo->prepare('SELECT * FROM usuarios WHERE correo = ? AND contraseña = ?');
$stmt->execute([$correo, $hash]);
$result = $stmt->fetch();

Ejemplo en Python (psycopg2):

cur.execute("SELECT * FROM usuarios WHERE correo = %s AND contraseña = %s", (correo, hash))

2. Validación y saneamiento

Validar tipo, longitud, formato (ej. emails, números, fechas) antes de procesar.
Rechazar o normalizar entradas inesperadas.
Evitar la construcción dinámica de SQL con concatenación de strings.

3. Principio de menor privilegio

La cuenta que usa la aplicación para conectarse debe tener permisos mínimos (por ejemplo SELECT/INSERT/UPDATE en tablas necesarias, sin DROP ni DDL excesivo).

4. Uso de ORMs con cuidado

Los ORMs suelen parametrizar consultas correctamente, pero el uso de consultas «raw» o concatenadas puede introducir riesgos. Revisar y auditar el código que construye SQL manualmente.

5. Manejo seguro de errores y mensajes

No mostrar trazas o errores SQL al usuario. Registrar internamente la información suficiente para investigar sin exponer estructura ni datos.

6. Registro, monitoreo y respuesta

Implementar alertas ante patrones sospechosos (picos de errores, inputs raros).
Mantener logs de consultas y accesos para análisis forense.

7. Controles adicionales

Web Application Firewall (WAF) como capa adicional — útil pero no sustituye buenas prácticas de codificación.
Hardening y parches de la BD y del servidor de aplicaciones.
Revisión de código y pruebas de seguridad (pentests, fuzzing) periódicas.

Ejemplos de corrección (antes / después)

Código vulnerable (no usar):

$sql = "SELECT * FROM usuarios WHERE correo = '" . $_POST['correo'] . "' AND contraseña = '" . $_POST['pass'] . "'";

Corrección con prepared statement (recomendada):

$stmt = $pdo->prepare("SELECT * FROM usuarios WHERE correo = :correo AND contraseña = :pass");
$stmt->bindParam(':correo', $_POST['correo']);
$stmt->bindParam(':pass', $hash);
$stmt->execute();

Respuesta ante un incidente

1. Contener: desactivar vectores afectados (ej. endpoints vulnerables), cambiar credenciales si fuera necesario.

2. Analizar logs para identificar alcance y vectores.

3. Restaurar desde backups conocidas si hay pérdida o corrupción de datos.

4. Corregir la vulnerabilidad (parche, refactorización de consultas) y ejecutar pruebas.

5. Notificar a las partes afectadas según normativa/Política de divulgación y cumplimiento legal.

Recursos y pruebas seguras

Usar entornos de laboratorio aislados (no en producción) para practicar detección/mitigación.
Emplear herramientas de seguridad para evaluar de forma controlada (sólo en sistemas de prueba o con autorización explícita).

Referencias rápidas

Aprender SQL es clave para desarrollar con seguridad: entender cómo se construyen consultas permite tanto optimizar rendimiento como prevenir fallos de seguridad.
Revisar siempre los puntos del código que generan SQL dinámico y tratarlos como zonas críticas de seguridad.

Bibliografía

Fundamentos de SQL - Andy Oppel Robert Sheldon

MySQL - Wikipedia

index.php?title=Categoría:Bases de datos