El Proyecto | Sobre nosotros | Contribuir | Donaciones | Licencia

HOME

Las ocho lecciones anteriores fueron de prevención: cerrar puertas antes de que alguien las cruce. Pero ninguna prevención es total. A09:2021 – Fallos de Registro y Monitorización (Security Logging and Monitoring Failures) —antes "Registro y Monitoreo Insuficientes"— aborda qué pasa cuando algo se cuela: ¿lo detectamos?, ¿en cuánto tiempo?, ¿podemos investigar qué ocurrió? La estadística es demoledora: muchas brechas tardan meses en detectarse, y a menudo el aviso llega de fuera (un tercero, la prensa) en lugar de los propios sistemas.

Esta categoría es transversal: es la que convierte todos los "eventos de seguridad" que hemos ido mencionando (fallos de control de acceso en A01, intentos de login en A07, XML con DTD en XXE...) en señales accionables. En BazarNube revisaremos el logging de la API Express: qué registrar, qué nunca registrar (datos sensibles), cómo detectar y alertar. Esta lección conecta directamente con el caso de estudio de análisis de incidente del módulo 8 (08-03), donde usaremos estos logs para reconstruir un ataque.

Aviso legal y ético: los ejemplos son ilustrativos y con datos ficticios. Al registrar eventos de personas reales, cumple la normativa de protección de datos aplicable. Practica solo sobre sistemas propios o con autorización explícita.

Contenido

Por qué el registro y la monitorización son seguridad
Qué eventos de seguridad registrar
Qué NO registrar: datos sensibles
Cómo registrar bien: formato, contexto y correlación
De los logs a la detección: alertas y respuesta
Integridad y retención de los logs
Errores comunes, ejercicios y soluciones

Por qué el registro y la monitorización son seguridad

Sin registro no hay detección (no ves el ataque en curso), ni respuesta (no sabes qué contener), ni análisis forense (no puedes reconstruir qué pasó), ni evidencia (para requisitos legales/regulatorios). Un buen sistema de logging reduce el tiempo de detección de meses a minutos y es la diferencia entre "contuvimos el incidente" y "nos enteramos por los titulares".

Qué eventos de seguridad registrar

La API de BazarNube apenas registraba nada relevante para seguridad:

// VULNERABLE por omision: no hay traza de eventos de seguridad
router.post('/api/login', async (req, res) => {
  const u = await getUser(req.body.email);
  if (u && await verifyPassword(req.body.password, u.pwd)) {
    req.session.userId = u.id;
    return res.json({ ok: true });
  }
  res.status(401).json({ error: 'Credenciales invalidas' }); // fallo silencioso
});

Si alguien lanza un ataque de fuerza bruta (A07), no queda ningún rastro. Eventos que sí deben registrarse:

Evento	Por qué importa
Login correcto y fallido	Detectar fuerza bruta / credential stuffing
Cambios de contraseña, email, MFA	Detectar toma de cuenta
Fallos de control de acceso (403)	Detectar intentos de escalada / IDOR (A01)
Errores de validación de entrada	Posibles inyecciones (A03)
Operaciones sensibles (pagos, exportaciones, cambios de rol)	Trazabilidad y no repudio
Eventos de administración	Auditoría de acciones privilegiadas
Errores del servidor (500)	Salud y posible explotación

// SEGURO: registrar eventos de seguridad con contexto (sin datos sensibles)
router.post('/api/login', async (req, res) => {
  const u = await getUser(req.body.email);
  if (u && await verifyPassword(req.body.password, u.pwd)) {
    req.session.userId = u.id;
    logger.info({ event: 'login_success', userId: u.id, ip: req.ip, reqId: req.id });
    return res.json({ ok: true });
  }
  logger.warn({ event: 'login_failure', emailHash: sha256(req.body.email),
                ip: req.ip, reqId: req.id });   // hash del email, no el email en claro
  res.status(401).json({ error: 'Credenciales invalidas' });
});

