WAPT: cosa sapere prima di commissionare un pen test web

Il WAPT è il Web Application Penetration Test: un test in cui qualcuno prova a violare la tua applicazione web prima che lo faccia un estraneo.

Su cos’è si trova scritto parecchio. Quello che manca, quando arrivi al momento di commissionarlo, è tutto il resto. Quanto costa e perché. Cosa devi preparare prima. Cosa ti ritrovi in mano alla fine.

Questo articolo risponde a quelle domande. Per la panoramica sui test di sicurezza c’è la nostra guida al Vulnerability Assessment, e per il confronto generale con il penetration test di rete l’articolo dedicato alle differenze tra VA e PT.

1. Cosa ottieni da un WAPT
2. WAPT o Web Vulnerability Assessment: quale ti serve
3. Cosa determina il prezzo
4. Cosa preparare prima del test
5. Black box, grey box, white box: come scegliere
6. Cosa succede dopo il report
7. Quando l’applicazione non è tua
8. Gli errori che rendono inutile un WAPT
9. Domande frequenti

Cosa ottieni da un WAPT

Alla fine di un WAPT hai un documento che dice: da questo punto, con questi passaggi, si arriva a questi dati.

È diverso da un elenco di avvisi. Uno scanner segnala che un parametro sembra vulnerabile. Un WAPT mostra che da quel parametro si legge la tabella degli utenti, e ti dice come riprodurlo.

Quella dimostrazione è il prodotto che stai comprando. Serve a chi sviluppa per correggere, serve a te per decidere cosa sistemare prima, e serve in audit come prova che la verifica è stata fatta davvero.

Il perimetro è l’applicazione: pagine, parametri, sessioni, API, ruoli utente. Server, firewall ed endpoint restano fuori, e per quelli servono un test sulla rete interna e un intervento di network security.

WAPT o Web Vulnerability Assessment: quale ti serve

Questa è la prima domanda da risolvere, perché sbagliarla significa pagare per la cosa sbagliata.

Ti serve un Web Vulnerability Assessment se vuoi una fotografia periodica, ampia, da ripetere spesso. Copre tanto, costa poco, non tocca l’applicazione. È il controllo di routine.

Ti serve un WAPT se devi sapere cosa un attaccante riesce a fare per davvero. Va in profondità su meno cose, richiede lavoro manuale e agisce sull’applicazione. È l’esame approfondito.

La regola pratica che uso quando me lo chiedono: assessment con cadenza regolare, WAPT nei momenti che contano. Prima di pubblicare, dopo un rifacimento, quando l’applicazione inizia a trattare dati delicati.

Se il quadro da chiarire è ancora più a monte, cioè cosa proteggere e con che priorità, il punto di partenza è il risk assessment. E se ti stai chiedendo cosa ci guadagna l’azienda da tutto questo, ne abbiamo parlato nei benefici del Vulnerability Assessment.

Cosa determina il prezzo

Un WAPT non ha un listino, e chi te lo quota a scatola chiusa sta tirando a indovinare. Il preventivo dipende da cinque cose.

1. Il numero di funzioni. Non le pagine: le funzioni. Un sito vitrina da quaranta pagine si testa in poco. Un portale con registrazione, area riservata, caricamento file e pagamenti ha dieci volte il lavoro, anche se le pagine sono meno.
2. I ruoli utente. Ogni ruolo va testato e incrociato con gli altri. Con tre ruoli le combinazioni da verificare non sono tre: sono tutte le coppie possibili, perché il problema più frequente è l’utente che raggiunge i dati di un altro.
3. Le API. Se l’applicazione espone interfacce usate da app mobile o da sistemi esterni, sono un perimetro a sé. Vanno dichiarate nel preventivo, altrimenti non sono nel prezzo.
4. L’ambiente disponibile. Con un ambiente di collaudo il test è più libero e veloce. Solo produzione significa più cautela, più concordamento e più tempo.
5. La modalità. Black box costa meno e trova meno. White box costa più e trova più.

Il paragone utile è con il costo dell’alternativa. Nell’articolo su quanto costa un data breach abbiamo messo in fila le voci di un incidente, e il confronto con un preventivo di test non regge il paragone. Se vuoi una quotazione concreta puoi partire dal nostro modulo per il preventivo.

Cosa preparare prima del test

Questa è la parte che nessuno racconta e che decide se il test riesce o si impianta al secondo giorno.

• Un’autorizzazione scritta
  Serve sempre, e serve firmata da chi ha titolo per darla. Un test non autorizzato su un’applicazione è un accesso abusivo, anche se lo commissiona un dipendente in buona fede.
• Le utenze di prova
  Una per ogni ruolo, create per il test e non riciclate da account reali. Se il tester deve lavorare con l’utenza di un cliente vero, metà delle verifiche diventa impraticabile.
• L’ambiente
  Se esiste un collaudo allineato alla produzione, è lì che si lavora meglio. Se si testa in produzione, servono backup verificato e una finestra concordata.
• L’avviso a chi gestisce l’infrastruttura
  Hosting provider, eventuale firewall applicativo, sistemi di protezione. Il traffico di un WAPT somiglia a un attacco, e senza preavviso rischi che l’IP del tester venga bloccato dopo venti minuti. Se hai un servizio di web security attivo o l’applicazione sta in cloud, va verificato cosa prevede il contratto.
