03 - DAST - Test Dinamico e Penetration Testing Automatico

DAST: Cos'è il Test Dinamico di Sicurezza

DAST (Dynamic Application Security Testing) e una tecnica di analisi che testa le applicazioni in esecuzione, simulando attacchi reali dall'esterno. A differenza di SAST che analizza il codice sorgente, DAST interagisce con l'applicazione via HTTP come farebbe un attaccante, cercando vulnerabilità come XSS, SQL injection, CSRF, misconfiguration e broken authentication.

DAST e un approccio black-box: non ha accesso al codice sorgente e vede l'applicazione esattamente come la vedrebbe un utente malevolo. Questo complementa SAST perchè trova vulnerabilità che emergono solo a runtime, come problemi di configurazione, header HTTP mancanti e flussi di autenticazione insicuri.

In questo articolo esploreremo OWASP ZAP e Burp Suite, la loro integrazione nella pipeline CI/CD e le strategie per implementare DAST automatizzato senza rallentare il ciclo di rilascio.

Come Funziona DAST

Un tool DAST segue un processo strutturato per analizzare un'applicazione web:

1. Spider/Crawl: il tool naviga l'applicazione scoprendo tutte le pagine, i form e gli endpoint API
2. Passive Scan: analizza le risposte HTTP cercando informazioni sensibili, header mancanti, cookie insicuri
3. Active Scan: invia payload malevoli (SQL injection, XSS payloads, path traversal) e analizza le risposte per identificare vulnerabilità
4. Reporting: genera un report con le vulnerabilità trovate, categorizzate per severita e con istruzioni di remediation

Quando Usare DAST nella Pipeline

DAST richiede un'applicazione in esecuzione, quindi si posiziona tipicamente nelle fasi successive della pipeline:

• Ambiente di staging: dopo il deploy in staging, prima della promozione a produzione
• Pull Request: su ambienti effimeri (preview deployments) per ogni PR
• Nightly scan: scan completi programmati ogni notte sull'ambiente di staging
• Post-deploy: scan leggero dopo ogni deploy in produzione (solo passive scan)

OWASP ZAP: Lo Standard Open Source

OWASP ZAP (Zed Attack Proxy) e il tool DAST open source più utilizzato al mondo, mantenuto dalla OWASP Foundation. E gratuito, estensibile e supporta sia l'uso manuale (come proxy di intercettazione) che automatizzato (per la pipeline CI/CD).

ZAP Baseline Scan in Docker

Il modo più semplice per eseguire un scan DAST automatizzato e utilizzare i container Docker ufficiali di ZAP:

# Baseline scan: scan veloce, solo passive checks
docker run --rm -t ghcr.io/zaproxy/zaproxy:stable \
  zap-baseline.py \
  -t https://staging.myapp.com \
  -r zap-report.html \
  -J zap-report.json \
  -c zap-baseline.conf

# Full scan: scan completo con active scanning
docker run --rm -t ghcr.io/zaproxy/zaproxy:stable \
  zap-full-scan.py \
  -t https://staging.myapp.com \
  -r zap-full-report.html \
  -J zap-full-report.json

# API scan: specifico per API REST/GraphQL
docker run --rm -t ghcr.io/zaproxy/zaproxy:stable \
  zap-api-scan.py \
  -t https://staging.myapp.com/api/openapi.json \
  -f openapi \
  -r zap-api-report.html
      

Configurazione ZAP per CI/CD

Per personalizzare il comportamento di ZAP, si utilizza un file di configurazione che definisce quali regole attivare, le soglie di severita e le esclusioni:

# zap-baseline.conf
# Formato: ID_regola  WARN|IGNORE|FAIL
# Regole passive scan
10010   WARN    # Cookie No HttpOnly Flag
10011   WARN    # Cookie Without Secure Flag
10015   FAIL    # Incomplete or No Cache-control
10017   WARN    # Cross-Domain JavaScript Source
10020   FAIL    # X-Frame-Options Header
10021   FAIL    # X-Content-Type-Options Header
10038   FAIL    # Content Security Policy Header
10098   WARN    # Cross-Domain Misconfiguration
10202   WARN    # Absence of Anti-CSRF Tokens
90033   WARN    # Loosely Scoped Cookie
      

Integrazione in GitHub Actions

# .github/workflows/dast.yml
name: DAST Security Scan
on:
  deployment_status:

jobs:
  dast:
    if: github.event.deployment_status.state == 'success'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: OWASP ZAP Baseline Scan
        uses: zaproxy/action-baseline@v0.12.0
        with:
          target: ${{ github.event.deployment_status.target_url }}
          rules_file_name: "zap-baseline.conf"
          cmd_options: "-a -j"
          fail_action: true

      - name: Upload ZAP Report
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: zap-report
          path: report_html.html
      

API Security Testing

Le API moderne (REST, GraphQL, gRPC) richiedono un approccio DAST specifico. Le vulnerabilità più comuni nelle API includono:

• Broken Object Level Authorization (BOLA): accesso a risorse di altri utenti modificando gli ID
• Broken Authentication: token JWT deboli, assenza di rate limiting, sessioni non invalidate
• Excessive Data Exposure: API che ritornano più dati del necessario
• Mass Assignment: modifica di campi non previsti attraverso il body della richiesta
• Injection: SQL injection, NoSQL injection, command injection attraverso parametri API

ZAP API Scan con OpenAPI

ZAP supporta la specifica OpenAPI per generare automaticamente i test per ogni endpoint:

# .github/workflows/api-dast.yml
name: API DAST Scan
on:
  workflow_dispatch:
  schedule:
    - cron: "0 2 * * 1-5"  # Ogni notte lavorativa alle 2:00

jobs:
  api-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: ZAP API Scan
        uses: zaproxy/action-api-scan@v0.7.0
        with:
          target: "https://staging-api.myapp.com/openapi.json"
          format: openapi
          fail_action: true
          cmd_options: >
            -z "-config replacer.full_list(0).description=AuthHeader
            -config replacer.full_list(0).enabled=true
            -config replacer.full_list(0).matchtype=REQ_HEADER
            -config replacer.full_list(0).matchstr=Authorization
            -config replacer.full_list(0).replacement=Bearer TEST_TOKEN"
      

Fuzzing: Test con Input Casuali

Il fuzzing e una tecnica che invia input casuali o semi-casuali all'applicazione per scoprire crash, memory leak e comportamenti inattesi. Nel contesto DAST, il fuzzing e particolarmente efficace per trovare:

• Buffer overflow in campi con lunghezza non validata
• Parsing error con input malformati (JSON/XML/YAML corrotti)
• Race condition con richieste concorrenti
• Denial of Service con payload di grandi dimensioni

Burp Suite: Lo Strumento Professionale

Burp Suite di PortSwigger e il tool DAST commerciale più utilizzato dai penetration tester professionisti. La versione Community e gratuita ma limitata; la versione Professional offre scanner automatizzato, intruder avanzato e collaborazione team.

Burp Suite eccelle nell'analisi manuale e semi-automatica, dove il tester può intercettare le richieste, modificarle e rilanciare con payload personalizzati. Per l'integrazione CI/CD, Burp Suite Enterprise offre API REST per avviare scan programmati.

Gestione dei Risultati DAST

I risultati DAST richiedono un processo di triage strutturato per evitare falsi positivi e prioritizzare le correzioni:

DAST per Single Page Applications (SPA)

Le Single Page Applications (Angular, React, Vue) presentano sfide specifiche per DAST: il contenuto e generato dinamicamente via JavaScript e il crawler tradizionale potrebbe non esplorare tutte le pagine.

• AJAX Spider di ZAP: utilizza un browser headless per navigare SPA e scoprire contenuti dinamici
• Autenticazione: configurare ZAP per gestire login basati su JWT o sessioni SPA
• Pre-seeding: fornire a ZAP una lista di URL da testare, estratta dalla build dell'applicazione

Best Practice per DAST

1. Ambiente dedicato: eseguire DAST su un ambiente di staging isolato, mai direttamente in produzione
2. Dati di test realistici: popolare l'ambiente con dati realistici per massimizzare la copertura
3. Autenticazione configurata: configurare credenziali di test per esplorare le aree autenticate
4. Scan incrementali: baseline scan sulle PR, full scan notturni
5. Correlazione con SAST: correlare i finding DAST con quelli SAST per ridurre i duplicati
6. Feedback rapido: notificare immediatamente i developer tramite Slack/Teams per finding critici

Conclusioni

DAST e il complemento essenziale di SAST nella strategia DevSecOps. Mentre SAST trova vulnerabilità nel codice sorgente, DAST verifica che l'applicazione in esecuzione sia effettivamente sicura, testando configurazioni, header, autenticazione e flussi di business.

Nel prossimo articolo esploreremo SCA (Software Composition Analysis), la tecnica per analizzare le dipendenze open source e scoprire vulnerabilità note nelle librerie utilizzate dal progetto.