Penetration Test
Attacchiamo la tua applicazione. Con il tuo permesso, e per scritto.
Se un'applicazione tratta dati o pagamenti, qualcuno la proverà
Serve a chi ha un'applicazione web, un portale clienti, un gestionale raggiungibile da internet o un e-commerce.
Meglio che il primo a provarci siamo noi.
Perché non basta uno scanner
Gli strumenti automatici trovano le configurazioni sbagliate e le versioni vecchie. Le vulnerabilità che fanno davvero danno — una logica di autorizzazione scritta male, un identificativo che si può cambiare a mano — le trova solo una persona che prova.
Usiamo Burp Suite, ma la parte che conta è manuale.
Ogni problema che troviamo, lo dimostriamo
Seguiamo la OWASP Web Security Testing Guide, insieme a OWASP Top 10, ASVS e NIST SP 800-115. Non scriviamo «questo parametro potrebbe essere vulnerabile»: alleghiamo la richiesta HTTP che lo sfrutta e la risposta del server che lo conferma.
Regole d'ingaggio
Perimetro, limiti e finestra temporale concordati per iscritto prima di iniziare.
Test
Da tre a cinque giorni su un'applicazione di dimensioni normali. Restiamo raggiungibili per tutta la durata.
Prova
Per ogni finding, richiesta e risposta HTTP complete: il tuo sviluppatore riproduce il problema in un minuto.
Piano di correzione
Cosa sistemare entro 7 giorni, entro 30, entro 90.
Un documento che il tuo sviluppatore può seguire
Molte aziende lo usano anche come prova nei questionari di sicurezza che ricevono dai propri clienti.
- Finding per gravità: Critical, High, Medium, Low, con punteggio CVSS
- Prova di sfruttabilità per ognuno: richiesta e risposta HTTP
- Piano di correzione con tempi e priorità
- Sintesi per la direzione, senza gergo
- Ritest dopo le correzioni
Come si quota
Dipende da quante applicazioni, quante aree riservate hanno e se esiste un ambiente di collaudo su cui lavorare.
Un gestionale con tre ruoli utente diversi richiede più lavoro di un sito vetrina con un modulo di contatto. Si definisce dopo una call.
Chiedi un preventivoQuello che ci chiedono sempre
Il perimetro e i limiti si concordano per iscritto prima di iniziare. Dove possibile lavoriamo su un ambiente di collaudo. In produzione escludiamo i test distruttivi e restiamo raggiungibili per tutta la durata del test.
Dipende da cosa vuoi sapere. Senza credenziali vediamo quello che vede un estraneo. Con credenziali di prova vediamo anche cosa può fare un utente registrato che decide di andare oltre — che nella pratica è lo scenario che produce i danni peggiori.
Per un'applicazione di dimensioni normali, da tre a cinque giorni di test più due di stesura del report. Le date si concordano insieme.
Sì. È un documento firmato da FD Consulting con metodologia e riferimenti dichiarati. Molte aziende lo usano come prova nei questionari di sicurezza dei fornitori.
La tua applicazione regge un attacco vero?
L'unico modo per saperlo è provarci. Meglio con qualcuno che poi ti spiega come chiudere le porte.