Qué NO registrar: datos sensibles

Registrar de más es un fallo de seguridad tan grave como registrar de menos: los logs se copian, se envían a sistemas de terceros y se conservan mucho tiempo. Nunca registres:

Contraseñas (ni siquiera las fallidas), tokens de sesión, claves de API, secretos.
Datos de tarjeta (PAN, CVV) ni datos personales innecesarios.
Cuerpos de petición completos de endpoints sensibles (pueden contener credenciales).

// PELIGRO: esto filtra credenciales al log
logger.info('login intento', { body: req.body }); // body incluye la contrasena!

Cuando necesites correlacionar por usuario sin exponer el dato, registra un identificador seudonimizado (el userId interno, o un hash del email como arriba), no el dato en claro. Aplica enmascaramiento (mostrar solo ****4242) y redacción automática de campos sensibles en el logger.

Sí registrar	No registrar
`userId` interno, `reqId`	Contraseñas, tokens, claves
IP, user-agent, timestamp	PAN/CVV, datos personales de más
Tipo de evento y resultado	Cuerpos completos de peticiones sensibles
Hash/seudónimo del email	Email/datos en claro (si se puede evitar)

Cómo registrar bien: formato, contexto y correlación

Formato estructurado (JSON), no texto libre: permite buscar, filtrar y alertar automáticamente.
Contexto suficiente: marca de tiempo (UTC), tipo de evento, resultado, userId, IP, y un id de correlación (reqId) que atraviese todos los servicios (React → Express → módulo Java).
Centralización: enviar los logs a un sistema central (SIEM / agregador) para correlacionar entre servicios y no depender de que un contenedor efímero conserve sus ficheros.
Niveles coherentes: info para eventos normales, warn para sospechosos, error para fallos.

flowchart LR
  A[Front React] -->|reqId| B[API Express]
  B -->|reqId| C[Modulo Java]
  A --> D[Log central / SIEM]
  B --> D
  C --> D
  D --> E[Correlacion y alertas]

El reqId es el hilo que permite reconstruir una petición completa a través de todos los servicios: fundamental para el análisis forense del módulo 8.

De los logs a la detección: alertas y respuesta

Registrar sin vigilar es como instalar cámaras sin nadie mirando las pantallas. Hay que detectar y alertar:

Reglas de correlación: "N logins fallidos para la misma cuenta en X minutos", "muchos 403 desde una IP" (posible enumeración de IDOR), "picos de errores 500".
Alertas accionables: que lleguen a quien puede responder (la SRE de BazarNube, el equipo de seguridad), con contexto suficiente para actuar y sin ruido excesivo (evita la fatiga de alertas).
Umbrales y anomalías: combinar reglas fijas con detección de comportamiento anómalo.
Plan de respuesta: una alerta debe conectar con un procedimiento (quién investiga, cómo se contiene, cómo se escala). La detección sin respuesta no cierra el ciclo.

Integridad y retención de los logs

Un atacante experto intentará borrar sus huellas. Por eso:

Protege la integridad: logs en almacenamiento append-only o replicados a un sistema al que la aplicación comprometida no pueda escribir/borrar libremente.
Control de acceso a los logs: contienen información sensible; limita quién los lee (se solapa con A01).
Retención adecuada: conserva lo suficiente para investigar (según política y normativa), pero no indefinidamente si contienen datos personales.
Sincroniza los relojes (NTP) entre servicios: sin marcas de tiempo coherentes, la correlación forense se vuelve imposible.

Errores Comunes y Consejos

No registrar los fallos (login fallido, 403, errores de validación). Son las señales de ataque.
Registrar datos sensibles (contraseñas, tokens, PAN, cuerpos completos). Convierte el log en una brecha.
Logs solo en texto libre. Dificultan alertar; usa formato estructurado.
Registrar pero no alertar. Sin detección/respuesta, los logs solo sirven para la autopsia.
Logs en el propio servidor comprometido, sin protección. El atacante los borra; centraliza y protege la integridad.
Relojes sin sincronizar. Rompe la correlación temporal en el forense.
Consejo: define desde el diseño (enlaza con A04) qué eventos de seguridad emite cada componente y a qué alerta dan lugar; el logging no se improvisa después.

