**Come funziona:**

1. **Claude Code** legge `CLAUDE.md` per la metodologia completa di pentest e orchestra il flusso di lavoro in 7 fasi
2. **Subagenti specializzati per ruolo** (Scout, Analyzer, Exploiter, Reporter) eseguono compiti mirati con template di prompt dedicati, guide per gli strumenti e anti-pattern
3. **Server MCP WSTG** (68+ strumenti) fornisce procedure di test OWASP, 31 guide alle tecniche di PortSwigger, albero dei compiti gerarchico, grafo della conoscenza, evasione WAF, prioritizzazione degli endpoint, verifica dei risultati, compressione del contesto, gate di qualità e generazione di report
4. **Contenitore Docker** esegue tutti i 27 strumenti di sicurezza — il traffico può essere instradato opzionalmente attraverso Burp Suite per il monitoraggio passivo
5. **Playwright MCP** gestisce i test basati su browser (DOM XSS, clickjacking, pagine di login renderizzate con JavaScript)

---

## Caratteristiche

### Copertura OWASP Completa
- **109 casi di test WSTG** in 12 categorie — dalla raccolta informazioni al test delle API
- Ogni test include procedure CLI passo passo, payload specifici per contesto, criteri di rilevamento e rubriche di gravità
- I test sono prioritizzati (MUST/SHOULD) con trigger condizionali in modo che nulla di rilevante venga saltato

