CiberWiki - Contribuciones del usuario [es]

SQLite

2026-04-16T22:43:47Z

Warid.F:

= SQLite =

'''SQLite''' es un sistema de gestión de bases de datos relacional (RDBMS) ligero, embebido y sin servidor, implementado como una biblioteca en C. Fue creado por D. Richard Hipp en el año 2000 y es de dominio público.

A diferencia de otros motores como MySQL o PostgreSQL, SQLite no utiliza arquitectura cliente-servidor, sino que funciona directamente dentro de la aplicación que lo usa.

== Características ==

* '''Sin servidor (serverless)''': no requiere instalación ni configuración de un servicio.
* '''Archivo único''': la base de datos completa se almacena en un solo archivo.
* '''Ligero''': tamaño muy reducido.
* '''Portable''': funciona en múltiples sistemas operativos sin cambios.
* '''ACID''': garantiza atomicidad, consistencia, aislamiento y durabilidad.
* '''Embebido''': se integra directamente en la aplicación.
* '''Transaccional''': soporta transacciones completas.
* '''Multiplataforma''': Windows, Linux, macOS, Android, iOS.

== Arquitectura ==

SQLite no sigue el modelo cliente-servidor:

* La aplicación accede directamente al archivo de base de datos.
* No hay procesos en segundo plano.
* Todo se maneja mediante llamadas a la biblioteca SQLite.

== Funcionamiento ==

SQLite ejecuta sentencias SQL estándar sobre un archivo local.

Operaciones principales:

* <code>CREATE</code>
* <code>INSERT</code>
* <code>SELECT</code>
* <code>UPDATE</code>
* <code>DELETE</code>

Ejemplo:

<syntaxhighlight lang="sql">
CREATE TABLE usuarios (
id INTEGER PRIMARY KEY,
nombre TEXT,
edad INTEGER
);

INSERT INTO usuarios (nombre, edad)
VALUES ('Juan', 25);

SELECT * FROM usuarios;
</syntaxhighlight>

== Tipos de datos ==

SQLite usa tipado dinámico. Tipos principales:

* '''NULL'''
* '''INTEGER'''
* '''REAL'''
* '''TEXT'''
* '''BLOB'''

== Ventajas ==

* No requiere instalación
* Muy rápido en local
* Bajo consumo de recursos
* Fácil de transportar
* Ideal para apps pequeñas o embebidas

== Desventajas ==

* Concurrencia limitada
* No escala bien a sistemas grandes
* Sin gestión avanzada de usuarios
* Bloqueo de escritura a nivel de archivo

== Casos de uso ==

* Aplicaciones móviles
* Software de escritorio
* Sistemas embebidos / IoT
* Navegadores
* Prototipos

== Comparación ==

{| class="wikitable"
! Característica !! SQLite !! PostgreSQL / MySQL
|-
| Arquitectura || Embebida || Cliente-servidor
|-
| Instalación || No || Sí
|-
| Escalabilidad || Baja || Alta
|-
| Concurrencia || Limitada || Alta
|}

== Comandos útiles ==

* <code>.open archivo.db</code>
* <code>.tables</code>
* <code>.schema</code>
* <code>.exit</code>

== Seguridad ==

SQLite no tiene autenticación interna. Depende de:

* Permisos del sistema operativo
* Encriptación externa (ej: SQLCipher)

== Licencia ==

Dominio público. Uso libre sin restricciones.

SQLite

2026-04-16T22:42:22Z

Warid.F: Página creada con «<nowiki>#</nowiki> SQLite <nowiki>**</nowiki>SQLite** es un sistema de gestión de bases de datos relacional (RDBMS) ligero, embebido y sin servidor, implementado como una biblioteca en C. Fue creado por D. Richard Hipp en el año 2000 y es de dominio público. A diferencia de otros motores como MySQL o PostgreSQL, SQLite no utiliza arquitectura cliente-servidor, sino que funciona directamente dentro de la aplicación que lo usa. --- <nowiki>##</nowiki> Caracterí…»

<nowiki>#</nowiki> SQLite

<nowiki>**</nowiki>SQLite** es un sistema de gestión de bases de datos relacional (RDBMS) ligero, embebido y sin servidor, implementado como una biblioteca en C. Fue creado por D. Richard Hipp en el año 2000 y es de dominio público.

