La maggior parte delle violazioni di applicazioni web non inizia con un exploit esotico. Inizia con una richiesta che l’applicazione avrebbe dovuto rifiutare: la fattura di un altro cliente, un prezzo modificato in transito, una reimpostazione della password che si fida dell’header sbagliato. Gli scanner non trovano questi difetti perché non sanno a che cosa serve l’applicazione.
Testiamo come utenti autenticati di ogni ruolo, mappiamo che cosa può raggiungere ciascun ruolo e poi proviamo a superare ogni confine tra un ruolo e l’altro. Gli strumenti automatici coprono le classi note. Il tempo degli specialisti va alla logica, al controllo degli accessi e alle catene di piccole debolezze che, sommate, portano a una compromissione.
01Perimetro
Che cosa testiamo
Autenticazione, sessioni, recupero della password e autenticazione a più fattori
Controllo degli accessi orizzontale e verticale, isolamento dei tenant
Logica di business: pagamenti, sconti, limiti, flussi di lavoro, race condition
Injection: SQL, NoSQL, comandi, template, entità esterne XML
Lato client: cross-site scripting, CSRF, CORS, postMessage, storage del browser
Single sign-on: flussi SAML, OAuth 2.0 e OpenID Connect
Token e URL firmati: gestione dei JWT, scadenza, revoca
Configurazione: header di sicurezza, TLS, gestione degli errori, interfacce esposte
02Approccio
Come si svolge il lavoro
01
Mappatura
Costruiamo una mappa di ruoli, funzioni, flussi di dati e punti di ingresso, comprese le parti dell’applicazione a cui l’interfaccia non rimanda.
02
Baseline automatizzata
Gli scanner e i nostri strumenti coprono le classi di vulnerabilità note, così il tempo del lavoro manuale non viene speso per ciò che una macchina può trovare.
03
Test manuale
Ogni funzione viene testata a mano rispetto ai casi di test OWASP WSTG pertinenti, con particolare attenzione al controllo degli accessi e alla logica di business.
04
Sfruttamento e concatenazione
Una debolezza viene sfruttata fino alla profondità concordata per dimostrare l’impatto reale e viene combinata con altre quando questo porta più lontano.
Grey box come impostazione predefinita: lavoriamo con account e documentazione, perché così si trova di più nel tempo disponibile. Il black box è adatto quando vuoi misurare che cosa ottiene un estraneo senza alcuna informazione. Il white box aggiunge il codice sorgente ed è descritto nella revisione di sicurezza del codice.
Testate in produzione?
Preferiamo un ambiente che corrisponda alla produzione. Se esiste solo la produzione, concordiamo le finestre di test, evitiamo azioni distruttive e lavoriamo con i nostri dati di test.
Uno scanner di vulnerabilità non basta?
Uno scanner trova pattern noti in singole richieste. Non sa che un cliente non deve vedere gli ordini di un altro, né che uno sconto non deve essere applicato due volte. Questi difetti li trovano le persone che capiscono l’applicazione.