Ejercicios

Ejercicio 1. Clasifica qué se debe y qué no se debe registrar en un intento de login: email, contraseña introducida, resultado (éxito/fallo), IP, id de sesión emitido, marca de tiempo.

Ejercicio 2. La API registra cada 403 (acceso denegado) pero nadie mira esos logs. ¿Qué oportunidad de detección se pierde y cómo la aprovecharías?

Ejercicio 3. Un atacante compromete un contenedor de BazarNube y borra /var/log/app.log. ¿Qué dos medidas habrían preservado la evidencia?

Soluciones

Solución 1. Registrar: resultado (éxito/fallo), IP, marca de tiempo y un identificador de usuario seudonimizado (userId o hash del email). No registrar: la contraseña (jamás), el email en claro si se puede evitar (mejor su hash) y el id de sesión emitido (es un secreto; su filtración permite secuestro de sesión).

Solución 2. Se pierde la detección temprana de escalada/IDOR y enumeración (A01): una ráfaga de 403 desde una cuenta o IP indica que alguien está probando accesos no autorizados. Se aprovecha creando una regla de alerta ("más de N 403 por usuario/IP en X minutos") que notifique al equipo, más un panel de tendencia para ver picos.

Solución 3. (1) Centralizar los logs en tiempo real en un sistema externo (SIEM/agregador) al que el contenedor comprometido no pueda borrar; (2) almacenamiento append-only/inmutable con control de acceso restringido. Así, aunque el atacante borre el fichero local, la evidencia ya está fuera de su alcance.

Conclusión

A09 cierra el ciclo de la seguridad operativa: registrar los eventos correctos (y solo esos, sin datos sensibles), en formato estructurado y correlacionable, para detectar y responder a tiempo, protegiendo la integridad de los propios logs. En BazarNube pasamos de un sistema mudo a uno que emite eventos de seguridad con reqId, seudonimiza los datos, centraliza en un SIEM y dispara alertas accionables.

Entrada de backlog — A09: logging estructurado de eventos de seguridad (login éxito/fallo, 403, operaciones sensibles) con reqId; redacción de datos sensibles y hash del email; centralización en SIEM; reglas de alerta por fuerza bruta y ráfagas de 403; logs append-only con retención definida. Estos logs serán la base del caso de estudio de incidente del módulo 8 (08-03).

Nos queda una categoría, la segunda novedad de 2021. Cuando el propio servidor hace peticiones a URLs que el atacante controla, tenemos un problema serio. La última lección del módulo es A10:2021 – Server-Side Request Forgery (SSRF).

A09:2021 – Fallos de Registro y Monitorización

Contenido

Por qué el registro y la monitorización son seguridad

Qué eventos de seguridad registrar

Qué NO registrar: datos sensibles

Cómo registrar bien: formato, contexto y correlación

De los logs a la detección: alertas y respuesta

Integridad y retención de los logs

Errores Comunes y Consejos

Ejercicios

Soluciones

Conclusión

Curso de OWASP: Directrices y Estándares para la Seguridad en Aplicaciones Web

Módulo 1: Introducción a OWASP

Módulo 2: Principales Proyectos de OWASP

Módulo 3: OWASP Top Ten 2021 en Profundidad

Módulo 4: OWASP ASVS (Application Security Verification Standard)

Módulo 5: OWASP SAMM (Software Assurance Maturity Model)

Módulo 6: OWASP ZAP (Zed Attack Proxy)

Módulo 7: Buenas Prácticas y Recomendaciones

Módulo 8: Ejercicios Prácticos y Casos de Estudio

Módulo 9: Evaluación y Certificación