A diferencia de otros motores como MySQL o PostgreSQL, SQLite no utiliza arquitectura cliente-servidor, sino que funciona directamente dentro de la aplicación que lo usa.

---

<nowiki>##</nowiki> Características

- **Sin servidor (serverless)**: no requiere instalación ni configuración de un servicio.

- **Archivo único**: la base de datos completa se almacena en un solo archivo.

- **Ligero**: tamaño muy reducido.

- **Portable**: funciona en múltiples sistemas operativos sin cambios.

- **ACID**: garantiza atomicidad, consistencia, aislamiento y durabilidad.

- **Embebido**: se integra directamente en la aplicación.

- **Transaccional**: soporta transacciones completas.

- **Multiplataforma**: Windows, Linux, macOS, Android, iOS.

---

<nowiki>##</nowiki> Arquitectura

SQLite no sigue el modelo cliente-servidor:

- La aplicación accede directamente al archivo de base de datos.

- No hay procesos en segundo plano.

- Todo se maneja mediante llamadas a la biblioteca SQLite.

---

<nowiki>##</nowiki> Funcionamiento

SQLite ejecuta sentencias SQL estándar sobre un archivo local.

Operaciones principales:

- `CREATE`

- `INSERT`

- `SELECT`

- `UPDATE`

- `DELETE`

Ejemplo:

```sql

CREATE TABLE usuarios (

id INTEGER PRIMARY KEY,

nombre TEXT,

edad INTEGER

);

INSERT INTO usuarios (nombre, edad)

VALUES ('Juan', 25);

SELECT * FROM usuarios;

```

---

<nowiki>##</nowiki> Tipos de datos

SQLite usa tipado dinámico. Tipos principales:

- **NULL**

- **INTEGER**

- **REAL**

- **TEXT**

- **BLOB**

---

<nowiki>##</nowiki> Ventajas

- No requiere instalación

- Muy rápido en local

- Bajo consumo de recursos

- Fácil de transportar

- Ideal para apps pequeñas o embebidas

---

<nowiki>##</nowiki> Desventajas

- Concurrencia limitada

- No escala bien a sistemas grandes

- Sin gestión avanzada de usuarios

- Bloqueo de escritura a nivel de archivo

---

<nowiki>##</nowiki> Casos de uso

- Aplicaciones móviles

- Software de escritorio

- Sistemas embebidos / IoT

- Navegadores

- Prototipos

---

<nowiki>##</nowiki> Comparación

| Característica | SQLite | PostgreSQL / MySQL |

|--------------|--------|--------------------|

| Arquitectura | Embebida | Cliente-servidor |

| Instalación | No | Sí |

| Escalabilidad | Baja | Alta |

| Concurrencia | Limitada | Alta |

---

<nowiki>##</nowiki> Comandos útiles

- `.open archivo.db`

- `.tables`

- `.schema`

- `.exit`

---

<nowiki>##</nowiki> Seguridad

SQLite no tiene autenticación interna. Depende de:

- Permisos del sistema operativo

- Encriptación externa (ej: SQLCipher)

---

<nowiki>##</nowiki> Licencia

Dominio público. Uso libre sin restricciones.

Postgres

2025-11-11T18:34:39Z

Warid.F: Extensión de contenido

