Come scrivere un buon report di pentest

#Cos'è un report di penetration test

Un report di penetration test è il documento scritto di un test di sicurezza fatto con il permesso del proprietario. Dice cosa è stato testato, cosa è stato trovato, come un lettore può confermare ogni finding e cosa cambiare. Il test finisce quando il tester smette di inviare richieste. Il report è ciò che il proprietario conserva, condivide con gli sviluppatori e usa per dimostrare che il lavoro è rimasto dentro il perimetro concordato.

NIST SP 800-115, la guida tecnica ai test e alle valutazioni di sicurezza delle informazioni, copre l'intero processo, compresa l'analisi dei finding e lo sviluppo delle strategie di mitigazione. L'OWASP Web Security Testing Guide ha un capitolo Reporting che parte da una struttura del report e da uno schema di denominazione dei finding. Leggili entrambi quando puoi. Questo articolo si concentra sulla parte che scriverai per prima: un report chiaro con un finding che qualcun altro può riprodurre.

#Perché il report conta

Un bug reale che nessuno riesce a riprodurre raramente viene corretto. Gli sviluppatori hanno bisogno di passi da eseguire partendo da uno stato pulito. I manager devono sapere cosa significa il rischio per l'azienda. Gli auditor hanno bisogno della prova che il lavoro ha rispettato il permesso ricevuto. Un solo documento deve servire tutti e tre.

Il report protegge anche il tester. Un perimetro scritto e una registrazione datata di cosa è stato testato mostrano che ogni azione è rimasta dentro il perimetro concordato. Senza quella registrazione, un tester che ha trovato una falla reale può ritrovarsi a discutere se il test fosse consentito.

#Le sezioni di un report

Una struttura pratica ha sei parti:

• Executive summary. Una o due pagine per chi non leggerà il resto. Dice cosa è stato testato, il rischio complessivo, i finding più importanti in parole semplici e le prime azioni da fare. Scrivila per ultima, anche se compare per prima.
• Perimetro e permesso. Host, URL e account nel perimetro, cosa è stato escluso, le date del test, chi ha dato il permesso per il lavoro ed eventuali limiti, come il divieto di test denial-of-service.
• Metodologia. L'approccio e gli strumenti, con le versioni, con dettagli sufficienti perché qualcuno possa ripetere il lavoro. Indica quali controlli sono stati manuali.
• Finding. Una voce per ogni problema, in ordine di gravità. Ogni voce usa lo stesso template.
• Correzioni. I fix raggruppati per proprietario o per tema, con le priorità. Ogni fix ha un controllo che mostra che funziona.
• Appendice. Prove grezze con i segreti rimossi, catture complete di richieste e risposte e un glossario per i termini che il pubblico può non conoscere.

#Scrivere un finding

Ogni finding risponde alle stesse domande, nello stesso ordine.

• Titolo. Qual è la falla e dove si trova. "Cross-site scripting reflected nel parametro search" dice al lettore più di "Vulnerabilità XSS". L'articolo sul cross-site scripting spiega la classe di falla dietro quell'esempio.
• Asset colpito. URL, endpoint, parametro, componente o versione esatti.
• Passi per riprodurre. Passi numerati che uno sconosciuto può seguire da una sessione di browser pulita. Includi la richiesta esatta quando un passo dipende da una richiesta.
• Prove. La dimostrazione che i passi hanno funzionato: uno screenshot o l'output di curl -i, con i segreti rimossi. Numera ogni prova così i passi possono rimandarvi.
• Impatto. Cosa potrebbe fare un attaccante nelle condizioni che hai verificato.
• Gravità. Un vettore CVSS v4.0 e la sua valutazione, calcolati in base a ciò che hai verificato.
• Correzione. Un fix specifico e un controllo che mostra che funziona.

Un finding che il lettore non può riprodurre dalla sola pagina non è finito, per quanto bello sia il titolo.

