Ricordo che eravamo in Algarve, per l’Owasp Summit del 2008. Ricordo che, parlando di Owasp Orizon, Dinis Cruz fece un’analogia tra l’output dei tool dei nostri arsenali e quello schermo tattile che Tom Cruise usa in Minority Report.

Lo strumento ideale deve indizi; deve permettermi di fare dei collegamenti, di vedere dove si nasconde la vulnerabilità.

Sono passati 8 anni e nessuno strumento, che conosco, che utilizzo e che sviluppo, è andato verso quella direzione. Anzi. I grossi player di mercato, non hanno ancora inserito nei loro team qualcuno che si occupi di design e di usabilità.

Quando WebInspect finisce il suo lavoro, sinceramente penso di essere ancora nel 2001. Lo stesso dicasi per Fortify ad esempio. Nel caso del tool di code review è ancora peggio, perché in un prodotto stabile, è stato mischiato un pezzo di UI nuova ad un pezzo di UI vecchia, con la sensazione per l’utente di essere nel mezzo di un beta testing.

Idem con patate il mio caro Nexpose. La parte di interfaccia dei report, per un anno almeno, è stata non coerente con il resto dello strumento.

L’analista non deve avere risposte assolute dallo strumento, deve avere indicatori.

Al netto poi dell’usabilità, i tool di code review partono con l’assunto presuntuoso di volermi dare la soluzione esatta al mio problema.

All’ipotetica domanda “voglio uno strumento che mi aiuti nel fare (code review || pentest || antani)”, la risposta di chi fa vendita è “prova il mio, è 0% false positive free”.

Quando gli chiedi una comparazione con gli altri, difficile avere qualcosa di usabile. Gli altri fanno tutti schifo.

Ora, per me che hpo un po’ di esperienza e qualche nome, l’ho provato in questi anni, magari è semplice scegliere, ma per la persona che si occupa di #appsec per caso nella propria azienda? Come riesce, non solo a scegliere, ma poi a fruire dei risultati dello strumento se sono ancora troppo legati al risultato tecnico?

Che poi, l’infallibilità di un software nel rilevare difetti di un altro software, non solo è poco probabile, ma anche impossibile.

L’interfaccia grafica e la mancanza di comunicazione tra strumenti non rendono facile il lavoro di analisi. Io devo essere libero di scegliere il tool che preferisco, perché un vendor sarà più bravo a fare una cosa rispetto ad un altro e viceversa. I tool, in un mondo ideale, dovrebbero poter condividere risultati che mi rendano semplice intersecare i dati.

Mettiamo ad esempio che io voglia usare Burp e Fortify su un progetto. Io devo avere una dashboard unica, che mi mostra il flusso dei dati rilevato durante l’analisi dinamica associato al codice sorfente che viene attraversato. L’analista non deve avere risposte assolute dallo strumento, deve avere indicatori. Gli strumenti devono dargli dei sospetti circa la presenza di una vulnerabilità o di un problema più complesso.

Durante anni di analisi, partendo da un finding di severità alta sono arrivato a ricondurre il tutto ad un input non filtrato che però non era sfruttabile, mentre vulnerabilità di severità medio o bassa che sono diventate delle session fixation. Perché questo? Perché l’esperienza di chi analizza non è un qualcosa che può essere sostituito, mentre il tool dovrebbe limitarsi ad evidenziare sospetti o punti che poi devono essere approfonditi.

Ho sinceramente visto troppi report generati in automatico pieni di Null pointer dereference, marchiati come High severity. Lì mi accorgo se il fornitore mi ha rubato i soldi e quanto il grado di competenza. Anche perché, quando poi chiedi in quale condizioni si attiva quella dereferenziazione, le risposte sono imbarazzanti, quando arrivano.

Poi è chiaro, ci sono pattern di sviluppo che non danno troppo spazio all’immaginazione. Leggi qualcosa dalla richiesta http e lo usi così com’è, il codice è vulnerabile a cross site scripting. In questo caso che si fa? Il tool: “si filtra l’input!” E lo sviluppatore ci chiede: “come?” Ed il tool ci risponde: “si filtra l’input!”

Pochi strumenti danno dei suggerimenti per la remediation che possano essere fruibili. Nessun strumento ad esempio mi da già la regola da applicare in mod_security per fare virtual patching. Rilevo una SQL Injection in produzione, non me n’ero mai accorto. Secondo lo strumento cosa dovrei fare? Metto offline un portale in produzione, che magari è parte del mio business? Difficilmente accadrebbe. Più semplice tirar su mod_security al volo e fare virtual patching mentre gli sviluppatori mettono la patch in sviluppo e collaudo.

Vedo 3 problemi grossi:

• i tool non cooperano tra di loro
• i tool sono focalizzati sul finding e non mi rendono semplice vedere lo scenario più grande
• i tool hanno una UI indietro di 20 anni.

Grandi problemi, grandi opportunità.

Enjoy it!