[[File:Logo PostgreSQL.png|thumb|right|200px|https://www.postgresql.org/]]

'''PostgreSQL''' o también llamado '''Postgres''' es un potente sistema de base de datos objeto-relacional de código abierto con más de 35 años de desarrollo activo que le ha valido una sólida reputación por su fiabilidad, robustez de características y rendimiento.

Existe una gran cantidad de información que describe cómo instalar y utilizar PostgreSQL a través de la documentación oficial. La comunidad de código abierto proporciona muchos lugares útiles para familiarizarse con PostgreSQL, descubrir cómo funciona y encontrar oportunidades de carrera.

= PostgreSQL en Ciberseguridad =

'''PostgreSQL''' es un sistema de gestión de bases de datos relacional y orientado a objetos (ORDBMS) ampliamente utilizado en entornos donde la integridad, el rendimiento y la seguridad son fundamentales.

Su diseño modular, su enfoque en el cumplimiento de estándares y la capacidad de extenderlo con módulos personalizados lo convierten en una base sólida para proyectos de seguridad ofensiva y defensiva.

== Arquitectura general ==

PostgreSQL se basa en una arquitectura cliente-servidor, donde cada conexión activa se maneja mediante un proceso independiente. El motor principal gestiona la concurrencia, el almacenamiento y la recuperación mediante un mecanismo de registro previo de escritura (Write Ahead Logging, WAL), que garantiza la consistencia incluso ante fallos del sistema.

<pre style="color: blue">
# Estructura simplificada de PostgreSQL
- postmaster (proceso principal)
- backend processes (uno por conexión)
- wal writer (manejo de transacciones)
- bgwriter (escritura en segundo plano)
- autovacuum launcher (mantenimiento automático)
</pre>

Este diseño multiproceso, en lugar de multihilo, ofrece un aislamiento más seguro entre sesiones y reduce el riesgo de corrupción de memoria compartida, algo esencial en entornos con múltiples usuarios o scripts automatizados.

== Seguridad interna ==

PostgreSQL incorpora múltiples capas de seguridad:
* '''Autenticación múltiple:''' admite contraseñas, certificados SSL, GSSAPI, LDAP y autenticación por IP.
* '''Control de acceso granular:''' a través de roles, herencia de privilegios y políticas de seguridad a nivel de fila (RLS - Row Level Security).
* '''Cifrado:''' soporte nativo de SSL/TLS y posibilidad de cifrar datos sensibles mediante extensiones como `pgcrypto`.
* '''Auditoría:''' integración con `pgaudit` para registrar eventos de autenticación, consultas y operaciones críticas.

<pre style="color: blue">
-- Ejemplo: activación de seguridad por fila
ALTER TABLE registros ENABLE ROW LEVEL SECURITY;
CREATE POLICY solo_propietario ON registros
USING (usuario = current_user);
</pre>

Esto garantiza que incluso un atacante con acceso parcial a la base no pueda ver datos pertenecientes a otros usuarios, aplicando aislamiento lógico dentro del propio SGBD.

== Extensibilidad y automatización ==

Una de las mayores fortalezas de PostgreSQL es su capacidad de extenderse.
Permite crear:
* Funciones en múltiples lenguajes (SQL, PL/pgSQL, Python, C, Perl, etc.).
* Tipos de datos definidos por el usuario.
* Módulos personalizados para cifrado, auditoría o análisis.

Esto lo hace ideal para sistemas de detección, correlación de logs o sandboxing de datos sensibles.

Ejemplo de función definida en Python:

<pre style="color: blue">
CREATE FUNCTION hash_password(pwd TEXT)
RETURNS TEXT AS $$
import hashlib
return hashlib.sha256(pwd.encode()).hexdigest()
$$ LANGUAGE plpython3u;
</pre>

== Rendimiento y mantenimiento ==

PostgreSQL implementa estrategias de optimización como:
* '''VACUUM''' y '''AUTOVACUUM''' para limpiar registros muertos.
* '''Query planner''' avanzado con índices B-tree, Hash, GIN y GiST.
* '''Particionamiento nativo''' y replicación lógica.

Estas capacidades permiten mantener grandes volúmenes de información sin degradación significativa, lo que lo hace apto para entornos donde se procesan logs, registros de red o métricas de seguridad en tiempo real.

== PostgreSQL frente a SQL estándar ==

Mientras que SQL describe el lenguaje y las reglas básicas de manipulación de datos, PostgreSQL representa una implementación que '''trasciende el estándar'''. SQL define el “qué”, pero PostgreSQL define el “cómo” con:
* Mayor cumplimiento y extensión del estándar ANSI.
* Seguridad interna granular (RLS, roles jerárquicos).
* Mecanismos avanzados de recuperación (WAL).
* Modularidad y extensibilidad a bajo nivel.
* Integración nativa con lenguajes de scripting.

En resumen, SQL es el lenguaje, PostgreSQL es la '''plataforma'''. Un experto en ciberseguridad que domine PostgreSQL no solo entiende consultas, sino también políticas, cifrado y auditoría a nivel estructural.
[[Categoría:Bases de datos]]

NoSQL

2025-11-01T14:31:48Z

Warid.F: Arreglo de categoria

= NoSQL =
'''NoSQL''' (''Not Only SQL'') es un conjunto de sistemas de gestión de '''BD''' (bases de datos) diseñados para manejar grandes volúmenes de datos no estructurados o semiestructurados. A diferencia de los sistemas basados en '''SQL''', los motores NoSQL no dependen de un esquema rígido de tablas y relaciones, lo que les otorga mayor flexibilidad, escalabilidad y rendimiento en entornos distribuidos.

En el ámbito de la '''seguridad''', comprender el funcionamiento de NoSQL es crucial para proteger ''apps'', ''srv'' y ''API'' modernas que utilizan bases de datos no relacionales.

== Características principales ==

* '''Sin esquema fijo:''' Los datos pueden almacenarse en distintos formatos (documentos, grafos, pares clave-valor o columnas).
* '''Escalabilidad horizontal:''' Los datos se distribuyen entre múltiples ''srv'' o nodos, favoreciendo la expansión del sistema sin pérdida de rendimiento.
* '''Alto rendimiento:''' Optimizado para operaciones de lectura/escritura masiva y consultas en tiempo real.
* '''Alta disponibilidad (HA):''' Mediante replicación y redundancia entre nodos.
* '''Flexibilidad:''' Ideal para ''apps'' con estructuras dinámicas y datos cambiantes.

== Tipos de BD NoSQL ==

===== 1. Clave-Valor =====

* Almacenan información como pares de '''clave → valor'''.
* Ideales para ''cache'', sesiones de ''usr'' o ''cfg'' temporales.
* Ejemplos: '''Redis''', '''Riak''', '''Amazon DynamoDB'''.
<pre style="color: blue">
SET usr:1 "Darfe"
GET usr:1
</pre>

===== 2. Documentales =====

* Los datos se almacenan en documentos tipo '''JSON''' o '''BSON'''.
* Permiten consultas complejas sin esquema predefinido.
* Usadas en ''apps'' web, móviles y ''microservicios''.
* Ejemplos: '''MongoDB''', '''CouchDB''', '''Firestore'''.
<pre style="color: blue">
{
"_id": 1,
"nombre": "Darfe",
"correo": "user@darfe.es",
"rol": "admin"
}
</pre>

===== 3. Columnar =====

* Organizan la información por columnas en lugar de filas.
* Son ideales para análisis de datos y consultas masivas.
* Ejemplos: '''Cassandra''', '''HBase''', '''ScyllaDB'''.
<pre style="color: blue">
CREATE TABLE usuarios (
id UUID PRIMARY KEY,
nombre TEXT,
edad INT
);
</pre>

===== 4. Grafos =====

* Representan relaciones mediante nodos (entidades) y aristas (enlaces).
* Ideales para ''apps'' de redes sociales, análisis de relaciones o motores de recomendación.
* Ejemplos: '''Neo4j''', '''ArangoDB''', '''OrientDB'''.
<pre style="color: blue">
CREATE (a:Usuario {nombre: "Darfe"})-[:SIGUE]->(b:Usuario {nombre: "Lía"})
</pre>

== Ventajas y Desventajas ==
'''Ventajas:'''

* Escalabilidad masiva y alta disponibilidad.
* Flexibilidad en el diseño de datos.
* Ideal para sistemas distribuidos y de alta concurrencia.

'''Desventajas:'''

* Falta de estandarización (cada motor usa su propia sintaxis o API).
* Pérdida parcial de las propiedades ACID.
* Complejidad en la replicación y la ''seguridad'' avanzada.

== Seguridad y Buenas Prácticas ==

* '''Validación de entradas:''' Evitar inyecciones NoSQL limitando los operadores permitidos.
* '''Control de permisos:''' Asignar privilegios mínimos a los ''usr'' y ''srv'' de base de datos.
* '''Autenticación y cifrado:''' Activar TLS y autenticación obligatoria.
* '''Auditoría constante:''' Monitorear accesos y operaciones críticas.
* '''Evitar exposición pública:''' No dejar puertos abiertos sin control (ej. :27017 en MongoDB).

== Inyección NoSQL ==
Una '''inyección NoSQL''' ocurre cuando un atacante manipula una consulta construida dinámicamente (por ejemplo, en formato JSON), logrando acceder o modificar datos sin autorización.

Ejemplo de vulnerabilidad:<pre style="color: red">
{
"usr": {"$ne": null},
"pass": {"$ne": null}
}
</pre>Esto fuerza la coincidencia de cualquier registro, permitiendo acceso no autorizado.

'''Prevención:'''

* Usar consultas parametrizadas o funciones de validación seguras.
* Sanitizar la entrada del ''usr'' y rechazar operadores como `$ne`, `$gt`, `$where`.
* Aplicar autenticación robusta y limitar las respuestas de error.

== Conclusión ==
NoSQL representa una evolución hacia sistemas más adaptables, distribuidos y escalables. Sin embargo, su potencia requiere una gestión cuidadosa en cuanto a configuración, permisos y seguridad de datos para evitar brechas críticas en entornos modernos de '''seguridad.'''
[[Categoría:Bases de datos]]

NoSQL

2025-11-01T14:25:34Z

Warid.F: Página creada con «= NoSQL = '''NoSQL''' (''Not Only SQL'') es un conjunto de sistemas de gestión de '''BD''' (bases de datos) diseñados para manejar grandes volúmenes de datos no estructurados o semiestructurados. A diferencia de los sistemas basados en '''SQL''', los motores NoSQL no dependen de un esquema rígido de tablas y relaciones, lo que les otorga mayor flexibilidad, escalabilidad y rendimiento en entornos distribuidos. En el ámbito de la '''seguridad''', comprender el f…»

SQL

2025-10-28T21:03:37Z

Warid.F:

'''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:<pre style="color: blue">
CREATE TABLE usuarios (
id INT PRIMARY KEY AUTO_INCREMENT,
nombre VARCHAR(50),
correo VARCHAR(100),
contraseña VARCHAR(100)
);
</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 ==

; SELECT
: Utilizado para consultar información dentro de una base de datos.
<pre style="color: blue">
SELECT * FROM usuarios;
</pre>

; INSERT
: Añade nuevos registros a una tabla.
<pre style="color: blue">
INSERT INTO usuarios (nombre, correo, contraseña)
VALUES ('user', 'user@darfe.es', 'clave123');

</pre>

; UPDATE
: Modifica registros existentes.
<pre style="color: blue">
UPDATE usuarios
SET contraseña = 'claveNueva'
WHERE nombre = 'Darfe';

</pre>

; DELETE
: Elimina registros de una tabla.
<pre style="color: red">
DELETE FROM usuarios WHERE id = 3;
</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 ==

* '''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 ===
<pre style="color: red">
' OR '1'='1
</pre>
*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):
<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>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):
<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.

