ASVS i Nivells de Seguretat

Proposta didàctica

En aquest bloc estudiem l'OWASP Application Security Verification Standard (ASVS), el marc de referència per determinar el nivell de seguretat que necessita una aplicació i verificar que el compleix.

Criteris d'avaluació

CA2.1 Nivells ASVS (Application Security Verification Standard).
CA2.2 Nivell de verificació requerit per a cada tipus d'aplicació.
CA2.3 Requisits de verificació necessaris per al nivell determinat.
CA2.4 Riscos principals d'aplicacions segons OWASP.

Continguts de referència

OWASP ASVS: Application Security Verification Standard
Els 3 nivells de verificació: L1, L2, L3
Categories ASVS: V1-V14
Com aplicar ASVS en un projecte real
Eines d'avaluació: OWASP ZAP, Burp Suite
Bug Bounty programs: HackerOne i Bugcrowd

Questionari inicial del bloc

Que és l'OWASP ASVS i per a que s'utilitza?
Quants nivells de verificació té l'ASVS?
Quina diferència hi ha entre el nivell L1 i el nivell L3?
Per a quin tipus d'aplicacions s'aplica el nivell 3 d'ASVS?
Que significa la categoria V2 en l'ASVS?
Que és una auditoria de seguretat d'aplicació web?
Per a que serveix OWASP ZAP?
Que és Burp Suite i com s'utilitza en pentesting?
Que és un programa de Bug Bounty?
Quina diferència hi ha entre un pentest de caixa negra i un de caixa grisa?

1. OWASP ASVS

L'Application Security Verification Standard (ASVS) és un estàndard obert de l'OWASP que proporciona una llista de requisits de seguretat per al disseny, el desenvolupament i les proves d'aplicacions web i serveis.

Per a que serveix l'ASVS?

L'ASVS té tres objectius principals:

Metric (Mètrica): Proporcionar un estàndard per mesurar el grau de confiança en la seguretat d'una aplicació web
Guidance (Guia): Orientar els equips de desenvolupament sobre els controls de seguretat que cal implementar
Procurement (Adquisició): Servir com a referència en contractes de desenvolupament de programari

Versió actual

La versió actual és ASVS 4.0.3 (2021). La versió 5.0 estava en desenvolupament el 2024 amb importants actualitzacions per a aplicacions modernes (APIs, microserveis, cloud-native).