### 31 Guide alle Tecniche di Attacco PortSwigger
- Fonte: [PortSwigger Web Security Academy](https://portswigger.net/web-security) — metodi di rilevamento, tecniche di sfruttamento, payload, cheat sheet e pattern di bypass WAF
- Organizzate per classe di vulnerabilità (SQLi, XSS, SSRF, JWT, OAuth, ecc.) per un uso diretto durante i test
- Integrate in ogni fase di test — gli agenti caricano automaticamente la guida tecnica pertinente prima di testare ogni classe di vulnerabilità
- Tabelle di payload specifici per database/piattaforma (Oracle vs MySQL vs PostgreSQL vs MSSQL per SQLi, Jinja2 vs Twig vs Freemarker per SSTI, ecc.)
- Pattern di bypass WAF organizzati per livello di bypass (base → intermedio → avanzato)

### 27 Strumenti di Sicurezza Pre-Configurati
- Tutti gli strumenti pre-installati in una singola immagine Docker — `make setup` e sei pronto
- Strumenti organizzati per fase: discovery, test di injection, autenticazione, crittografia, test delle API
- Integrazione automatica del proxy Burp Suite per il monitoraggio passivo del traffico

### Flusso di Lavoro Strutturato in 7 Fasi
- **Fase 0:** Scoperta e Mappatura dell'Applicazione
- **Fase 1:** Raccolta Informazioni e Ricognizione
- **Fase 2:** Test di Configurazione e Distribuzione
- **Fase 3:** Gestione di Identità, Autenticazione, Autorizzazione e Sessioni
- **Fase 4:** Test di Validazione degli Input (pipeline XSS/SQLi/SSRF)
- **Fase 5:** Gestione degli Errori, Crittografia, Logica di Business, Test Lato Client e API
- **Fase 6:** Verifica della Copertura e Reportistica
- **Fase 7:** Revisione Finale e Remediation

### Sistema di Assicurazione della Qualità
- **Gate di fase automatici** — ogni fase deve superare i controlli di qualità prima di procedere
- **Subagente Quality Reviewer** ad ogni transizione di fase identifica lacune e suggerisce miglioramenti
- **Giudice Finale** — un agente senza contesto esamina l'intero impegno a freddo, come un revisore QA esterno
- **Gate di esaurimento** — "non vulnerabile" richiede prova di uno sforzo di test sufficiente (tecniche minime e tentativi di bypass)

### Risultati Basati su Prove
- Ogni risultato richiede comandi curl riproducibili e prove complete di richiesta/risposta
- **Classificazione a tre livelli:** SFRUTTATO (impatto provato), POTENZIALE (bloccato da controllo), FALSO POSITIVO (controllo regge)
- **Framework anti-allucinazione** — "nessun exploit = nessun risultato" applicato ad ogni livello
- Liste di controllo delle prove per classe di vulnerabilità verificate prima di registrare qualsiasi risultato

### Subagenti Specializzati per Ruolo
- **4 ruoli dedicati** con template di prompt focalizzati, guide per gli strumenti e anti-pattern:
  - **Scout** — solo ricognizione, mappa la superficie d'attacco senza inviare payload (Fase 0-1)
  - **Analyzer** — identifica potenziali sink con payload canario/witness, costruisce code di sfruttamento (Analisi Fase 2-5)
  - **Exploiter** — consuma l'output di Analyzer, prova lo sfruttamento con prove, registra i risultati confermati (Sfruttamento Fase 4)
  - **Reporter** — revisione qualità e Giudice Finale, esamina i dati senza inviare richieste (QA + post-report)
- Punto di controllo di validazione tra analisi e sfruttamento previene sforzi sprecati
- Ogni ruolo ha elenchi espliciti di strumenti consentiti/vietati e contratti input/output

### Sfruttamento in Pipeline (Fase 4)
- 3 **pipeline a due stadi** indipendenti eseguite in parallelo: XSS, Injection (SQLi/CMDi), SSRF/SSTI
- Ogni pipeline: Analyzer (scopri → analizza → accoda) → punto di controllo di validazione → Exploiter (sfrutta → registra)
- Ogni pipeline carica la sua guida tecnica PortSwigger per metodi di rilevamento, cheat sheet e pattern di bypass WAF
- Intelligenza WAF condivisa tra tutte le pipeline
- Payload witness sensibili al contesto per 13 tipi di sink

### Evasione WAF Adattiva
- **Riconoscimento automatico del WAF** da intestazioni di risposta, corpo e codici di stato — identifica 12 vendor WAF (Cloudflare, AWS WAF, Akamai, Imperva, ModSecurity, F5, FortiWeb, Sucuri, Barracuda, Wordfence, NAXSI, Citrix)
- **Payload di bypass specifici per vendor** organizzati per livello di complessità (base → intermedio → avanzato)
- Intelligenza WAF condivisa tra tutti gli agenti tramite sistema di deliverable
- Gli agenti identificano automaticamente il WAF al primo blocco della risposta e passano a payload di bypass su misura

### Grafo della Conoscenza tra le Fasi
- **Grafo entità-relazione** traccia endpoint, parametri, tecnologie, risultati, cookie, domini e ruoli utente
- **Concatenamento automatico delle vulnerabilità** tramite ricerca del percorso BFS con 7 pattern di concatenamento predefiniti:
  - XSS + CSP mancante, XSS + cookie debole (no HttpOnly), Reindirizzamento aperto + callback OAuth
  - IDOR + ruolo admin, SSRF + metadati cloud, Nessun blocco + nessun MFA, CORS + endpoint sensibile
- Aggiornamenti di gravità quando il concatenamento aumenta materialmente l'impatto
- Popolato durante i test, interrogato dopo la Fase 4 per la scoperta di concatenamenti

### Albero dei Compiti Gerarchico
- Struttura ad albero persistente (fasi come rami, test come foglie) previene il bias di profondità LLM e la perdita di contesto
- L'agente principale mantiene una visione macro strategica; i subagenti aggiornano solo i nodi foglia assegnati
- Auto-propaggazione: quando tutti i figli completano, il genitore si completa automaticamente
- Percentuali di completamento a livello di fase per un processo decisionale informato

### Prioritizzazione del Rischio degli Endpoint
- Valuta e ordina gli endpoint per rischio per test prioritari — il rischio più alto testato per primo
- Fattori di valutazione: numero di parametri, indicatori di rischio tecnologico, confidenza della catena di taint, convergenza degli strumenti, requisiti di autenticazione, nomi di parametri iniettabili
- Integrato nella generazione della mappa degli endpoint della Fase 0

### Parsing dell'Output degli Strumenti
- **13 parser integrati** per strumenti CLI comuni (nmap, nuclei, sqlmap, ffuf, httpx, whatweb, testssl, nikto, dalfox, katana, gau, wapiti, commix)
- Condensa l'output grezzo degli strumenti 3-5x preservando risultati chiave, endpoint ed errori
- Verbosità configurabile: riepilogo (~15 righe), dettagliato (~50 righe), completo (output analizzato completo)

### Verifica dei Risultati degli Strumenti CLI
- Validazione automatica della qualità dell'output degli strumenti CLI — rileva output vuoti, errori di proxy, problemi di permessi e risultati sospetti
- **10 validatori per strumento** (nmap, nuclei, sqlmap, ffuf, feroxbuster, testssl, dalfox, wapiti, katana, httpx) con suggerimenti di comandi corretti
- Quando uno strumento produce output vuoto o sospetto, il validatore suggerisce correzioni (ad es., aggiungi `-Pn` per nmap, rimuovi variabili d'ambiente proxy, prova flag diversi)
- Integrato nel flusso di lavoro di esecuzione degli strumenti — gli agenti chiamano `verify_tool_result()` dopo ogni esecuzione di strumento CLI

### Compressione Progressiva del Contesto
- **Riepiloghi di fase** (~500-800 parole) generati automaticamente quando i gate di fase vengono superati — catturano risultati, copertura, risultati degli strumenti e superficie d'attacco in forma compressa
- Previene il degrado del contesto in impegni di lunga durata sostituendo i dati storici grezzi con riepiloghi strutturati
- `get_engagement_summary()` combina tutti i riepiloghi di fase in una singola panoramica per l'iniezione in nuovi prompt di subagenti
- I riepiloghi sono memorizzati come deliverable — accessibili da qualsiasi agente a valle senza richiedere la cronologia completa dell'impegno

### Analisi Controfattuale (Scoperta di Secondo Passaggio)
- Dopo che un Analyzer completa con vulnerabilità trovate, viene generato un **secondo Analyzer** con istruzioni di "assumere che quelle vulnerabilità siano corrette"
- L'Analyzer controfattuale cerca **ulteriori** vulnerabilità: endpoint diversi, parametri diversi, contesti di injection diversi, difetti logici
- I risultati vengono aggiunti alla coda di sfruttamento esistente (unione automatica con deduplicazione per endpoint+parametro e ID auto-incrementanti)
- Basato sulla ricerca PenHeal ablation che mostra un +71% di copertura delle vulnerabilità con prompt controfattuali

### Supporto Multi-Dominio
- Rilevamento e gestione automatici di SSO/OAuth/OIDC/SAML
- Registrazione, crawling e test dell'ambito per dominio
- Gestione del cookie jar per la persistenza delle sessioni tra domini
- Escalation di fallimento dell'autenticazione a 6 livelli (grant alternativi → PKCE → browser headless → estrazione token → provisioning utente → non autenticato)

### Gestione dell'Impegno a prova di crash
- `findings.md` e `progress.log` in append-only sopravvivono ai crash
- Checkpointing del workspace Git con capacità di rollback
- **Ripresa automatica su interruzione** — `resume-prompt.md` generato automaticamente ad ogni checkpoint con contesto completo (target, credenziali, fase corrente, test rimanenti, ambito). Incolla in una nuova sessione per continuare esattamente da dove hai lasciato
- Granularità del checkpoint a metà fase — tiene traccia di quali test all'interno di una fase sono completati, non solo dello stato a livello di fase
- Audit trail completo di ogni chiamata allo strumento MCP con timestamp

### Reportistica Professionale
- Report in Markdown con riepilogo esecutivo, risultati per gravità, matrice di copertura dei test e copertura degli strumenti
- Percentuali di copertura per categoria e analisi delle lacune
- Documentazione dell'analisi del concatenamento delle vulnerabilità
- Osservazioni del Giudice Finale e note di qualità incluse

---

## Sistema dei Ruoli degli Agenti

AutoPentest utilizza 4 ruoli di agente specializzati invece di subagenti generici. Ogni ruolo ha un template di prompt dedicato con guide per gli strumenti focalizzate, contratti input/output e anti-pattern.

| Ruolo | Template | Scopo | Fasi |
|-------|----------|-------|------|
| **Scout** | `templates/agent-roles/scout.md` | Ricognizione e mappatura della superficie d'attacco | Fase 0-1, scoperta del codice sorgente |
| **Analyzer** | `templates/agent-roles/analyzer.md` | Scoperta delle vulnerabilità con payload canario/witness | Analisi Fase 2-5 |
| **Exploiter** | `templates/agent-roles/exploiter.md` | Prova di sfruttamento con evidenze | Sfruttamento Fase 4 |
| **Reporter** | `templates/agent-roles/reporter.md` | Revisione qualità e Giudice Finale | Transizioni di fase, post-report |

### Come Funziona la Pipeline

La Fase 4 (test a più alto impatto) utilizza una pipeline a due stadi per classe di vulnerabilità:```
┌──────────────────────────────────────────────────────────────┐
│                    Pipeline 1: XSS                           │
│                                                              │
│  Analyzer (75 turns)          Exploiter (75 turns)           │
│  ┌─────────────────────┐      ┌─────────────────────┐        │
│  │ Discover endpoints  │      │ Load Analyzer queue │        │
│  │ Send canary payloads│─────▶│ Attempt exploitation│        │
│  │ Build exploit queue │ gate │ Prove impact        │        │
│  │ Save deliverable    │      │ Log findings        │        │
│  └─────────────────────┘      └─────────────────────┘        │
│                          ▲                                   │
│               validate_exploitation_queue()                  │
└──────────────────────────────────────────────────────────────┘

Ecco fatto. Tutti i 27 strumenti di sicurezza sono ora installati e pronti all'interno del contenitore Docker.

### Verifica dell'installazione```bash
# Check all tools are installed
make verify-tools

# Expected output:
# [+] nuclei: installed
# [+] httpx: installed
# [+] katana: installed
# ... (27 tools total)

Poi dì a Claude cosa testare:```
Run a full WSTG assessment against https://target.example.com

Claude chiederà eventuali informazioni mancanti (come credenziali) e inizierà il flusso di lavoro in 7 fasi.

### Opzione B: Modalità guidata dalla configurazione (Consigliata)

Crea un file di configurazione YAML per valutazioni ripetibili e coerenti:```yaml
# configs/my-target.yaml
target:
  url: https://app.example.com
  scope:
    - app.example.com
    - api.example.com
  exclude:
    - cdn.example.com

authentication:
  login_type: form
  login_url: https://app.example.com/login
  credentials:
    username: [email protected]
    password: secret123
  login_flow:
    - "Type $username into the email field"
    - "Type $password into the password field"
    - "Click the 'Sign In' button"
  success_condition:
    type: url_contains
    value: "/dashboard"

rules:
  avoid:
    - description: "Do not test logout"
      type: path
      url_path: "/logout"
  focus:
    - description: "Prioritize API endpoints"
      type: path
      url_path: "/api"

reporting:
  tester_name: "Security Team"

### Opzione C: Test mirati

Esegui test WSTG specifici contro endpoint specifici:```
Run WSTG-INPV-05 (SQL Injection) against https://app.example.com/search?q=

backends che desideri compilare.```
Run all authentication tests (WSTG-ATHN) against https://app.example.com

---

## Fasi di Test

### Fase 0: Scoperta e Mappatura dell'Applicazione

La fase fondamentale critica. Claude autonomamente:

1. **Controlli pre-flight** — verifica la raggiungibilità del target, rileva reindirizzamenti e autenticazione cross-dominio
2. **Lancia 10+ strumenti in background in parallelo** (katana, ffuf, nuclei, whatweb, gau, nmap, feroxbuster, wapiti, httpx)
3. **Crawling ricorsivo** — segue i link fino alla profondità 2-3, analizza HTML/JS per gli endpoint
4. **Brute-force delle directory** — percorsi comuni + wordlist specifiche per tecnologia
5. **Assorbimento dei risultati degli strumenti** — legge tutti gli output degli strumenti in background e li unisce in una mappa unificata degli endpoint
6. **Costruisce un inventario strutturato degli endpoint** con parametri, requisiti di autenticazione e priorità

**Output:** Una mappa completa degli endpoint organizzata per dominio, pronta per test sistematici.

### Fase 1-2: Ricognizione e Configurazione

- Fingerprinting del server, rilevamento delle tecnologie, revisione dei metadati
- Analisi degli header di sicurezza (HSTS, CSP, CORS, X-Frame-Options)
- Test della configurazione TLS, scoperta di interfacce di amministrazione
- Test dei metodi HTTP, gestione delle estensioni file

### Fase 3: Autenticazione, Autorizzazione e Gestione delle Sessioni

- **Griglia ruoli/privilegi** costruita prima dei test (mappa guardie, middleware e test di bypass)
- Test IDOR con più ID alternativi per endpoint
- Test CSRF su ogni endpoint che modifica lo stato
- Session fixation, hijacking e analisi dei token
- Test vulnerabilità JWT (se applicabile)
- Test debolezze OAuth/OIDC (se applicabile)

### Fase 4: Validazione dell'Input (Impatto Maggiore)

Tre pipeline a due stadi indipendenti vengono eseguite in parallelo, ciascuna con la suddivisione dei ruoli Analyzer→Exploiter:

| Pipeline | Classi di Vulnerabilità | Strumenti | Guide Tecniche |
|----------|-------------------------|-----------|----------------|
| Pipeline XSS | Reflected XSS, Stored XSS, DOM XSS | dalfox, Playwright | XSS, DOM |
| Pipeline Injection | SQL Injection, Command Injection, NoSQL Injection | sqlmap, commix, nosqli | SQLI, CMDI, NOSQLI |
| Pipeline SSRF/SSTI | SSRF, SSTI, Path Traversal | sstimap, ssrfmap | SSRF, SSTI, PTRAV |

Ogni pipeline: **Analizzatore** (scoprire → analizzare → costruire coda di sfruttamento) → checkpoint di validazione → **Exploiter** (tentare sfruttamento → provare impatto → registrare risultati). L'intelligenza di evasione WAF è condivisa tra tutte le pipeline.

### Fase 5: Gestione degli Errori, Crittografia, Logiche di Business, Lato Client e API

- Divulgazione di stack trace e messaggi di errore
- Test TLS/SSL tramite testssl.sh
- Bypass della logica di business (aggiramento del flusso di lavoro, falsificazione di richieste)
- Test lato client (clickjacking, redirect aperti, manipolazione DOM)
- Test GraphQL e API REST
- Analisi della concatenazione delle vulnerabilità tra tutte le scoperte

### Fase 6: Reportistica

- Verifica della copertura (copertura dei test + copertura degli strumenti)
- Deduplicazione delle scoperte e calibrazione della gravità
- Generazione del report in Markdown con sommario esecutivo, scoperte, matrici di copertura

### Fase 7: Revisione Finale del Giudice

Un agente senza contesto esamina l'intero impegno a freddo — nessuna conoscenza delle decisioni di test o delle difficoltà. Esso esamina:

- **Integrità della copertura** — test timbrati, endpoint mancanti
- **Rilevamento di cascate N/A** — categorie con eccessive segnalazioni "non applicabile"
- **Qualità delle scoperte** — completezza delle prove, coerenza della gravità, opportunità di concatenamento
- **Utilizzo degli strumenti** — strumenti eseguiti ma output mai revisionato, motivazioni di salto pigre
- **Superficie d'attacco mancata** — endpoint non testati, parametri non testati, domini non testati

Il verdetto (PASS/CONDITIONAL_PASS/FAIL) attiva azioni correttive specifiche prima che il report venga consegnato.

---

## Strumenti di Sicurezza

### Scoperta e Ricognizione (Fase 0)

| Strumento | Scopo | Flag Principali |
|-----------|-------|-----------------|
| **katana** | Web crawler con rendering JS | `-jc` per crawling JavaScript |
| **httpx** | Sondaggio HTTP, rilevamento tecnologia | `-tech-detect -status-code -title` |
| **ffuf** | Fuzzing directory/parametri | `-w wordlist -mc all -fc 404` |
| **feroxbuster** | Enumerazione ricorsiva delle directory | `--smart --auto-tune` |
| **nuclei** | Scanner vulnerabilità basato su template | `-t cves/ -t misconfigurations/` |
| **nikto** | Misconfigurazione server web | `-Tuning 1234567890` |
| **whatweb** | Fingerprinting tecnologia | `--aggression 3` |
| **nmap** | Scansione porte e servizi | `-sV -sC --top-ports 1000` |
| **gau** | Scoperta URL storici | `--blacklist png,jpg,gif` |
| **subfinder** | Enumerazione sottodomini | `-silent -all` |

### Test di Injection (Fase 4)

| Strumento | Scopo | Flag Principali |
|-----------|-------|-----------------|
| **sqlmap** | SQL injection (tutte le tecniche) | `--batch --risk 3 --level 5` |
| **dalfox** | Scansione e sfruttamento XSS | `--skip-bav --deep-domxss` |
| **commix** | Command injection | `--batch --all` |
| **sstimap** | Server-Side Template Injection | `-u <url>` |
| **ssrfmap** | Sfruttamento SSRF | `-r request.txt` |
| **nosqli** | NoSQL injection | `-u <url>` |
| **crlfuzz** | CRLF injection / HTTP splitting | `-u <url>` |
| **smuggler** | HTTP request smuggling | `-u <url>` |

### Autenticazione e Sessione (Fase 3)

| Strumento | Scopo | Flag Principali |
|-----------|-------|-----------------|
| **hydra** | Brute-force credenziali | `-L users.txt -P pass.txt` |
| **jwt_tool** | Analisi e sfruttamento token JWT | `-t <token> -M at` |

### Crittografia e API (Fase 5)

| Strumento | Scopo | Flag Principali |
|-----------|-------|-----------------|
| **testssl.sh** | Test configurazione TLS/SSL | `--severity HIGH --sneaky` |
| **graphql-cop** | Test sicurezza GraphQL | `-t <url>` |
| **websocat** | Test WebSocket | `ws://<url>` |

### Infrastruttura (Fase 2)

| Strumento | Scopo |
|-----------|-------|
| **corscanner** | Scansione misconfigurazioni CORS |
| **dnsreaper** | Rilevamento takeover sottodominio |

### Automazione Browser

| Strumento | Scopo |
|-----------|-------|
| **Playwright** | Prova DOM XSS, clickjacking, login renderizzato JS, ispezione storage lato client |

---

## Knowledge Base WSTG

109 casi di test in 12 categorie OWASP, ciascuno con procedure specifiche per CLI:

| Codice | Categoria | Test | Esempi |
|--------|-----------|:----:|--------|
| **INFO** | Raccolta Informazioni | 10 | Scoperta motori di ricerca, fingerprinting server, revisione metadati |
| **CONF** | Configurazione e Distribuzione | 14 | Header di sicurezza, CORS, CSP, HSTS, interfacce amministrative |
| **IDNT** | Gestione Identità | 5 | Definizioni ruoli, registrazione, enumerazione account |
| **ATHN** | Autenticazione | 11 | Credenziali predefinite, lockout, bypass autenticazione, MFA, policy password |
| **ATHZ** | Autorizzazione | 5 | Directory traversal, bypass autorizzazione, escalation privilegi, IDOR |
| **SESS** | Gestione Sessioni | 11 | Attributi cookie, CSRF, session fixation/hijacking, JWT |
| **INPV** | Validazione Input | 20 | XSS, SQLi, CMDi, SSTI, SSRF, path traversal, XXE, LDAP |
| **ERRH** | Gestione Errori | 2 | Messaggi errore, stack trace |
| **CRYP** | Crittografia | 4 | Configurazione TLS, padding oracle, crittografia debole |
| **BUSL** | Logica di Business | 10 | Bypass flusso di lavoro, falsificazione richieste, upload file, limiti di frequenza |
| **CLNT** | Lato Client | 14 | DOM XSS, clickjacking, redirect aperti, WebSocket, storage |
| **APIT** | Test API | 3 | GraphQL, REST, SOAP |

Ogni file di test include:
- Procedure CLI passo-passo (comandi curl, invocazioni strumenti)
- Payload organizzati per livello di bypass (base, intermedio, avanzato)
- Criteri di rilevamento con rubriche di valutazione della gravità
- Guida alla correzione con riferimenti

---

## Guide Tecniche PortSwigger

31 guide di riferimento per tecniche di attacco provenienti dalla [PortSwigger Web Security Academy](https://portswigger.net/web-security), organizzate per classe di vulnerabilità per uso diretto durante impegni di pentesting reali.

### Cosa Includono

| Codice | Categoria | Mappatura WSTG | Contenuti Principali |
|--------|-----------|----------------|----------------------|
| **SQLI** | SQL Injection | INPV-05 | Tecniche UNION/blind/error/time-based/OOB, cheat sheet specifici per database (Oracle, MySQL, PostgreSQL, MSSQL), bypass WAF |
| **XSS** | Cross-Site Scripting | INPV-01, INPV-02, CLNT-01 | Contesti reflected/stored/DOM, payload tag & event handler, bypass CSP, evasione filtri |
| **CMDI** | OS Command Injection | INPV-12 | Caratteri separatori, tecniche blind (time-delay, OOB), payload specifici per OS |
| **SSTI** | Server-Side Template Injection | INPV-18 | Rilevamento e sfruttamento Jinja2/Twig/Freemarker/Velocity/ERB, sandbox escape |
| **SSRF** | Server-Side Request Forgery | INPV-19 | Trucchi schema URL, offuscamento IP, DNS rebinding, metadati cloud, bypass filtri |
| **PTRAV** | Path Traversal | INPV-04 | Variazioni di codifica, iniezione null byte, bypass wrapper |
| **XXE** | XML External Entities | INPV-07 | Recupero file, SSRF tramite XXE, XXE blind con OOB, entità parametro |
| **AUTHN** | Autenticazione | ATHN-01 a ATHN-07 | Brute force, bypass 2FA, poisoning reset password, credential stuffing |
| **AUTHZ** | Controllo Accessi | ATHZ-01 a ATHZ-04 | IDOR, escalation privilegi, bypass orizzontale/verticale, controlli basati su referer |
| **JWT** | JSON Web Tokens | SESS-10 | Confusione algoritmo (none/HS256→RS256), iniezione kid, sfruttamento JWK/JKU |
| **OAUTH** | OAuth 2.0 | ATHZ-05 | Furto codice autorizzazione, redirect aperto, upgrade scope, CSRF sui flussi OAuth |
| **CSRF** | Cross-Site Request Forgery | SESS-05 | Bypass token, bypass SameSite, bypass validazione referer |
| **SMUGGLE** | HTTP Request Smuggling | INPV-15 | CL.TE, TE.CL, TE.TE, downgrade HTTP/2, tunneling richieste |
| **DOM** | Vulnerabilità DOM | CLNT-01 | Sorgenti/sink, DOM clobbering, gadget prototype pollution |
| **CORS** | Cross-Origin Resource Sharing | CONF-13, CLNT-07 | Riflessione origine, origine null, sfruttamento fiducia sottodominio |
| **NOSQLI** | NoSQL Injection | INPV-05 | Iniezione operatori MongoDB, iniezione JavaScript, estrazione blind |
| **GRAPHQL** | GraphQL | APIT-01 | Introspection, field suggestion, attacchi batching, bypass autorizzazione |
| **RACE** | Race Conditions | BUSL-04 | Limit overrun, TOCTOU, race a singolo endpoint, last-frame sync |
| **UPLOAD** | File Upload | BUSL-08, BUSL-09 | Bypass estensione, manipolazione content-type, web shell, file poliglotti |
| **HOST** | Host Header Injection | INPV-17 | Poisoning reset password, cache poisoning, SSRF basato su routing |

Più 11 altre: CLICK, WS, CACHEPOIS, CACHEDEC, DESER, INFO, BUSL, PROTO, API, LLM, SKILLS.

### Come Vengono Utilizzate

Le guide tecniche sono integrate in ogni fase di test tramite lo strumento MCP `get_technique_guide()`:```
Phase 2 → CORS guide for CONF-13 testing
Phase 3 → AUTHN, AUTHZ, CSRF, JWT, OAUTH guides for auth/session testing
Phase 4 → SQLI, XSS, CMDI, SSTI, SSRF, PTRAV, XXE guides for input validation
Phase 5 → DOM, CLICK, GRAPHQL, RACE, UPLOAD guides for client-side & business logic

Il risolutore ha due modalità:
- **autopentest** (predefinita): Esegue Claude Code dalla radice del progetto, caricando `.mcp.json` (server MCP con 68+ strumenti) e `CLAUDE.md` (metodologia di pentest). Misura la piena capacità di AutoPentest.
- **raw** (`RAW=1`): Esegue Claude Code nudo, senza server MCP né metodologia. Linea di base per misurare il valore aggiunto di AutoPentest rispetto alla capacità grezza dell'LLM.

Ogni sfida è un'applicazione Docker Compose con una flag iniettata al momento della build. L'estrazione della flag dall'output di Claude determina il superamento/fallimento. I risultati vengono valutati per singola sfida, per tag e per livello di difficoltà.

### Modalità CTF

Per le sfide CTF e le piccole applicazioni, abilita la modalità CTF per limiti di qualità più rilassati:```yaml
mode: ctf
target:
  url: https://target.com

### Esempio di Rilevamento (SQL Injection)

Dal report — un rilevamento critico di SQL injection con prove complete di sfruttamento:```
FINDING-017: SQL Injection in /catalog category parameter — Full Data Extraction

Severity: Critical
WSTG Reference: WSTG-INPV-05

The category parameter is vulnerable to UNION-based SQL injection.
The attacker can:
  1. Inject a single quote to cause a 500 error (confirming injection)
  2. Use UNION SELECT with 8 columns to extract arbitrary data
  3. Enumerate tables: PRODUCTS, TRACKING, USERS
  4. Extract credentials from the USERS table

Evidence (reproducible curl command):
  curl -sk "https://ginandjuice.shop/catalog?category='+UNION+SELECT+1,USERNAME,PASSWORD,
  1,1,USERNAME,1,USERNAME+FROM+USERS+LIMIT+10--"

### Configurazione del Server MCP

Il file `.mcp.json` registra due server MCP:```json
{
  "mcpServers": {
    "wstg-pentest": {
      "command": "uv",
      "args": ["--directory", "./server", "run", "server.py"]
    },
    "playwright": {
      "command": "npx",
      "args": ["-y", "@playwright/mcp"]
    }
  }
}

Tutti i domini vengono automaticamente registrati nell'ambito con il loro tipo (app, auth_provider, api, cdn).

### Test per Dominio

Ogni test WSTG viene valutato per dominio, non solo quello principale:

- Gli strumenti di discovery (katana, ffuf, nuclei) vengono eseguiti su **tutti** i domini
- Gli strumenti di validazione input (sqlmap, dalfox) prendono di mira gli endpoint su **ogni** dominio con elaborazione lato server
- Un test è "non applicabile" solo quando **nessun** dominio ha la funzionalità testata

### Autenticazione Cross-Dominio

Protocolli SSO supportati:
- **OAuth 2.0 / OIDC** (Authorization Code, PKCE, Password Grant, Client Credentials)
- **SAML** (flusso avviato da SP)
- **Keycloak**, **Auth0**, **Okta**, **Azure AD**
- **SSO Personalizzato** (segui il reindirizzamento con cookie jar)

La procedura di escalation dell'autenticazione (6 livelli) garantisce che il test possa procedere anche con flussi di autenticazione complessi.

---

## Ripristino da Crash

AutoPentest è progettato per sopravvivere alle interruzioni:

### Checkpoint Automatici
- I gate di fase salvano automaticamente i checkpoint al superamento
- `git_checkpoint()` crea snapshot git dell'area di lavoro dell'engagement
- I log append-only (`findings.md`, `progress.log`) sopravvivono ai crash

### Ripristino Automatico tramite resume-prompt.md (Consigliato)

Ogni checkpoint e gate di fase genera automaticamente `engagements/<eid>/resume-prompt.md` — un prompt completo e autonomo con tutto ciò che una nuova sessione necessita:

- URL target, credenziali di autenticazione e domini nell'ambito
- Fase corrente e quali test specifici rimangono (precisione a metà fase)
- Stato del cookie jar e istruzioni per la ri-autenticazione
- Regole di evitamento/messa a fuoco e riferimenti alla mappa degli endpoint

**Per riprendere dopo un'interruzione:**
1. Apri una nuova sessione di Claude Code
2. Incolla il contenuto di `engagements/<eid>/resume-prompt.md`
3. Claude riprende esattamente da dove si era interrotto — nessun contesto manuale necessario

### Ripristino da Checkpoint (Alternativo)```
Resume engagement pentest-2026-02-11-myapp

### Rollback in caso di fallimento

Se una fase produce risultati negativi, esegue il rollback al checkpoint precedente:```
Roll back the engagement to the last checkpoint

---

## Requisiti

| Requisito | Versione | Note |
|-------------|---------|-------|
| Docker | 20.10+ | Docker Desktop su macOS/Windows |
| Claude Code | Ultima | `npm install -g @anthropic-ai/claude-code` |
| uv | 0.1+ | `curl -LsSf https://astral.sh/uv/install.sh \| sh` |
| Node.js | 18+ | Per il server MCP Playwright |
| Python | 3.10+ | Gestito da uv (nessuna installazione manuale necessaria) |
| Burp Suite Pro | Ultima | **Opzionale** — per il monitoraggio passivo del traffico |

**Piattaforme supportate:** macOS (Apple Silicon e Intel), Linux (x86_64 e ARM64)

---

## FAQ

**D: Questo sostituisce un penetration tester umano?**

No. AutoPentest automatizza le parti sistematiche e guidate dalla metodologia di un pentest. Eccelle nella copertura (garantendo che nulla venga trascurato) e nella coerenza (ogni test segue la stessa procedura). Tuttavia, la logica aziendale complessa, le catene di sfruttamento creative e la valutazione del rischio dipendente dal contesto beneficiano ancora dell'esperienza umana. Pensalo come un moltiplicatore di forze.

**D: Quanto tempo richiede una valutazione completa?**

Dipende dalle dimensioni e dalla complessità dell'applicazione. Una tipica applicazione web di medie dimensioni (50-100 endpoint) richiede qualche ora. Le applicazioni multi-dominio con SSO richiedono più tempo. L'architettura pipeline della Fase 4 parallelizza i test che richiedono più tempo.

**D: Posso eseguirlo senza Burp Suite?**

Sì. Burp Suite è opzionale e usato solo per il monitoraggio passivo del traffico. Tutte le richieste HTTP passano attraverso `docker exec curl` e tutti gli strumenti di sicurezza vengono eseguiti all'interno del container Docker. Senza Burp, perdi la possibilità di rivedere il traffico nella cronologia del proxy di Burp, ma tutte le funzionalità di test funzionano.

**D: Cosa sono le guide tecniche di PortSwigger?**

31 guide di riferimento sugli attacchi che coprono rilevamento, tecniche di sfruttamento, payload, cheat sheet e pattern di bypass WAF — tratte dalla PortSwigger Web Security Academy. Durante i test, gli agenti caricano automaticamente la guida pertinente (ad esempio, la guida SQLi quando testano per SQL injection) per avere un riferimento completo di tecniche e payload. Consulta [`docs/adding-knowledge-base-resources.md`](https://github.com/bhavsec/autopentest-ai/blob/HEAD/docs/adding-knowledge-base-resources.md) per aggiungere le tue guide personalizzate.

**D: Come posso aggiungere wordlist o payload personalizzati?**

Posiziona le wordlist in `templates/wordlists/` e saranno disponibili all'interno del container Docker tramite il mount del volume. I file di test WSTG in `knowledge-base/` possono anche essere personalizzati con payload aggiuntivi. Per aggiungere nuove guide sulle tecniche di attacco, segui le istruzioni in [`docs/adding-knowledge-base-resources.md`](https://github.com/bhavsec/autopentest-ai/blob/HEAD/docs/adding-knowledge-base-resources.md).

**D: Posso testare applicazioni dietro una VPN?**

Sì. Il container Docker eredita la rete del tuo host (su Linux con `--network host`) o raggiunge l'host tramite `host.docker.internal` (su macOS/Windows). Se la tua VPN è in esecuzione sull'host, il container può raggiungere i target protetti dalla VPN.

**D: Cosa succede se un pentest viene interrotto (crash, limite di utilizzo, timeout)?**

AutoPentest genera automaticamente un file `resume-prompt.md` ad ogni checkpoint con tutto il necessario per continuare. Apri una nuova sessione di Claude Code, incolla il contenuto di `engagements/<eid>/resume-prompt.md` e i test riprendono esattamente da dove si erano interrotti — includendo progressi a metà fase, credenziali, ambito e test rimanenti.

**D: Per quanto riguarda il rate limiting?**

AutoPentest include una classificazione degli errori a tre livelli (Transitorio/Limite di velocità/Permanente) con backoff automatico. Se il target limita le richieste, gli strumenti rallentano automaticamente. Puoi anche impostare regole di evitamento nella configurazione per saltare endpoint specifici.

**D: Quali sono i ruoli degli agenti?**

AutoPentest utilizza 4 ruoli specializzati (Scout, Analyzer, Exploiter, Reporter) invece di sub-agenti generici. Ogni ruolo ha un modello di prompt dedicato con indicazioni mirate sugli strumenti, elenchi di strumenti limitati e anti-pattern. Questo impedisce agli agenti di confondere ricognizione, analisi, sfruttamento e reportistica, migliorando la concentrazione e l'isolamento dei fallimenti. Vedi [`templates/agent-roles/README.md`](https://github.com/bhavsec/autopentest-ai/blob/HEAD/templates/agent-roles/README.md) per l'indice completo dei ruoli.

**D: Come funziona l'evasione WAF?**

Quando un payload viene bloccato (403, pagina di blocco), AutoPentest identifica automaticamente il fornitore del WAF dalle caratteristiche della risposta, quindi carica payload di bypass specifici per il fornitore, organizzati per livello di complessità. Sono supportati 12 fornitori WAF (Cloudflare, AWS WAF, Akamai, Imperva, ModSecurity, F5 e altri). L'intelligence WAF è condivisa tra tutti gli agenti tramite il sistema di deliverable.

**D: Cos'è l'analisi controfattuale?**

Dopo il primo passaggio di analisi che trova vulnerabilità, AutoPentest può generare un secondo Analyzer che assume che tutte le vulnerabilità note siano state corrette. Questo costringe l'agente a cercare vettori di attacco diversi — endpoint diversi, parametri, contesti di injection e difetti logici. I risultati vengono fusi nella coda di sfruttamento esistente con deduplicazione automatica. Questa tecnica si basa su ricerca accademica (studio di ablazione PenHeal) che mostra un miglioramento della copertura delle vulnerabilità del +71%.

**D: Come funziona la verifica dei risultati?**

Quando gli strumenti CLI (nmap, nuclei, sqlmap, ecc.) producono output vuoti o sospetti, lo strumento `verify_tool_result()` rileva problemi comuni (errore proxy, permesso negato, flag errati) e suggerisce comandi corretti. Questo impedisce agli agenti di contare silenziosamente esecuzioni di strumenti non funzionanti come "completate" — una modalità di fallimento comune nel pentesting automatizzato.

**D: Come funziona il concatenamento delle vulnerabilità?**

Il grafo della conoscenza tiene traccia delle entità (endpoint, parametri, risultati, cookie, domini) e delle relazioni scoperte durante i test. Dopo la Fase 4, `find_chains()` utilizza BFS per scoprire percorsi di attacco multi-hop e controlla 7 pattern di concatenamento predefiniti (ad esempio, XSS + CSP mancante, SSRF + metadati cloud, IDOR + ruolo admin). Le catene che aumentano l'impatto attivano aggiornamenti automatici della gravità.

---

## Dichiarazione di non responsabilità

**Questo strumento è destinato esclusivamente a test di sicurezza autorizzati.** Utilizza AutoPentest solo contro applicazioni per le quali hai esplicita autorizzazione a testare. L'accesso non autorizzato a sistemi informatici è illegale. Gli autori non sono responsabili per qualsiasi uso improprio di questo strumento.

Assicurati sempre di avere:
- Autorizzazione scritta dal proprietario dell'applicazione
- Un ambito chiaramente definito di cosa può e non può essere testato
- Una comprensione dell'ambiente di test (produzione vs staging)
- Regole di evitamento appropriate configurate per endpoint distruttivi o sensibili

---

<p align="center">
  Costruito con <a href="https://modelcontextprotocol.io">Model Context Protocol</a>
</p>