Black box, gray box e white box indicano quanto conosce il tester. Scopri cosa verificano, quali limiti hanno e come scegliere il modello del pentest. I tre termini descrivono l'accesso alle informazioni, non il comportamento etico del professionista. Un pentest black box può essere pienamente autorizzato; un test white box non coincide con l'espressione white hat. La guida ai penetration test offre il contesto generale, mentre il confronto tra white hat ed ethical hacker chiarisce i ruoli. Black box: partire con poche informazioni Il tester dispone di informazioni interne limitate e osserva il sistema dal punto di vista previsto nell'incarico. Può essere utile per verificare una superficie pubblica e la qualità dei controlli esposti. Una parte del tempo viene impiegata a comprendere componenti e funzionalità. Il limite da gestire è la copertura: con pochi giorni e senza account, non puoi assumere che tutti i flussi riservati siano stati esaminati. "Nessun problema trovato" deve sempre essere letto insieme a ciò che il tester ha potuto raggiungere. Gray box: informazioni e accessi selezionati Si consegnano alcuni elementi, per esempio utenti di prova, ruoli, una descrizione del servizio o documentazione delle API. Questo permette di concentrarsi su domande specifiche senza dedicare l'intero incarico alla scoperta del sistema. Esempio: un portale ha i ruoli cliente e operatore. Due coppie di account di prova consentono di verificare la separazione fra utenti e fra privilegi. Il risultato risponde a una domanda diversa da quella di un semplice controllo del sito pubblico. Conta quindi descrivere esattamente cosa il tester riceve: il nome gray box non basta. White box: rendere disponibili dettagli interni Il tester può ricevere codice, configurazioni, diagrammi e altre informazioni concordate. L'accesso interno aiuta a capire perché un controllo funziona o fallisce e a indirizzare meglio la verifica. La guida di stile OWASP distingue i modelli in base alla conoscenza del sistema, includendo il codice nel contesto white box. È importante separare la disponibilità del codice dal lavoro effettivamente acquistato. Se nessuno svolge una revisione sistematica, la sola consegna del repository non trasforma un pentest in un audit completo del sorgente. Come scegliere senza cercare una graduatoria assoluta Parti da tre domande: quale scenario vuoi verificare, quali informazioni puoi condividere e quanto tempo hai. Per un'applicazione interna, offrire ruoli di prova può aumentare la copertura utile. Per una superficie pubblica, una prima fase con informazioni limitate può rispondere alla domanda di esposizione. È possibile combinare modelli: prima osservazione esterna, poi verifica autenticata e infine approfondimento di configurazione. Pianifica questi passaggi senza presentarli come equivalenti. La WSTG OWASP offre aree di verifica da adattare all'applicazione. Prima di accettare il preventivo, chiedi quali account, documenti e componenti verranno utilizzati e come saranno dichiarate le limitazioni. Metti queste informazioni nelle regole d'ingaggio. Per vedere una scelta concreta, prosegui con il pentest di applicazioni web e API; per valutare il risultato consulta la guida al report e retest.