flowchart TD
    A[Identificar tipus d'aplicació] --> B{Quin nivell ASVS?}
    B -->|Aplicació interna baixa criticitat| C[Nivell 1: L1]
    B -->|Aplicació amb dades sensibles| D[Nivell 2: L2]
    B -->|Aplicació crítica, fintech, salut| E[Nivell 3: L3]

    C --> F[Autoavaluació\nChecklist L1]
    D --> G[Auditoria interna\nPen test extern]
    E --> H[Auditoria completa\nPen test expert]

    F --> I[Informe de Conformitat]
    G --> I
    H --> I

2. Els Tres Nivells de Verificació

Nivell 1 (L1): Seguretat Bàsica — Oportunista

El Nivell 1 és el mínim de seguretat per a qualsevol aplicació. Protegeix contra les vulnerabilitats del OWASP Top Ten i es pot verificar mitjançant:

Autoavaluació (el propi equip de desenvolupament)
Eines automàtiques (DAST, escàners)

Aplicacions que necessiten L1: - Aplicacions internes sense dades sensibles - Portals informatius estàtics - Prototips en fase inicial

Exemple de requisits L1:

Requisit	Descripció
2.1.1	Les contrasenyes de més de 12 caràcters han de ser acceptades
3.4.1	Les cookies de sessió han de tenir l'atribut `HttpOnly`
5.2.1	Totes les entrades d'usuari han de ser sanititzades
8.1.1	La pàgina d'error no ha de revelar informació del servidor

Nivell 2 (L2): Seguretat Estàndard — Defensiu

El Nivell 2 és adequat per a la majoria d'aplicacions que gestionen dades personals o transaccions de negoci. Requereix:

Revisió de codi per part d'experts
Pen testing manual per a les funcionalitats crítiques
Verificació dels controls de seguretat en profunditat

Aplicacions que necessiten L2: - Botigues en línia (e-commerce) - Plataformes SaaS amb dades d'usuaris - Apps mòbils amb funcionalitats de pagament - Sistemes de gestió empresarial (ERP, CRM)

Exemple de requisits addicionals L2:

Requisit	Descripció
2.2.1	Implementar MFA per a funcionalitats crítiques
3.3.1	Els tokens de sessió han de ser aleatoris i de mínim 128 bits d'entropia
4.2.1	Tots els accessos a recursos han de ser verificats en el servidor
9.1.1	Tota la comunicació ha d'usar TLS 1.2+

Nivell 3 (L3): Seguretat Avançada — Verificació en Profunditat

El Nivell 3 és per a aplicacions crítiques: sistemes financers, de salut, infraestructures crítiques. Requereix:

Revisió de codi exhaustiva i auditoria d'arquitectura
Pen testing avançat per experts certificats (OSCP, CEH)
Verificació dels mecanismes de seguretat interns

Aplicacions que necessiten L3: - Sistemes bancaris i de pagaments - Sistemes de salut (HIPAA) - Infraestructures crítiques - Aplicacions governamentals sensibles - Plataformes de criptomonedes

Nivell	Tipus d'Aplicació	Mètode de Verificació	Freqüència
L1	Qualsevol aplicació	Automatitzat + autoavaluació	Contínua
L2	Aplicació estàndard amb dades sensibles	Manual + automatitzat	Anual
L3	Aplicació crítica	Auditoria experta completa	Semestral

3. Categories ASVS

L'ASVS 4.0.3 s'organitza en 14 categories (V1 a V14):

mindmap
  root((ASVS v4.0))
    V1 Arquitectura
    V2 Autenticació
    V3 Sessions
    V4 Control Accés
    V5 Validació i Sanitització
    V6 Criptografia
    V7 Gestió Errors i Logs
    V8 Protecció Dades
    V9 Comunicació
    V10 Codi Maliciós
    V11 Lògica de Negoci
    V12 Fitxers i Recursos
    V13 API i Serveis
    V14 Configuració

V2: Autenticació

La categoria V2 cobreix tots els aspectes de la verificació d'identitat:

Requisits clau V2 (selecció):

V2.1.1  Les contrasenyes de mínim 12 caràcters han de ser acceptades [L1]
V2.1.2  Les contrasenyes de fins a 128 caràcters han de ser acceptades [L1]
V2.1.6  El comptador de contrasenyes no ha de truncar contrasenyes [L1]
V2.2.1  L'autenticació multifactor ha d'estar disponible [L2]
V2.3.1  S'han de generar credencials inicials aleatòries d'almenys 6 caràcters [L1]
V2.4.1  Les contrasenyes han d'estar emmagatzemades en forma resistentla a atacs offline [L1]
V2.4.2  S'ha d'usar bcrypt, scrypt, argon2id o PBKDF2 per a l'emmagatzematge [L1]
V2.7.1  S'han d'enviar OTPs o codis d'un sol ús per canal secundari segur [L1]

V3: Gestió de Sessions

Requisits clau V3:

V3.1.1  La id de sessió no s'ha d'exposar mai a l'URL [L1]
V3.2.1  L'id de sessió s'ha de generar amb almenys 128 bits d'entropia [L1]
V3.2.2  S'ha de generar una nova id de sessió en iniciar sessió [L1]
V3.2.4  Les ids de sessió han de ser aleatòries usant un CSPRNG [L1]
V3.3.1  La sessió ha d'expirar en un temps raonable [L1]
V3.4.1  Les cookies han de tenir l'atribut SameSite [L1]
V3.4.2  Les cookies han de tenir l'atribut HttpOnly [L1]
V3.4.3  Les cookies han de tenir l'atribut Secure [L1]
V3.7.1  L'aplicació ha d'invalidar tokens de sessió en tancar sessió [L1]

V4: Control d'Accés

Requisits clau V4:

V4.1.1  L'aplicació ha d'aplicar les regles de control d'accés al costat del servidor [L1]
V4.1.2  Tots els atributs d'usuari i dades usats pel control d'accés han de ser verificats [L1]
V4.1.3  El principi de mínim privilegi ha d'aplicar-se [L1]
V4.2.1  L'aplicació ha de protegir-se contra IDOR [L1]
V4.3.1  Les interfícies d'administració han de usar autenticació forta [L1]

V5: Validació, Sanitització i Codificació

Requisits clau V5:

V5.1.1  L'aplicació disposa de defenses contra atacs de paràmetres HTTP [L1]
V5.2.1  Totes les entrades d'usuari no confiables es codifiquen en l'output [L1]
V5.2.2  La validació d'entrades usa una llista blanca, no negra [L1]
V5.3.4  L'aplicació usa prepared statements per a SQL [L1]
V5.3.5  L'aplicació usa consultes parametritzades [L1]

4. Com Aplicar ASVS en un Projecte Real

Pas 1: Determinar el Nivell Necessari

Factors a considerar per determinar el nivell ASVS adequat:

Factor	Impacte en el Nivell
Dades personals (GDPR)	+1 nivell
Transaccions financeres	L2 mínim
Dades mèdiques (HIPAA)	L3 recomanat
Accés des d'Internet	+1 nivell
Usuaris de tercers	+1 nivell
Infraestructura crítica	L3 obligatori

Pas 2: Crear el Checklist de Requisits

Exemple de checklist per a una API REST de L2:

## Checklist ASVS L2 - API REST de gestió d'usuaris

### V2: Autenticació
- [ ] V2.1.1: Les contrasenyes accepten fins a 128 caràcters
- [ ] V2.1.6: Les contrasenyes no es truncen
- [ ] V2.2.1: MFA disponible per a usuaris
- [ ] V2.4.2: Contrasenyes emmagatzemades amb Argon2id
- [ ] V2.7.1: OTPs enviats per canal secundari

### V3: Gestió de Sessions
- [ ] V3.1.1: ID de sessió no exposada a URL
- [ ] V3.2.1: ID de sessió amb 128+ bits d'entropia
- [ ] V3.2.2: Nova ID de sessió en login
- [ ] V3.3.1: Expiració de sessió configurada
- [ ] V3.7.1: Invalidació de sessió en logout

### V4: Control d'Accés
- [ ] V4.1.1: Control d'accés al servidor, no al client
- [ ] V4.2.1: Protecció contra IDOR
- [ ] V4.3.1: Interfícies admin protegides

Pas 3: Verificació i Proves

sequenceDiagram
    participant Dev as Equip Dev
    participant SAST as Eina SAST
    participant DAST as OWASP ZAP
    participant Auditor as Auditor Extern

    Dev->>SAST: Anàlisi del codi font
    SAST-->>Dev: Informe de vulnerabilitats
    Dev->>Dev: Corregir vulnerabilitats
    Dev->>DAST: Escaneig dinàmic
    DAST-->>Dev: Informe DAST
    Dev->>Dev: Corregir vulnerabilitats
    Dev->>Auditor: Sol·licitar auditoria L2
    Auditor->>Auditor: Pen test manual
    Auditor-->>Dev: Informe final ASVS

5. Eines d'Avaluació

OWASP ZAP (Zed Attack Proxy)

OWASP ZAP és una de les eines de seguretat web de codi obert més populars del món. Permet:

Interceptar i modificar peticions HTTP/HTTPS (com a proxy)
Escaneig automàtic de vulnerabilitats
Proves manuals de penetració
Integració en pipelines CI/CD

Iniciar ZAP amb Docker:

# Executar ZAP en mode daemon
docker run -d \
  --name zap-NOMCOGNOM \
  -p 8080:8080 \
  ghcr.io/zaproxy/zaproxy:stable \
  zap.sh -daemon -host 0.0.0.0 -port 8080 \
  -config api.key=clau-secreta

# Escaneig ràpid d'una URL
docker exec zap-NOMCOGNOM \
  zap-cli --api-key clau-secreta \
  quick-scan --self-contained \
  --start-options '-config api.key=clau-secreta' \
  http://aplicacio-a-provar.com

# Escaneig complet (spider + actiu)
docker run --rm \
  ghcr.io/zaproxy/zaproxy:stable \
  zap-full-scan.py \
  -t http://aplicacio-a-provar.com \
  -r informe_zap.html

Escaneig automatitzat en CI/CD (GitHub Actions):

# .github/workflows/dast.yml
name: DAST amb OWASP ZAP
on: [push]

jobs:
  zap_scan:
    runs-on: ubuntu-latest
    steps:
      - name: ZAP Scan
        uses: zaproxy/action-full-scan@v0.10.0
        with:
          target: 'https://staging.aplicacio.com'
          rules_file_name: '.zap/rules.tsv'
          cmd_options: '-a'

Burp Suite Community

Burp Suite és la plataforma de referència per a proves manuals de penetració web. La versió Community inclou:

Proxy: Interceptar i modificar peticions
Repeater: Reenviar i modificar peticions manualment
Intruder: Atacs automatitzats (brute force, fuzzing)
Decoder: Codificar/descodificar dades (Base64, URL, HTML...)
Sequencer: Analitzar l'aleatorietat de tokens de sessió

Configuració del proxy Burp Suite:

Proxy: 127.0.0.1:8080
Certificat: Importar el certificat CA de Burp al navegador

Miniactivitat: OWASP ZAP

Desplega OWASP WebGoat amb Docker:

docker run -d -p 8081:8080 \
  --name webgoat-NOMCOGNOM \
  webgoat/webgoat

Configura OWASP ZAP com a proxy
Navega per WebGoat a través del proxy ZAP
Llança un escaneig actiu sobre http://localhost:8081/WebGoat
Identifica les 3 vulnerabilitats de severitat més alta trobades

6. Bug Bounty Programs

Els programes de Bug Bounty permeten a investigadors de seguretat (hackers ètics) reportar vulnerabilitats a canvi d'una recompensa econòmica.

Com funcionen

flowchart LR
    A[Investigador\nde Seguretat] --> B[Descobreix\nVulnerabilitat]
    B --> C[Reporta via\nPlataforma Bug Bounty]
    C --> D{Empresa\nvalida el report}
    D -->|Vàlid| E[Paga la Recompensa]
    D -->|Duplicat| F[No Paga]
    D -->|Fora d'abast| G[No Paga]
    E --> H[Empresa corregeix\nla vulnerabilitat]

HackerOne i Bugcrowd

Plataforma	URL	Empreses destacades
HackerOne	hackerone.com	Uber, Twitter, GitHub, DoD (Govern EUA)
Bugcrowd	bugcrowd.com	Tesla, Mastercard, OpenAI
Intigriti	intigriti.com	Molt actiu a Europa
Immunefi	immunefi.com	Especialitzat en DeFi/blockchain

Recompenses típiques

Severitat	Recompensa típica (HackerOne)
Crítica (RCE, SQLi)	5.000 € – 100.000 €
Alta (XSS Stored, IDOR)	500 € – 5.000 €
Mitjana (XSS Reflected)	100 € – 500 €
Baixa (informació sensible)	50 € – 100 €

Regles i Responsabilitat

Important

Realitzar proves de seguretat sense autorització és il·legal a la majoria de països (Llei Orgànica 10/1995, Codi Penal espanyol, art. 197 bis). Sempre cal obtenir autorització escrita abans de fer qualsevol tipus de prova de penetració.

Els programes de Bug Bounty estableixen clarament: - L'abast (scope): quins sistemes es poden provar - Les regles d'enginyeria: que és permès i que no - El canal de comunicació per reportar

Resum del Bloc

Concepte	Descripció
ASVS	Estàndard OWASP per verificar la seguretat d'aplicacions web
L1	Nivell mínim per a qualsevol aplicació
L2	Nivell per a aplicacions amb dades sensibles
L3	Nivell per a aplicacions crítiques (financer, salut)
V2	Categoria d'autenticació ASVS
V3	Categoria de sessions ASVS
V4	Categoria de control d'accés ASVS
OWASP ZAP	Eina DAST open source per escaneig web
Burp Suite	Plataforma de pen test web professional
Bug Bounty	Programa de recompenses per descobrir vulnerabilitats

Activitats

AC506 (CA2.1, CA2.2) Determinació del nivell ASVS per a 3 aplicacions tipus
AC507 (CA2.3) Creació d'un checklist ASVS L2 per a una API REST
AC508 (CA2.4) Escaneig d'una aplicació de proves amb OWASP ZAP
AC509 (CA2.4) Proves manuals bàsiques amb Burp Suite Community

Projecte del Bloc

PR502 (CA2.1–CA2.4) Auditoria ASVS L2 completa d'una aplicació web amb informe formal

Ampliacions

AP503 Estudi d'un informe real de HackerOne i anàlisi de la vulnerabilitat
AP504 Comparativa entre ASVS i altres estàndards (PCI-DSS, ISO 27034)