== Bibliografía ==
[https://pedrobeltrancanessa-biblioteca.weebly.com/uploads/1/2/4/0/12405072/fundamentos_de_sql_3edi_oppel.pdf Fundamentos de SQL - Andy Oppel Robert Sheldon]

[https://es.wikipedia.org/wiki/MySQL MySQL - Wikipedia]

[[Categoría:Bases de datos]]

TCP/IP

2025-10-28T20:46:46Z

Warid.F:

[[File:Modelo capas-OSI y TCP-IP.jpg|thumb|Modelo capas-OSI y TCP-IP|right|200px]]
El '''modelo TCP/IP''' es considerado un '''estándar de comunicación''' ampliamente adoptado en el ámbito de las redes informáticas. Su función principal es '''definir el procedimiento mediante el cual los datos generados en el origen son transmitidos, entregados y comprendidos correctamente en el destino'''.

Para lograrlo, el modelo hace uso de '''diversos protocolos''', que pueden operar '''de forma simultánea o individual''', cada uno con '''una función específica y un rol bien definido''' dentro del proceso de comunicación.

Una forma sencilla de comprender el funcionamiento del modelo TCP/IP —comúnmente utilizada en la literatura técnica— es '''compararlo con una red telefónica'''.

Por ejemplo:

Si reemplazamos un teléfono celular antiguo por uno más reciente, '''no tendríamos inconvenientes al comunicarnos''' dentro de la red. No sería necesario realizar configuraciones complejas ni reconstruir toda la infraestructura de comunicación, ya que ambos dispositivos —el viejo y el nuevo— '''emplean los mismos protocolos y estándares globales de transmisión'''.

Esta '''uniformidad en los protocolos''' es precisamente lo que '''evita la obsolescencia tecnológica''' en la comunicación básica, permitiendo que '''nuevos dispositivos sean compatibles con las redes existentes''', siempre que respeten las mismas normas y estándares definidos por el modelo TCP/IP.[[File:Portada_del_libro_Seguridad_por_Niveles.jpg|left|120px|thumb|Portada del libro]]
Este tema lo encontrarás ampliamente desarrollado en el "CAPÍTULO 1: Introducción" de nuestro libro <b>[[Seguridad por Niveles]]</b> (que puedes descargar gratuitamente de nuestra web: https://darfe.es).
<br>
<br>
Muchas de las imágenes y explicaciones, también las podrás encontrar en [[Wikipedia]] en el siguiente enlace:

https://es.wikipedia.org/wiki/Familia_de_protocolos_de_internet

{| class="wikitable"
|+ Tenemos un video qu epuede ser de tu interés sobre este tema
|-
! Nombre del video !! Enlace
|-
| TCP/IP usando Wireshark||<youtube width="130" height="60">Moe5Mj_Wo5w</youtube>
|}
[[Categoría:Nivel de Transporte]]

SQL

2025-10-28T20:39:37Z

Warid.F: Adicion de informacion, protocolo de respuesta, ejemplo de errores y referencias. Nota: La corrección de puntuacion esta hecho por IA

= 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:<pre style="color: blue">
CREATE TABLE usuarios (
id INT PRIMARY KEY AUTO_INCREMENT,
nombre VARCHAR(50),
correo VARCHAR(100),
contraseña VARCHAR(100)
);
</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 ==

; SELECT
: Utilizado para consultar información dentro de una base de datos.
<pre style="color: blue">
SELECT * FROM usuarios;
</pre>

; INSERT
: Añade nuevos registros a una tabla.
<pre style="color: blue">
INSERT INTO usuarios (nombre, correo, contraseña)
VALUES ('user', 'user@darfe.es', 'clave123');

</pre>

; UPDATE
: Modifica registros existentes.
<pre style="color: blue">
UPDATE usuarios
SET contraseña = 'claveNueva'
WHERE nombre = 'Darfe';

</pre>

; DELETE
: Elimina registros de una tabla.
<pre style="color: red">
DELETE FROM usuarios WHERE id = 3;
</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 ==

* '''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 ===
<pre style="color: red">
' OR '1'='1
</pre>
*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):
<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>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):
<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.

== Bibliografía ==
[https://pedrobeltrancanessa-biblioteca.weebly.com/uploads/1/2/4/0/12405072/fundamentos_de_sql_3edi_oppel.pdf Fundamentos de SQL - Andy Oppel Robert Sheldon]

[https://es.wikipedia.org/wiki/MySQL MySQL - Wikipedia]

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

SQL

2025-10-28T20:27:18Z

Warid.F:

= 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:<pre style="color: blue">
CREATE TABLE usuarios (
id INT PRIMARY KEY AUTO_INCREMENT,
nombre VARCHAR(50),
correo VARCHAR(100),
contraseña VARCHAR(100)
);
</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 ==

; SELECT
: Utilizado para consultar información dentro de una base de datos.
<pre style="color: blue">
SELECT * FROM usuarios;
</pre>

; INSERT
: Añade nuevos registros a una tabla.
<pre style="color: blue">
INSERT INTO usuarios (nombre, correo, contraseña)
VALUES ('user', 'user@darfe.es', 'clave123');

</pre>

; UPDATE
: Modifica registros existentes.
<pre style="color: blue">
UPDATE usuarios
SET contraseña = 'claveNueva'
WHERE nombre = 'Darfe';

</pre>

; DELETE
: Elimina registros de una tabla.
<pre style="color: red">
DELETE FROM usuarios WHERE id = 3;
</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 ==

* '''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 ===
<pre style="color: red">
' OR '1'='1
</pre>
*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]]

Categoría:Bases de datos

2025-10-28T20:13:12Z

Warid.F: Adición de resumen de la categoria

Una '''base de datos (BD)''' es un sistema organizado para '''almacenar, gestionar y recuperar información''' de manera eficiente. Permite que múltiples usuarios o aplicaciones accedan a los datos de forma estructurada y segura.

TCP/IP

2025-10-28T19:49:14Z

Warid.F:

SQL

2025-10-28T02:05:51Z

Warid.F:

SQL

2025-10-28T02:04:55Z

Warid.F: Creacion del apartado SQL

Categoría:Bases de datos

2025-10-28T01:56:29Z

Warid.F: Página creada con «Bases de Datos»

Bases de Datos