L’adozione in ambito aziendale di applicazioni o basate sul Web siti complessi introduce nuovi scenari per quanto riguarda la sicurezza dei dati. L’uso di linguaggi di programmazione dinamici e la diffusione di servizi distribuiti per l’autenticazione e la gestione dei dati rende necessario includere, nel ciclo di sviluppo di una applicazione web complessa, strumenti di analisi della sua sicurezza applicativa.
Un amministratore di sistema dovrebbe, nel momento in cui adotta per la propria azienda un applicativo web, operare un’analisi approfondita delle possibili vulnerabilità cui va incontro. Sottovalutare l’hardening applicativo rischia di sottoporre l’intera struttura a rischi critici, permettendo ad un attaccante di sfruttare le web application per eseguire azioni fraudolente sull’intera rete aziendale, rendendo in molti casi inutile la presenza di sonde di monitoraggio, firewall e nid.
Cos’è un WAPT
Le applicazioni web interagiscono con l’utente ricevendo in ingresso dati non complessi che vengono elaborati, a volte correlati, a volte cifrati, e forniti a tecnologie sottostanti quali application server e database relazionali o servizi di vario genere come gateway, server smtp, server proxy e così via.
La fase di elaborazione del dato, oltre alla funzione per cui è stata definita, deve prevedere necessariamente una verifica dell’input fornito dall’utente sull’applicazione, sia per quanto riguarda la consistenza del dato sia per quanto riguarda l’epurazione dell’input da codice nocivo che potrebbe alterare il comportamento o l’aspetto dell’applicazione in modo non previsto.
Un WAPT (web applications penetration test) è un test di valutazione della sicurezza di una web application basato sull’individuazione e la valutazione di eventuali problematiche (vulnerabilità) legate esclusivamente all’ambito della sicurezza.
Per vulnerabilità si intende una debolezza che qualora sfruttata da una eventuale minaccia possa compromettere l’integrità o la confidenzialità o la disponibilità del dato, generando un evento rilevante ai fini della sicurezza. Un evento rilevante ai fini della sicurezza è un’alterazione nel comportamento e/o nell’aspetto dell’applicazione dovuto allo sfruttamento di una vulnerabilità.
Nonostante non vi sia attualmente uno standard riconosciuto in vigore per l’esecuzione di un WAPT, il progetto OWASP (The Open Web Application Security Project) fornisce numerose linee guida e documentazione sulle procedure di analisi e sfruttamento delle vulnerabilità. Questo consente di adottare una metodologia di testing con cui affrontare in modo sistematico e completo la corretta implementazione delle numerose tecnologie che possono trovarsi all’interno di una pagina web.
Un WAPT è composto da quattro fasi fondamentali:
- Studio dell’applicazione.
- Ricerca delle vulnerabilità.
- Definizione del rischio per ogni vulnerabilità riscontrata.
- Compilazione della documentazione per il gruppo di sviluppo e per il cliente.
Nei prossimi paragrafi si definiranno gli ambiti metodologici di verifica whitebox e blackbox, per poi prendere in esame un’applicazione web ricreando un possibile scenario di verifica. Seguirà infine l’approccio all’analisi del rischio delle web application.
L’ambito metodologico di verifica
Il WAPT può essere eseguito in ambito blackbox (o zero knowledge che dir si voglia) o in ambito whitebox (full knowledge). La differenza è sostanziale e prevede un differente approccio del penetration tester (colui che esegue il test) alla verifica dell’applicazione.
Ambito whitebox
Il WAPT viene condotto tramite visione delle specifiche funzionali e del codice sorgente dell’applicazione, ricercando le vulnerabilità legate al linguaggio impiegato per lo sviluppo dell’applicazione e le vulnerabilità architetturali tipiche di una web application.
Dovrebbe essere adottato come integrazione del ciclo di vita del software, andandosi a collocare subito dopo le fasi di progettazione e scrittura del codice, esattamente nella fase di collaudo precedente alla messa in esercizio nell’ambiente di produzione.
Requisiti
Assegnare il testing del software ad un programmatore che non appartenga al team di sviluppo: gli errori commessi durante la stesura del codice spesso non sono dovuti a semplice distrazione ma a convinzioni errate di sviluppo, soprattutto per quanto concerne la sicurezza.
Pro
- È possibile individuare tutti i possibili bug che affliggono l’applicazione.
- Automatizzando la procedura di verifica si riesce ad ottenere un notevole vantaggio in termini di tempo rispetto alla verifica blackbox.
- Semplifica il passaggio dalla fase di “debugging” a quella di correzione del codice grazie all’individuazione del segmento di codice che ha avuto rilevanza ai fini della sicurezza.
Contro
- Difficilmente un buon programmatore accetta di buon grado di fare del testing.
- Questo tipo di ambito non è applicabile a tutte le tipologie di sviluppo, particolarmente per motivi di segretezza del business.
- I richiami a funzioni contenute in librerie compilate la cui realizzazione è stata eseguita da terze parti non sono analizzabili (se non tramite reverse engineering).