• Un riferimento tecnico raggiungibile
  Durante il test arrivano domande, e se restano senza risposta per due giorni il tempo si spreca. Di solito è il responsabile IT, insieme a chi ha scritto l’applicazione.

Un consiglio in più: tieni attivo il monitoraggio durante il test. Vedere cosa i tuoi sistemi registrano mentre qualcuno li attacca è un modo gratuito per scoprire se il monitoraggio dei log funziona. Capita che il WAPT non rilevi falle gravi ma mostri che nessuno si è accorto di niente, e quello è un risultato utile quanto una vulnerabilità trovata.

Black box, grey box, white box: come scegliere

Le tre modalità sono note. Il criterio di scelta, molto meno.

• Black box se vuoi misurare l’esposizione verso l’esterno, tipicamente su un’applicazione appena pubblicata.
• Grey box se hai utenti autenticati. È la scelta giusta nella maggioranza dei casi, perché il rischio concreto non è l’estraneo che entra: è l’utente registrato che arriva dove non dovrebbe.
• White box se sviluppi in casa e vuoi trovare il massimo. Con codice e documentazione in mano il tester vede quello che dall’esterno resterebbe invisibile.

La domanda da farsi non è quale sia il test migliore, ma quale rischio ti preoccupa. Chi sviluppa software trova conveniente affiancare alla scelta anche l’analisi statica e dinamica del codice, cioè SAST e DAST. E per capire come si articola un pentest indipendentemente dalla modalità c’è il nostro pentest passo per passo.

Cosa succede dopo il report

Il report non è la fine del lavoro. È l’inizio della parte che conta, e conviene averla pianificata prima di iniziare.

• Si ordinano le correzioni
  Non per gravità teorica, ma per gravità incrociata con lo sforzo. Tre falle critiche risolvibili con un aggiornamento vengono prima di una critica che richiede di riscrivere un modulo.
• Si decide chi corregge
  Se l’applicazione è di terzi, va aperto un ticket al fornitore, e i tempi non li decidi tu. Se è interna, entra nella pianificazione dello sviluppo.
• Si verifica
  Il retest sui punti corretti va messo nel contratto insieme al test, non chiesto tre mesi dopo come favore. Senza verifica non sai se la correzione ha funzionato, e capita spesso che una patch chiuda il sintomo e lasci aperta la causa.
• Si programma il prossimo
  Non esiste un WAPT definitivo. Ogni rilascio rimette in gioco il risultato, e nel frattempo escono vulnerabilità nuove sui componenti che usi: sono catalogate nel National Vulnerability Database e si tengono sotto controllo con un patch management ordinato.

Quando l’applicazione non è tua

Capita più spesso di quanto si pensi: il gestionale è di un fornitore, l’e-commerce è su una piattaforma, mezzo sito sta su plugin scritti da altri.

La regola è semplice. Puoi testare quello che controlli, non quello che usi. Su un servizio in abbonamento il contratto stabilisce cosa è consentito, e molti fornitori vietano esplicitamente i test o chiedono un’autorizzazione preventiva.

Questo non ti lascia senza opzioni. Puoi testare la tua configurazione, le personalizzazioni che hai aggiunto, i plugin installati e il modo in cui l’applicazione si integra col resto. Che è anche dove si trovano le falle più frequenti, perché il codice del fornitore lo guardano in molti, la tua configurazione nessuno.

Puoi inoltre chiedere al fornitore il suo report. Se sviluppa software per aziende, un WAPT recente dovrebbe averlo, e la domanda è legittima: è la stessa che i tuoi clienti fanno a te, come spieghiamo nell’articolo sui motivi strategici per fare un VAPT. Sul fronte normativo la direttiva NIS2 ha reso queste verifiche sulla catena di fornitura un tema concreto anche per le PMI.

Gli errori che rendono inutile un WAPT

Cinque modi per spendere e non ottenere niente.

1. Perimetro definito male
   “Testate il sito” non è un perimetro. Senza l’elenco di domini, sottodomini, API e funzioni da coprire, il tester lavora su ipotesi e tu paghi per un risultato parziale.
2. Nessuna utenza autenticata
   Un WAPT fatto solo da fuori guarda la vetrina. Le falle serie stanno dietro il login.
3. Report che non arriva a chi sviluppa
   Resta al reparto IT, chi ha scritto il codice non lo legge, le correzioni non partono. È lo spreco più comune di tutti.
4. Correzioni mai verificate
   Senza retest hai il report di un’applicazione che non esiste più, e nessuna certezza su quella attuale.
5. Trattarlo come un bollino
   Un WAPT non certifica niente e nessuno può certificare la sicurezza di un’applicazione. Documenta come si è comportata in quel momento, con quel perimetro. Diffida di chi ti promette un certificato: OWASP pubblica metodologie e classifiche, non rilascia attestati.

Se l’incidente è già avvenuto, il test non è la prima cosa da fare. Prima serve capire cosa è successo, e su quello abbiamo scritto cosa fare quando l’azienda è stata violata.