#Descrivi l'impatto senza esagerare

L'impatto segue le prove. Se hai dimostrato che uno script è stato eseguito nel browser di un account di prova nel tuo laboratorio, scrivi esattamente questo. Una frase come "un attaccante può prendere il controllo di ogni account" senza una dimostrazione è un'esagerazione, e uno sviluppatore se ne accorgerà. Ti costa anche credibilità sul finding successivo. Quando non hai verificato qualcosa, dillo e indica il test che lo confermerebbe.

#L'output dello scanner è una pista, non un finding

Il risultato di uno scanner ti dice dove guardare. Prima che entri nel report, riproducilo a mano, registra la richiesta e la risposta e conferma tu il comportamento. Puoi citare lo scanner come origine della pista. Non incollare il suo output grezzo come prova. Può essere sbagliato, e il lettore non può sapere quali parti ha controllato qualcuno.

#Assegna la gravità con CVSS v4.0

La specifica CVSS v4.0 definisce un gruppo di metriche Base con due lati. Le metriche di sfruttabilità sono attack vector (AV), attack complexity (AC), attack requirements (AT), privileges required (PR) e user interaction (UI). Le metriche di impatto riguardano il sistema vulnerabile (VC, VI, VA) e i sistemi successivi (SC, SI, SA). Una stringa vettoriale inizia con CVSS:4.0 ed elenca ogni metrica base.

Le fasce qualitative di gravità sono None a 0.0, Low da 0.1 a 3.9, Medium da 4.0 a 6.9, High da 7.0 a 8.9 e Critical da 9.0 a 10.0.

I punteggi sono di quattro tipi a seconda dei gruppi di metriche usati: CVSS-B solo per Base, CVSS-BT per Base e Threat, CVSS-BE per Base ed Environmental, CVSS-BTE per tutti e tre. Un primo report di solito ha un punteggio Base, quindi etichettalo CVSS-B e non presentarlo come una valutazione completa del rischio.

Usa il calcolatore ufficiale su https://www.first.org/cvss/calculator/4.0 per costruire il vettore e ottenere il punteggio. Metti nel report il vettore, non solo il numero, così il lettore vede quali ipotesi hai fatto. La stringa qui sotto mostra solo il formato. Non è il punteggio di nessun finding del tuo laboratorio:

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N

Assegna il punteggio a ciò che hai verificato. Se l'attacco dipende da una condizione che non sei riuscito a riprodurre, la metrica deve rifletterlo.

#Oscura i segreti prima di condividere

Le prove contengono spesso cookie di sessione, bearer token, password e dati personali. Toglili prima che il file lasci la tua macchina. Conserva il nome dell'header e la forma del valore, così il lettore può ancora seguire la richiesta:

Cookie: session=<REDACTED>
Authorization: Bearer <REDACTED>

Non incollare un token attivo in una chat, in un ticket o in un repository pubblico, e non fare il commit di un file che ne contiene ancora uno. Se un segreto è stato esposto nel tuo laboratorio, ruotalo comunque e annota la rotazione nel report.

#Pratica: un finding dal tuo laboratorio Juice Shop

Ti serve il container OWASP Juice Shop del tuo laboratorio, in esecuzione sulla tua macchina. Questo esercizio tocca solo quell'istanza locale su 127.0.0.1. Non eseguire nessuno di questi passi su un sito che non è tuo o che non hai il permesso scritto di testare.

#1. Conferma che il laboratorio è locale

Esegui:

docker ps

Guarda la colonna delle porte. La mappatura dovrebbe iniziare con 127.0.0.1, il che significa che solo la tua macchina può raggiungere il servizio. Se vedi 0.0.0.0 o nessun indirizzo, ferma il container e riavvialo con l'indirizzo di loopback nel flag di pubblicazione.

docker run -d -p 127.0.0.1:3000:3000 bkimminich/juice-shop

Poi controlla che il laboratorio risponda:

curl -i http://127.0.0.1:3000

La riga di stato dovrebbe mostrare un codice di risposta di successo. Conserva l'output. Va nella sezione Scope, come prova del target che hai testato.

#2. Scegli un problema che puoi riprodurre

Scegli un comportamento che hai testato nel browser o con una singola richiesta e che puoi descrivere in pochi passi. Tieni il perimetro piccolo. Un finding ben documentato è più utile di otto non verificati.

#3. Cattura le prove

Ripeti la richiesta con curl -i per rendere visibili gli header. Sostituisci il percorso con quello del tuo finding e salva l'output in un file:

curl -i "http://127.0.0.1:3000/<path-you-tested>" > evidence-01.txt

Il flag -i stampa gli header della risposta prima del corpo. Leggi la riga di stato, l'header Content-Type e ogni header da cui dipende il tuo finding. Poi oscura token e cookie nel file prima di farne il commit.

#4. Compila il template

Crea report.md nel repository del laboratorio e usa questo template. Sostituisci ogni segnaposto con ciò che hai osservato davvero:

## Scope

- Target: http://127.0.0.1:3000, my own OWASP Juice Shop container
- Permission: I run this lab on a machine I own
- Dates: <start date> to <end date>
- Out of scope: everything else

## Finding title

<Flaw> in <exact location>

## Steps to reproduce

1. <Start from a clean browser session at http://127.0.0.1:3000>
2. <Exact action or request>
3. <What you see>

## Evidence

<Screenshot file name, or the redacted curl -i output file, matched to the steps>

## Impact

<What you verified. What you did not verify, and the test that would check it.>

## CVSS vector

<CVSS:4.0 vector from the calculator, and its rating>

## Remediation

<The specific fix, and how to check that it works>

#5. Fai il commit del report

Controlla cosa registrerà Git prima del commit, così non scappa un file non oscurato:

git add report.md
git status
git commit -m 'First lab finding'

Conferma il commit con git log --oneline -1. La riga dovrebbe mostrare il tuo messaggio. Quando hai finito, ferma il container del laboratorio con docker stop <container-name>, poi esegui docker ps per confermare che non è più in elenco.

#Errori comuni

• Partire dall'impatto. Scrivi prima i passi, poi decidi cosa dimostrano.
• Passi che dipendono da una sessione che il lettore non ha. Parti da uno stato pulito e dillo.
• Prove senza collegamento ai passi. Numera le prove e cita il numero in ogni passo.
• Incollare l'output dello scanner come prova.
• Scegliere la gravità a sensazione. Usa il vettore e registra le ipotesi che ci stanno dietro.
• Far trapelare segreti in screenshot, log o commit.
• Un fix senza un modo per verificarlo.
• Descrivere un test che non hai eseguito. Il report dice cosa è successo, in ordine.
• Dedicare gran parte del report alla metodologia. La sezione dei finding dovrebbe essere la più lunga.

#Per andare oltre

• Leggi NIST SP 800-115 per intero. Il documento è gratis sul sito del NIST.
• Leggi il capitolo Reporting della WSTG, partendo dalla struttura del report e dagli schemi di denominazione.
• Leggi la specifica CVSS v4.0, metrica per metrica, prima di assegnare il punteggio a un finding importante.
• Dai il tuo finding a qualcuno che non l'ha scritto e chiedigli di riprodurlo usando solo i passi. Se non ci riesce, il finding non è finito.
• Leggi le regole d'ingaggio prima di testare un sistema che non è tuo. L'articolo sulle regole d'ingaggio del bug bounty spiega come i programmi fissano questi limiti.

#Fonti

• NIST SP 800-115, Technical Guide to Information Security Testing and Assessment
• OWASP Web Security Testing Guide, Reporting
• Penetration Testing Execution Standard, Reporting
• FIRST, CVSS v4.0 Specification Document
• FIRST, CVSS v4.0 Calculator