Ja sabem què és l'ASVS i que BazarNube apunta al Nivell 2. Toca obrir el catàleg i treballar amb els requisits reals. En aquesta lliçó recorrerem els capítols de requisits més rellevants per a una aplicació web com BazarNube, aprendrem a llegir un requisit verificable amb precisió i —el més útil de tot— mapejarem les troballes del Top Ten del mòdul 3 a requisits ASVS concrets. Aquest mapeig és el que converteix el backlog dispers de BazarNube en una checklist verificable i ordenada per capítols.
Contingut
- Com llegir un requisit verificable
- V2 – Autenticació
- V3 – Gestió de sessions
- V4 – Control d'accés
- V5 – Validació, sanització i codificació
- V6 – Criptografia emmagatzemada
- V7 – Maneig d'errors i logging
- V8/V9 – Protecció de dades i comunicacions
- V14 – Configuració
- Mapa: troballes Top Ten de BazarNube → requisits ASVS
Com llegir un requisit verificable
Abans de recórrer capítols, fixem el mètode de lectura. Un requisit ASVS es llegeix identificant quatre coses:
V5.3.3 "Verificar que la codificacio de sortida sensible al context
es realitza a prop o per l'interpret al qual va destinada."
Nivells: L1 L2 L3 CWE-116
1. QUE afirma -> "es fa codificacio de sortida per context"
2. COM es comprova -> revisar el codi de renderitzat/plantilles
3. EN QUIN NIVELL aplica -> L1, L2 i L3 (obligatori ja des de L1)
4. QUINA debilitat cobreix -> CWE-116 (codificacio incorrecta de sortida)Regla pràctica: si no pots respondre "compleix / no compleix / no aplica" després de llegir-lo, no l'has acabat de verificar. Cada requisit és un cas de prova, no una recomanació. Amb aquest mètode, recorrem els capítols clau.
V2 – Autenticació
Reuneix els requisits sobre credencials, el seu cicle de vida i protecció davant abús. Cobreix el territori d'A07 (Errors d'autenticació) del Top Ten.
| Requisit | Text (resumit) | Nivell |
|---|---|---|
| V2.1.1 | Les contrasenyes tenen almenys 12 caràcters | L1–L3 |
| V2.1.7 | Les contrasenyes es contrasten contra llistes de compromeses | L1–L3 |
| V2.2.1 | Existeixen controls anti-automatització (força bruta, credential stuffing) | L1–L3 |
Exemple de verificació de V2.1.7 al backend Node de BazarNube:
// V2.1.7: rebutjar contrasenyes presents en llistes de filtrades
const pwnedCount = await checkBreachedPassword(password); // p.ex. k-anonymity
if (pwnedCount > 0) {
return res.status(400).json({
error: 'Aquesta contrasenya apareix en filtracions conegudes. Tria'n una altra.'
});
}
// V2.1.1: longitud minima
if (password.length < 12) {
return res.status(400).json({ error: 'Minim 12 caracters.' });
}V3 – Gestió de sessions
Requisits sobre com es creen, transporten, expiren i invaliden els tokens de sessió. Complementa V2 en el territori d'A07.
| Requisit | Text (resumit) | Nivell |
|---|---|---|
| V3.2.1 | Es generen tokens de sessió nous després d'autenticar-se (anti fixation) | L1–L3 |
| V3.3.1 | El logout i l'expiració invaliden realment el token | L1–L3 |
| V3.4.1 | Les cookies de sessió porten atributs Secure, HttpOnly i SameSite |
L1–L3 |
Exemple de configuració de cookie de sessió que satisfà V3.4.1 a Express:
// V3.4.1: cookie de sessio endurida
res.cookie('sid', sessionId, {
httpOnly: true, // no accessible des de JavaScript (mitiga robatori per XSS)
secure: true, // nomes s'envia per HTTPS
sameSite: 'lax', // mitiga CSRF en navegacio cross-site
maxAge: 1000 * 60 * 30 // expiracio (dona suport a V3.3.x)
});V4 – Control d'accés
El capítol d'autorització: qui pot accedir a què. Cobreix el territori d'A01 (Control d'accés trencat), inclosos els IDOR que BazarNube patia.
| Requisit | Text (resumit) | Nivell |
|---|---|---|
| V4.1.1 | Les regles de control d'accés s'apliquen al servidor de confiança | L1–L3 |
| V4.1.3 | Principi de mínim privilegi: només s'accedeix al que s'autoritza | L1–L3 |
| V4.2.1 | Es verifica la propietat del recurs abans d'accedir (anti-IDOR) | L1–L3 |
Exemple de verificació de V4.2.1 corregint l'IDOR de les comandes de BazarNube:
// V4.2.1: comprovar propietat del recurs, no confiar en l'ID del client
const comanda = await Comanda.findById(req.params.id);
if (!comanda || comanda.usuariId !== req.user.id) {
return res.status(404).end(); // 404, no 403, per no revelar existencia
}
res.json(comanda);V5 – Validació, sanització i codificació
El capítol que concentra la defensa davant injecció i XSS. Cobreix el territori d'A03 (Injecció) i del XSS del mòdul 3.
| Requisit | Text (resumit) | Nivell |
|---|---|---|
| V5.1.1 | L'entrada es valida contra un esquema/llista de permesos | L1–L3 |
| V5.3.3 | Codificació de sortida sensible al context (anti-XSS) | L1–L3 |
| V5.3.4 | Es fan servir consultes parametritzades / ORM segur (anti-injecció SQL) | L1–L3 |
Exemple de V5.3.4 substituint la concatenació de SQL de BazarNube:
// MALAMENT (injeccio): const q = `SELECT * FROM productes WHERE nom='${nom}'`;
// V5.3.4: consulta parametritzada
const { rows } = await db.query(
'SELECT * FROM productes WHERE nom = $1',
[nom]
);V6 – Criptografia emmagatzemada
Requisits sobre xifratge en repòs, gestió de claus i aleatorietat. Cobreix el territori d'A02 (Errors criptogràfics).
| Requisit | Text (resumit) | Nivell |
|---|---|---|
| V6.2.1 | Les dades sensibles es xifren en repòs | L1–L3 |
| V6.2.3 | Es fan servir algorismes i modes aprovats, no obsolets | L2–L3 |
| V6.4.1 | Les claus i secrets es gestionen amb un magatzem segur (no al codi) | L2–L3 |
Exemple de V6.4.1: els secrets no viuen al repositori.
// V6.4.1: la clau es llegeix d'un secret manager / variable d'entorn,
// mai hardcodejada al codi font
const dbKey = process.env.DB_ENCRYPTION_KEY; // injectada pel secret store
if (!dbKey) throw new Error('Falta DB_ENCRYPTION_KEY a l\'entorn');V7 – Maneig d'errors i logging
Requisits sobre registrar esdeveniments de seguretat sense filtrar dades sensibles. Cobreix el territori d'A09 (Errors de registre i monitorització).
| Requisit | Text (resumit) | Nivell |
|---|---|---|
| V7.1.1 | No es registren dades sensibles (credencials, targetes) als logs | L1–L3 |
| V7.2.1 | Es registren els esdeveniments de seguretat rellevants (login, accés denegat) | L2–L3 |
| V7.3.1 | Els logs estan protegits davant manipulació i són analitzables | L2–L3 |
// V7.2.1: registrar esdeveniment de seguretat; V7.1.1: sense dades sensibles
logger.security('login_fallit', {
usuariHash: hash(email), // no l'email en clar; mai la contrasenya
ip: req.ip,
ts: Date.now()
});V8/V9 – Protecció de dades i comunicacions
- V8 (Protecció de dades): minimització, retenció, protecció de dades sensibles al client i memòria. Cobreix part d'A02 i A04 (Disseny insegur).
- V9 (Comunicacions): TLS ben configurat, xifratge en trànsit, sense protocols febles.
| Requisit | Text (resumit) | Nivell |
|---|---|---|
| V8.1.1 | Es protegeixen dades sensibles davant cau no autoritzat | L2–L3 |
| V8.3.1 | Es minimitza i controla la retenció de dades personals | L2–L3 |
| V9.1.1 | Tota comunicació fa servir TLS; sense fallback a text pla | L1–L3 |
| V9.1.2 | Es fan servir versions i suites TLS actuals; sense protocols obsolets | L2–L3 |
V14 – Configuració
Enduriment del desplegament: capçaleres de seguretat, dependències, secrets, valors per defecte. Cobreix A05 (Configuració incorrecta) i A06 (Components vulnerables).
| Requisit | Text (resumit) | Nivell |
|---|---|---|
| V14.3.2 | S'eliminen configuracions i comptes per defecte innecessaris | L1–L3 |
| V14.4.1 | S'envien capçaleres de seguretat HTTP (CSP, HSTS, X-Content-Type-Options...) | L1–L3 |
| V14.2.1 | Les dependències estan al dia i sense vulnerabilitats conegudes | L1–L3 |
// V14.4.1: capcaleres de seguretat amb helmet a Express
app.use(helmet({
contentSecurityPolicy: { directives: { defaultSrc: ["'self'"] } },
hsts: { maxAge: 31536000, includeSubDomains: true }
}));Mapa: troballes Top Ten de BazarNube → requisits ASVS
Aquest és el lliurable central de la lliçó: convertir el backlog del mòdul 3 (organitzat per riscos A01–A10) en requisits ASVS verificables (organitzats per capítols V). Cada fila pren una troballa real de BazarNube i l'ancora als requisits que cal verificar.
| Troballa BazarNube (M3) | Risc Top Ten | Requisits ASVS a verificar | Cap. |
|---|---|---|---|
IDOR a /comandes/:id |
A01 | V4.1.1, V4.2.1 | V4 |
| Secrets i clau de xifratge al repo | A02 | V6.2.1, V6.4.1 | V6 |
| Dades de pagament sense xifrar en repòs | A02 | V6.2.1, V8.1.1 | V6/V8 |
| SQL per concatenació a la cerca | A03 | V5.1.1, V5.3.4 | V5 |
| Manca de threat modeling al checkout | A04 | V1.1.x | V1 |
| Sense capçaleres de seguretat / defaults insegurs | A05 | V14.3.2, V14.4.1 | V14 |
| Llibreria amb CVE conegut | A06 | V14.2.1 | V14 |
| XSS reflectit al cercador | A03/XSS | V5.3.3, V5.3.4 | V5 |
| Contrasenyes febles i sense anti-força bruta | A07 | V2.1.1, V2.1.7, V2.2.1 | V2 |
| Sessió no s'invalida en tancar sessió | A07 | V3.3.1, V3.4.1 | V3 |
| Sense registre d'esdeveniments de seguretat | A09 | V7.2.1, V7.3.1 | V7 |
| SSRF a "imatge des d'URL" | A10 | V5.2.6, V12.6.x | V5/V12 |
Amb aquest mapa, BazarNube ja no té "un munt de fixes solts": té una checklist ASVS per capítols, amb nivell associat i estat verificable per cada fila. Aquest és l'insum directe de la lliçó següent, on el convertirem en un pla d'implementació.
graph LR TT[Troballes Top Ten M3] --> MAP[Mapeig a requisits ASVS] MAP --> CHK[Checklist per capitols V] CHK --> VER[Verificacio compleix no-compleix]
Errors Comuns i Consells
- Llegir el requisit com a consell i no com a test. Si després de llegir-lo no saps dir compleix/no compleix, no l'has verificat; et falta mirar codi o provar.
- Validar només al client. V4.1.1 i V5.1.1 exigeixen aplicar control d'accés i validació al servidor; el front és ajuda d'UX, no control de seguretat.
- Confondre codificació de sortida amb validació d'entrada. Són requisits diferents (V5.3 vs V5.1) i tots dos calen: validar entrada no eximeix de codificar la sortida.
- Desar secrets al repositori. V6.4.1 ho prohibeix explícitament; fes servir un secret store o variables d'entorn injectades.
- Consell: treballa capítol a capítol, no requisit aleatori. Acabar V2 sencer dona una imatge de compliment molt més útil que picotejar requisits solts de diversos capítols.
Exercicis
Exercici 1. Pren la troballa "XSS reflectit al cercador" de BazarNube. Indica a quin(s) capítol(s) i requisit(s) ASVS el mapejaries i explica per què intervenen tant validació d'entrada com codificació de sortida.
Exercici 2. Llegeix aquest requisit i respon què comprovaries al codi de BazarNube per marcar-lo "compleix": "V3.4.1 – Verificar que les cookies de sessió fan servir els atributs Secure, HttpOnly i SameSite."
Exercici 3. La troballa "secrets al repositori" es va mapejar a V6.4.1. Proposa dues evidències concretes que presentaries a un auditor per demostrar que ara BazarNube compleix aquest requisit.
Solucions
Solució 1. Es mapeja al capítol V5 (Validació, sanització i codificació), principalment a V5.3.3 (codificació de sortida sensible al context) i, de manera complementària, a V5.1.1 (validació d'entrada). Intervenen tots dos perquè són defenses diferents i acumulatives: validar l'entrada redueix la superfície (rebutjar caràcters/estructures inesperades), però no n'hi ha prou, perquè dades legítimes poden contenir caràcters perillosos; la protecció determinant davant XSS és codificar la sortida segons el context (HTML, atribut, JS) al punt de renderitzat. Complir només un deixa forat; l'ASVS exigeix tots dos.
Solució 2. Buscaria al codi on s'emet la cookie de sessió (per exemple la config d'express-session o el res.cookie('sid', ...)) i comprovaria que hi són posats els tres atributs: httpOnly: true (no accessible des de JS, mitiga robatori per XSS), secure: true (només per HTTPS) i sameSite (lax o strict, mitiga CSRF). Si els tres són presents en tots els camins que creen la cookie, el requisit es marca compleix; si en falta algun o hi ha una ruta que emet la cookie sense ells, no compleix.
Solució 3. (1) Evidència de configuració: captura del secret manager / variables d'entorn mostrant que DB_ENCRYPTION_KEY i altres secrets s'injecten en temps d'execució, més el fragment de codi que els llegeix de process.env sense valors hardcodejats. (2) Evidència de procés/històric: resultat d'un escaneig de secrets (per exemple un secret scanner a CI) sobre el repositori actual retornant zero troballes, i confirmació que les claus antigues exposades van ser rotades. Totes dues juntes demostren que els secrets ni estan al codi ni són ja els que van estar exposats.
Conclusió
Els requisits de l'ASVS s'organitzen en capítols temàtics —V2 autenticació, V3 sessions, V4 control d'accés, V5 validació i codificació, V6 criptografia, V7 logging, V8/V9 dades i comunicacions, V14 configuració— i cadascun es llegeix com un cas de prova amb resposta compleix/no compleix/no aplica. El més valuós per a BazarNube ha estat mapejar les troballes del Top Ten del mòdul 3 a requisits ASVS concrets, transformant un backlog de riscos solts en una checklist verificable per capítols i nivells.
Tenim l'estàndard, el nivell objectiu (L2) i la checklist mapejada. Falta el que converteix tot això en resultats: com integrar-ho al dia a dia del projecte. A l'última lliçó del mòdul, 04-04 Implementació d'ASVS en Projectes, veurem com fer servir la checklist com a criteris d'acceptació, quan verificar manual o automàticament, com deixar evidències i traçabilitat, i traçarem un pla pràctic pas a pas per al backlog de BazarNube.
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