Les vuit lliçons anteriors van ser de prevenció: tancar portes abans que algú les creui. Però cap prevenció és total. A09:2021 – Errors de Registre i Monitorització (Security Logging and Monitoring Failures) —abans "Registre i Monitoratge Insuficients"— aborda què passa quan alguna cosa s'esmuny: ho detectem?, en quant de temps?, podem investigar què va passar? L'estadística és demolidora: moltes bretxes triguen mesos a detectar-se, i sovint l'avís arriba de fora (un tercer, la premsa) en lloc dels propis sistemes.
Aquesta categoria és transversal: és la que converteix tots els "esdeveniments de seguretat" que hem anat mencionant (errors de control d'accés a A01, intents de login a A07, XML amb DTD a XXE...) en senyals accionables. A BazarNube revisarem el logging de l'API Express: què registrar, què mai registrar (dades sensibles), com detectar i alertar. Aquesta lliçó connecta directament amb el cas d'estudi d'anàlisi d'incident del mòdul 8 (08-03), on farem servir aquests logs per reconstruir un atac.
Avís legal i ètic: els exemples són il·lustratius i amb dades fictícies. En registrar esdeveniments de persones reals, compleix la normativa de protecció de dades aplicable. Practica només sobre sistemes propis o amb autorització explícita.
Contingut
- Per què el registre i la monitorització són seguretat
- Quins esdeveniments de seguretat registrar
- Què NO registrar: dades sensibles
- Com registrar bé: format, context i correlació
- Dels logs a la detecció: alertes i resposta
- Integritat i retenció dels logs
- Errors comuns, exercicis i solucions
- Per què el registre i la monitorització són seguretat
Sense registre no hi ha detecció (no veus l'atac en curs), ni resposta (no saps què contenir), ni anàlisi forense (no pots reconstruir què va passar), ni evidència (per a requisits legals/regulatoris). Un bon sistema de logging redueix el temps de detecció de mesos a minuts i és la diferència entre "vam contenir l'incident" i "ens vam assabentar pels titulars".
- Quins esdeveniments de seguretat registrar
L'API de BazarNube amb prou feines registrava res rellevant per a seguretat:
// VULNERABLE per omissio: no hi ha rastre d'esdeveniments de seguretat
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: 'Credencials invalides' }); // fallada silenciosa
});Si algú llança un atac de força bruta (A07), no queda cap rastre. Esdeveniments que sí que s'han de registrar:
| Esdeveniment | Per què importa |
|---|---|
| Login correcte i fallit | Detectar força bruta / credential stuffing |
| Canvis de contrasenya, correu, MFA | Detectar presa de compte |
| Errors de control d'accés (403) | Detectar intents d'escalada / IDOR (A01) |
| Errors de validació d'entrada | Possibles injeccions (A03) |
| Operacions sensibles (pagaments, exportacions, canvis de rol) | Traçabilitat i no repudi |
| Esdeveniments d'administració | Auditoria d'accions privilegiades |
| Errors del servidor (500) | Salut i possible explotació |
// SEGUR: registrar esdeveniments de seguretat amb context (sense dades 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 correu, no el correu en clar
res.status(401).json({ error: 'Credencials invalides' });
});
- Què NO registrar: dades sensibles
Registrar de més és un error de seguretat tan greu com registrar de menys: els logs es copien, s'envien a sistemes de tercers i es conserven molt de temps. Mai registris:
- Contrasenyes (ni tan sols les fallides), tokens de sessió, claus d'API, secrets.
- Dades de targeta (PAN, CVV) ni dades personals innecessàries.
- Cossos de petició complets d'endpoints sensibles (poden contenir credencials).
// PERILL: aixo filtra credencials al log
logger.info('login intent', { body: req.body }); // el body inclou la contrasenya!Quan necessitis correlacionar per usuari sense exposar la dada, registra un identificador seudonimitzat (el userId intern, o un hash del correu com abans), no la dada en clar. Aplica emmascarament (mostrar només ****4242) i redacció automàtica de camps sensibles al logger.
| Sí registrar | No registrar |
|---|---|
userId intern, reqId |
Contrasenyes, tokens, claus |
| IP, user-agent, timestamp | PAN/CVV, dades personals de més |
| Tipus d'esdeveniment i resultat | Cossos complets de peticions sensibles |
| Hash/pseudònim del correu | Correu/dades en clar (si es pot evitar) |
- Com registrar bé: format, context i correlació
- Format estructurat (JSON), no text lliure: permet cercar, filtrar i alertar automàticament.
- Context suficient: marca de temps (UTC), tipus d'esdeveniment, resultat,
userId, IP, i un id de correlació (reqId) que travessi tots els serveis (React → Express → mòdul Java). - Centralització: enviar els logs a un sistema central (SIEM / agregador) per correlacionar entre serveis i no dependre que un contenidor efímer conservi els seus fitxers.
- Nivells coherents:
infoper a esdeveniments normals,warnper a sospitosos,errorper a fallades.
flowchart LR A[Front React] -->|reqId| B[API Express] B -->|reqId| C[Modul Java] A --> D[Log central / SIEM] B --> D C --> D D --> E[Correlacio i alertes]
El reqId és el fil que permet reconstruir una petició completa a través de tots els serveis: fonamental per a l'anàlisi forense del mòdul 8.
- Dels logs a la detecció: alertes i resposta
Registrar sense vigilar és com instal·lar càmeres sense ningú mirant les pantalles. Cal detectar i alertar:
- Regles de correlació: "N logins fallits per al mateix compte en X minuts", "molts 403 des d'una IP" (possible enumeració d'IDOR), "pics d'errors 500".
- Alertes accionables: que arribin a qui pot respondre (la SRE de BazarNube, l'equip de seguretat), amb prou context per actuar i sense soroll excessiu (evita la fatiga d'alertes).
- Llindars i anomalies: combinar regles fixes amb detecció de comportament anòmal.
- Pla de resposta: una alerta ha de connectar amb un procediment (qui investiga, com es conté, com s'escala). La detecció sense resposta no tanca el cicle.
- Integritat i retenció dels logs
Un atacant expert intentarà esborrar les seves petjades. Per això:
- Protegeix la integritat: logs en emmagatzematge append-only o replicats a un sistema al qual l'aplicació compromesa no pugui escriure/esborrar lliurement.
- Control d'accés als logs: contenen informació sensible; limita qui els llegeix (se solapa amb A01).
- Retenció adequada: conserva prou per investigar (segons política i normativa), però no indefinidament si contenen dades personals.
- Sincronitza els rellotges (NTP) entre serveis: sense marques de temps coherents, la correlació forense es torna impossible.
Errors Comuns i Consells
- No registrar les fallades (login fallit, 403, errors de validació). Són els senyals d'atac.
- Registrar dades sensibles (contrasenyes, tokens, PAN, cossos complets). Converteix el log en una bretxa.
- Logs només en text lliure. Dificulten alertar; fes servir format estructurat.
- Registrar però no alertar. Sense detecció/resposta, els logs només serveixen per a l'autòpsia.
- Logs al propi servidor compromès, sense protecció. L'atacant els esborra; centralitza i protegeix la integritat.
- Rellotges sense sincronitzar. Trenca la correlació temporal en el forense.
- Consell: defineix des del disseny (enllaça amb A04) quins esdeveniments de seguretat emet cada component i a quina alerta donen lloc; el logging no s'improvisa després.
Exercicis
Exercici 1. Classifica què s'ha i què no s'ha de registrar en un intent de login: correu, contrasenya introduïda, resultat (èxit/fallada), IP, id de sessió emès, marca de temps.
Exercici 2. L'API registra cada 403 (accés denegat) però ningú mira aquests logs. Quina oportunitat de detecció es perd i com l'aprofitaries?
Exercici 3. Un atacant compromet un contenidor de BazarNube i esborra /var/log/app.log. Quines dues mesures haurien preservat l'evidència?
Solucions
Solució 1. Registrar: resultat (èxit/fallada), IP, marca de temps i un identificador d'usuari seudonimitzat (userId o hash del correu). No registrar: la contrasenya (mai), el correu en clar si es pot evitar (millor el seu hash) i l'id de sessió emès (és un secret; la seva filtració permet segrest de sessió).
Solució 2. Es perd la detecció primerenca d'escalada/IDOR i enumeració (A01): una ràfega de 403 des d'un compte o IP indica que algú està provant accessos no autoritzats. S'aprofita creant una regla d'alerta ("més de N 403 per usuari/IP en X minuts") que notifiqui l'equip, més un panell de tendència per veure pics.
Solució 3. (1) Centralitzar els logs en temps real en un sistema extern (SIEM/agregador) que el contenidor compromès no pugui esborrar; (2) emmagatzematge append-only/immutable amb control d'accés restringit. Així, encara que l'atacant esborri el fitxer local, l'evidència ja és fora del seu abast.
Conclusió
A09 tanca el cicle de la seguretat operativa: registrar els esdeveniments correctes (i només aquests, sense dades sensibles), en format estructurat i correlacionable, per detectar i respondre a temps, protegint la integritat dels propis logs. A BazarNube passem d'un sistema mut a un que emet esdeveniments de seguretat amb reqId, seudonimitza les dades, centralitza en un SIEM i dispara alertes accionables.
Entrada de backlog — A09: logging estructurat d'esdeveniments de seguretat (login èxit/fallada, 403, operacions sensibles) amb reqId; redacció de dades sensibles i hash del correu; centralització en SIEM; regles d'alerta per força bruta i ràfegues de 403; logs append-only amb retenció definida. Aquests logs seran la base del cas d'estudi d'incident del mòdul 8 (08-03).
Ens queda una categoria, la segona novetat de 2021. Quan el propi servidor fa peticions a URLs que l'atacant controla, tenim un problema seriós. L'última lliçó del mòdul és A10:2021 – Server-Side Request Forgery (SSRF).
Curs d'OWASP: Directrius i Estàndards per a la Seguretat en Aplicacions Web
Mòdul 1: Introducció a OWASP
Mòdul 2: Principals Projectes d'OWASP
- OWASP Top Ten
- OWASP ASVS (Application Security Verification Standard)
- OWASP SAMM (Software Assurance Maturity Model)
- OWASP ZAP (Zed Attack Proxy)
- Altres Projectes Clau: WSTG, Cheat Sheets i Dependency-Check
Mòdul 3: OWASP Top Ten 2021 en Profunditat
- A01:2021 – Pèrdua de Control d'Accés
- A02:2021 – Errors Criptogràfics i Exposició de Dades Sensibles
- A03:2021 – Injecció
- Cross-Site Scripting (XSS) en Profunditat
- A04:2021 – Disseny Insegur
- A05:2021 – Configuració de Seguretat Incorrecta
- Entitats Externes XML (XXE)
- A06:2021 – Components Vulnerables i Desactualitzats
- A07:2021 – Errors d'Identificació i Autenticació
- A08:2021 – Errors d'Integritat de Programari i Dades (Deserialització Insegura)
- A09:2021 – Errors de Registre i Monitorització
- A10:2021 – Server-Side Request Forgery (SSRF)
Mòdul 4: OWASP ASVS (Application Security Verification Standard)
Mòdul 5: OWASP SAMM (Software Assurance Maturity Model)
Mòdul 6: OWASP ZAP (Zed Attack Proxy)
- Introducció a ZAP
- Instal·lació i Configuració
- Escaneig de Vulnerabilitats
- Automatització de Proves de Seguretat
Mòdul 7: Bones Pràctiques i Recomanacions
- Cicle de Vida de Desenvolupament Segur (SDLC)
- Modelatge d'Amenaces (Threat Modeling)
- Integració de Seguretat en DevOps (DevSecOps)
- Formació i Conscienciació en Seguretat
- Eines i Recursos Addicionals
Mòdul 8: Exercicis Pràctics i Casos d'Estudi
- Exercici 1: Identificació de Vulnerabilitats
- Exercici 2: Implementació de Controls de Seguretat
- Cas d'Estudi 1: Anàlisi d'un Incident de Seguretat
- Cas d'Estudi 2: Millora de la Seguretat en una Aplicació Web