In genere, sulle applicazioni Web possono essere eseguiti due tipi di test di sicurezza: analisi statica e analisi dinamica.
Inoltre, ci sono poi due metodi per eseguire tali test: automatico e manuale.
Analisi dinamica
L’analisi dinamica, che comporta l’esecuzione di prove mentre l’applicazione esegue una determinata istanza, è nota anche come test della scatola nera (black box). Il test di sicurezza prevede che siano inviate alcune richieste all’applicazione e che siano osservate le risposte per verificare se esiste una qualsiasi indicazione che possa essere presente una vulnerabilità di protezione.
L’analisi dinamica può essere un modo efficace per testare le applicazioni, ma è importante sapere che esistono alcune limitazioni. Prima di tutto, poiché il test è basato sull’analisi di modelli di domanda e risposta, i risultati ottenuti sono soltanto un’ipotesi sulla situazione interna dell’applicazione (in genere, il tester non è a conoscenza del codice sorgente che sta alla base dell’applicazione e di quello che effettivamente è l’attuale stato interno dell’applicazione stessa).
Inoltre, dato che il tester sta solo valutando il comportamento osservabile dell’applicazione e non può conoscere ciò che accade sull’intera superficie di attacco, esiste la possibilità che certe aree dell’applicazione e certe componenti delle sua funzionalità siano escluse dalla prova. Per altro, anche determinate risposte, ovviamente, non potrebbero indicare se è presente una vulnerabilità di sicurezza. Questi fattori portano alla possibilità di individuare falsi negativi, situazioni in cui vi è una vulnerabilità di sicurezza che passa inosservata e non è dichiarata.
A sua volta, l’analisi dinamica può essere eseguita in modo automatico o manuale. Tool per la scansione delle applicazioni Web, come quelli realizzati da Watchfire e SPI Dynamics, sono buoni esempi di strumenti per l’analisi automatizzata dinamica.
Questi tool consentono di individuare molte delle più diffuse vulnerabilità, come l’SQL injection e il cross-site scripting (XSS), e spesso sono anche usati per cercare noti problemi sicurezza o di configurazione nei Web server e negli application server e nei sistemi operativi delle applicazioni che stanno testando. I report forniti da questi tool rivelano aspetti importanti, come la non avvenuta installazione di patch critiche. Ciò può però portare solo all’identificazione dei difetti tecnici nell’applicazione.
I tool automatizzati sono limitati, perché non si curano della logica di business che sta alla base delle applicazioni testate: vengono perciò trascurati comuni difetti logici nelle applicazioni che possono potenzialmente essere altamente dannosi. Questo è un punto importante per le organizzazioni che implementano applicazioni di sicurezza – anche se lo scanner dice che tutto va bene è necessario guardare più in profondità, al fine di eseguire un lavoro credibile nell’assicurare la sicurezza delle applicazioni.
Il test manuale delle applicazioni Web è solitamente eseguito utilizzando un browser e un proxy Web, come accade con i tool Paros o WebScarab di OWASP. I tool commerciali di scansione sono in genere venduti con integrato un proxy in modo che l’analista che usa tali scanner possa rendere più significativi i risultati della scansione attraverso il test manuale. I proxy consentono al tecnico di sicurezza di creare e inviare richieste arbitrarie all’applicazione e verificare i risultati al fine di visualizzare i più evidenti problemi di vulnerabilità. Come già detto in precedenza, questi test manuali sono necessari per rendere credibile un’application security assessment che preveda la ricerca di un’eventuale perdita di dati, di errori nelle autorizzazioni delle attività e così via.
Analisi statica
Quando viene eseguita l’analisi dinamica durante l’installazione di una applicazione, l’analisi statica prevede il riesame degli asset di tale applicazione, come il codice sorgente, i file di configurazione e così via, quando questi sono statici o in stand by. Questa operazione è nota anche come analisi del codice sorgente o test della scatola bianca.
Perché l’analisi venga effettuata bisogna accedere al codice sorgente. In questo caso, i tecnici non devono osservare il comportamento di un’applicazione e fare congetture circa la situazione interna del sistema, ma hanno accesso alle effettive istruzioni che il software eseguirà quando sarà messo in produzione. Questo può aiutare a limitare i falsi positivi e i falsi negativi. Uno svantaggio inerente l’analisi statica è che può fallire nell’individuazione dei problemi di sicurezza legati in modo specifico alla configurazione del sistema implementato: per esempio, l’analisi statica non è in grado di individuare i problemi che potrebbero sorgere a causa della dimenticanza da parte degli amministratori di installare le patch nel Web Server o nel sistema operativo.
Solo con il test dinamico o della scatola nera, l’analisi statica può essere effettuata sia dai tool di revisione automatici sia da quelli manuali. Perché applicazioni non banali possano avere decine o centinaia di migliaia – o addirittura milioni – di linee di codice sorgente, le revisioni manuali sono tipicamente condotte solo su un sottoinsieme del codice sorgente dell’applicazione, che è considerato critico per la sicurezza.
I tool automatizzati di analisi statica, come quelli di Fortify Software e Ounce Labs, offrono il vantaggio di poter essere eseguiti su grandi basi di codice sorgente e l’analisi viene costantemente effetturata sull’intera base del codice sorgente. I tool automatici per l’analisi statica possono eseguire solo un insieme di regole in grado di cercare difetti inerenti qualità e sicurezza di carattere generale; non sono in alcun modo in grado di comprendere il contesto dell’applicazione né delle regole di business che dovrebbero essere fatte rispettare. Per questo motivo, i tool automatizzati di analisi statica mostrano la stessa cecità nei confronti dei difetti nelle applicazioni che mostrano i loro equivalenti dell’analisi dinamica. Sono invece molto efficienti nell’individuare difetti come l’SQL injection, il cross-site scripting e il buffer overflow, ma non mostrano la stessa efficacia in altre aree critiche.
Conclusioni
L’effettiva analisi della sicurezza delle applicazioni Web spesso combina una o più delle tecniche precedentemente elencate e definisce su quali fattori basarsi, come le risorse disponibili, per effettuare la valutazione e accedere al codice sorgente o ai sistemi in funzione che possono essere usati per il testing.
L’esecuzione di una scansione automatica del codice sorgente o l’esecuzione di applicazioni può essere un modo relativamente economico per avere un’idea della situazione della sicurezza del sistema, ma non è in grado di identificare difetti nella logica dell’applicazione sopra descritta. In molte organizzazioni, può essere difficile ottenere l’accesso al codice sorgente dei sistemi in uso perché è considerato altamente proprietario. In casi come questi, potrebbe essere effettuata solo un’analisi dinamica.
Viceversa, per vari motivi in altre organizzazioni può essere inaccettabile eseguire test sui sistemi “live” e potrebbero non essere disponibili basilari istanze di pre-deployment delle applicazioni. In questi casi, l’analisi statica sarebbe l’unica opzione.
La revisione manuale sia delle applicazioni “live” sia del codice sorgente può diventare molto costosa per le grandi applicazioni, perciò deve essere assolutamente mirata. È fondamentale per le imprese comprendere gli obiettivi della propria valutazione della security e del livello di garanzia della sicurezza di cui hanno bisogno. In funzione di ciò, e delle risorse disponibili, va quindi selezionata una strategia di test delle applicazione in grado di raggiungere gli obiettivi prefissati.
