Ir al contenido

Diferencia entre revisiones de «SQL»

SQL (ver código)

Revisión del 20:27 28 oct 2025

9500 bytes añadidos ,  28 oct 2025
sin resumen de edición
VisualWikitexto
Sin resumen de edición
Sin resumen de edición
Línea 1: Línea 1:
= SQL =
= 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.
'''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 ==
== Conceptos Fundamentales ==
Línea 9: Línea 36:
* ''Registro (Row)'' — Una entrada individual dentro de una tabla.
* ''Registro (Row)'' — Una entrada individual dentro de una tabla.
* ''Campo (Field)'' — Un atributo específico 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:<pre style="color: blue">
Ejemplo de creación de tabla:<pre style="color: blue">
Línea 18: Línea 49:
);
);
</pre>
</pre>
== 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 ==
== Consultas SQL Básicas ==
Línea 49: Línea 89:
DELETE FROM usuarios WHERE id = 3;
DELETE FROM usuarios WHERE id = 3;
</pre>
</pre>
== 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 ==
== Seguridad y Buenas Prácticas ==


* '''Validación de entradas:''' Evita la inyección SQL usando consultas preparadas.
* '''Validación de entradas:''' Evita la inyección SQL usando consultas preparadas y validación estricta de tipos y longitudes.
* '''Principio de menor privilegio:''' Los usuarios de base de datos deben tener solo los permisos necesarios.
* '''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:''' Almacena contraseñas usando hash (por ejemplo, bcrypt o Argon2).
* '''Cifrado:''' Almacenar contraseñas usando hash con sal (por ejemplo, bcrypt o Argon2). No almacenar contraseñas en texto plano.
* '''Auditoría:''' Monitorea los accesos y modificaciones en tablas sensibles.
* '''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) ==


Ejemplo de inyección SQL maliciosa:<pre style="color: red">
=== 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 ===
<pre style="color: red">
' OR '1'='1
' OR '1'='1
</pre>
</pre>
[[Categoría:Bases de datos]]
*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) ===
 
# 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):
<pre style="color: blue">
$stmt = $pdo->prepare('SELECT * FROM usuarios WHERE correo = ? AND contraseña = ?');
$stmt->execute([$correo, $hash]);
$result = $stmt->fetch();
</pre>
 
Ejemplo en Python (psycopg2):
<pre style="color: blue">
cur.execute("SELECT * FROM usuarios WHERE correo = %s AND contraseña = %s", (correo, hash))
</pre>
 
# 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.
 
# 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).
 
# 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.
 
# 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.
 
# Registro, monitoreo y respuesta
* Implementar alertas ante patrones sospechosos (picos de errores, inputs raros).
* Mantener logs de consultas y accesos para análisis forense.
 
# 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):*
<pre style="color: red">
$sql = "SELECT * FROM usuarios WHERE correo = '" . $_POST['correo'] . "' AND contraseña = '" . $_POST['pass'] . "'";
</pre>
 
*Corrección con prepared statement (recomendada):*
<pre style="color: blue">
$stmt = $pdo->prepare("SELECT * FROM usuarios WHERE correo = :correo AND contraseña = :pass");
$stmt->bindParam(':correo', $_POST['correo']);
$stmt->bindParam(':pass', $hash);
$stmt->execute();
</pre>
 
=== 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.
 
[[index.php?title=Categoría:Bases de datos]]
Warid.F
14

ediciones

Obtenido de «https://darfe.es/ciberwiki/index.php?title=Especial:MobileDiff/2623»