L‘articolo vuole essere una breve introduzione nel mondo della sicurezza delle “Web applications” tramite la presentazione del consorzio OWASP e dei suoi obiettivi. Per rendere il tutto più comprensibile utilizzeremo WebGoat, un‘applicazione insicura creata allo scopo e il praticissimo proxy HTTP WebScarab.
Che cosa è OWASP
L‘Open Web Application Security Project (OWASP) è una community open-source diretta a diffondere la conoscenza sulle vulnerabilità delle applicazioni web indotte da sviluppo di codice non sicuro [1].
La community ha il supporto organizzativo della Foundation no-profit omonima, che coordina i lavori e definisce le regole tramite cui partecipare, a diverso titolo, ai singoli progetti. Questi si concretizzano in articoli, metodologie, strumenti, resi disponibili liberamente a tutti, indipendentemente dal grado di partecipazione attiva alla community.
Tra le attività di rilievo che hanno contribuito alla sua diffusione, OWASP annovera la classifica delle “Top Ten”, ovvero le 10 maggiori vulnerabilità software in ambienti web. Questo documento, in costante evoluzione, definisce in maniera organica le più importanti criticità delle applicazioni, fornendo un ottimo punto di partenza per la preparazione di utili checklist in fase di assessment e di treatment dei rischi applicativi.
Vulnerabilità delle applicazioni
Una vulnerabilità è, genericamente, una debolezza che può favorire il concretizzarsi di una minaccia. Nell‘ambito del processo di produzione del software, la vulnerabilità è indotta da carenze architetturali (design), o da tecniche di codifica non sicure o inappropriate (build), o da errori di configurazione (deployment).
Nel caso di un‘applicazione web, per esempio, una convalida dell‘input poco robusta può costituire un facile bersaglio per un attaccante, il quale può modificare in parte o completamente la richiesta inoltrata verso un web server di destinazione, alterando a suo piacimento il contenuto di tali parametri.
Altre vulnerabilità si possono manifestare nell‘implementazione poco corretta dei meccanismi di controllo d‘accesso a una risorsa web (autenticazione e autorizzazione) così come nelle fasi successive: errori nell‘assegnazione dei permessi sui file (di configurazione, eseguibili), identificazione degli utenti tramite sessionID poco sicuri (un utente potrebbe comprenderne la generazione o assegnazione e tentare di assumere privilegi che non gli spettano), memorizzazione in cache di dati critici, e così via.
Per meglio comprendere il concetto di vulnerabilità delle applicazioni Web, l‘OWASP mette WebGoat [2] a disposizione di chi vuole approfondire l‘argomento: si tratta di una vera applicazione web resa volutamente insicura per mostrare, con diverse lezioni interattive, pericoli ed effetti sui dati esposti tramite l‘applicazione stessa.
WebGoat
Come accennavamo in precedenza, WebGoat è una applicazione deliberatamente insicura, sviluppata in J2EE, gestita dall‘OWASP allo scopo di insegnare alcune lezioni sulla sicurezza delle applicazioni Web. In ogni lezione l‘utente deve dimostrare di aver capito dove si trova il problema di sicurezza, sfruttando la reale vulnerabilità presente.
Essendo sviluppata in Java, WebGoat può essere eseguita su qualsiasi piattaforma che implementi una Java Virtual Machine ed ospiti un application server J2EE compliant. Tramite SourceForge viene fornito sia un archivio comprendente il pacchetto completo JRE + Apache Tomcat, sia un WAR standalone (potete trovarli seguendo il link alla sezione download contenuto in [2]).
Nota per gli utenti Windows: se non avete mai installato una JDK/JRE sulla vostra macchina, basterà scompattare l‘archivio così com‘à© e specificare il percorso della variabile di ambiente JAVA_HOME. Per farlo da start –> setting –> control panel –> system nel tab Advanced, alla voce Enviroment Variables, selezionare il percorso della cartella jre)
Figura 1 – Modificate qui la variabile d‘ambiente, alla voce Environment Variables
Su un sistema Linux, invece, si devono seguire i seguenti passi:
Estrarre il file zip in un percorso, ad esempio “/usr/local”:
[root] unzip Unix_WebGoat-4.0_Release.zip -d /usr/local/webgoat4
Lo zip, in questa versione, presenta alcuni errori e non funziona correttamente; occorre spostarsi pertanto nella directory per fare le modifiche necessarie:
[root] cd /usr/local/webgoat4/
Togliere il carattere ASCII 13d dallo script SH e renderlo eseguibile:
[root] mv webgoat.sh webgoat.sh.old [root] cat webgoat.sh.old | sed "s/^M//g" > webgoat.sh [root] chmod a+rx webgoat.sh
Facciamo anche un po‘ di modifiche negli scripts di Tomcat:
[root] cd tomcat/bin [root] mv startup.sh startup.sh.old [root] cat startup.sh.old | sed "s/^M//g" > startup.sh [root] chmod a+rx startup.sh [root] mv catalina.sh catalina.sh.old [root] cat catalina.sh.old | sed "s/^M//g" > catalina.sh [root] chmod a+rx catalina.sh [root] mv setclasspath.sh setclasspath.sh.old [root] cat setclasspath.sh.old | sed "s/^M//g" > setclasspath.sh [root] chmod a+rx setclasspath.sh [root] mv shutdown.sh shutdown.sh.old [root] cat shutdown.sh.old | sed "s/^M//g" > shutdown.sh [root] chmod a+rx shutdown.sh[root] export JAVA_HOME=/usr/local/java1.5
Proviamo a lanciare lo script:
[root] cd ../..[root] ./webgoat.shUsage: {start8080|start80|stop}
Adesso è possibile lanciare l‘applicazione web:
[root] ./webgoat.sh start8080Using CATALINA_BASE: ./tomcatUsing CATALINA_HOME: ./tomcatUsing CATALINA_TMPDIR: ./tomcat/tempUsing JAVA_HOME: /usr/local/jdk1.5.0_06 Open http://127.0.0.1:8080/WebGoat/attack Username: guest Password: guest Or try http://guest:guest@127.0.0.1:8080/WebGoat/attack
WebScarab
WebScarab è un framework per analizzare le applicazioni che comunicano tra loro usando i protocolli HTTP e HTTPS, ed è scritta in Java, come WebGoat, ed è pertanto portabile su svariate piattaforme. Le funzionalità offerte sono molteplici, grazie all‘architettura modulare a plugin, ma la principale è quella di fungere da proxy d‘intercettazione: WebScarab permette all‘operatore di vedere e modificare le richieste create dal browser prima che vengano inviate al server, e di vedere e modificare le risposte del server prima che il browser le riceva.
Il link per poterne scaricare sorgenti e Java binary è nella sezione download della pagina del progetto [3]: una volta estratto con il comando jar, l‘installer lancerà una comoda e semplice procedura di installazione mentre la versione self-contained farà partire solo l‘applicazione vera e propria.
Per installare il tool su Linux, seguire i seguenti passi:
Impostare la JDK 1.5:
[root] export JAVA_HOME=/usr/local/jdk1.5.0_06 [root] export PATH=$JAVA_HOME/bin:$PATH
Lanciare il programma di setup:
[root] java -jar webscarab-installer-20060718-1904.jar
e seguire i passi a video molto semplici ed intuitivi.
Per lanciare il programma:
[root] export JAVA_HOME=/usr/local/jdk1.5.0_06
[root] export PATH=$JAVA_HOME/bin:$PATH
[root] java -jar /usr/local/WebScarab/webscarab.jar
Un esempio pratico
Vediamo adesso un esempio concreto dei concetti accennati in precedenza.
Se avete installato correttamente l‘ambiente di runtime, l‘application server e WebGoat, aprite il vostro browser preferito all‘url http://localhost/WebGoat/attack; verrà richiesto di autenticarsi (usate la coppia login/password “guest” digitandola ovviamente senza le virgolette e tutta in minuscolo) come in figura 3.
Figura 3 – Procedura di autenticazione di WebGoat
Fatto questo finalmente potrete iniziare ad usare l‘applicazione.
Figura 4 – La schermata di benvenuto di WebGoat
Premuto il tasto Start avrete immediatamente accesso alla prima lezione che vi permetterà di apprendere come avvengono i trasferimenti di dati via protocollo HTTP.
Figura 5 – In alto a destra viene sempre mostrato un pop-up con gli scopi della lezione corrente.
In questo articolo esamineremo in dettaglio la lezione che riguarda come sfruttare una debolezza nel meccanismo di autenticazione tramite i cookies.
Figura 6 – Questo l‘obiettivo della lezione di nostro interesse.
I cookies di autenticazione contengono informazioni, memorizzate spesso nella cache del browser, che permettono di tenere traccia dell‘identità dell‘utente evitandogli di riautenticarsi durante tutta la sessione di navigazione (sempre che l‘utente non li abbia disattivati, beninteso). Come evidenziato negli obiettivi di questa lezione però, a volte gli algoritmi che generano questi cookies possono essere compresi da un attaccante o spesso vengono incautamente lasciati sulla macchina del client e possono essere rubati sfruttando un‘altra vulnerabilità del sistema del client.
Come fare per catturare questi cookies? Per farlo ci avvarremo di WebScarab.
Una volta aperto il programma, selezioniamo le azioni che il proxy deve effettuare: intercettare le richieste, le risposte e quali metodi utilizzare (ci bastano GET e POST).
Figura 7 – Configuriamo il proxy WebScarab per intercettare le richieste e le risposte del client.
A questo punto, come la lezione stessa ci suggerisce proviamo ad autenticarci con la coppia login/password “webgoat”.
Come potete vedere WebScarab richiama alla vostra attenzione i parametri che stanno per essere inviati dal client al server.
Figura 8 – WebScarab ha intercettato la richiesta del client.
Ci siamo autenticati correttamente digitando i parametri, come evidenziato nella figura 9.
Premendo sul tasto Refresh potete notare invece come l‘autenticazione sia avvenuta tramite cookie e infatti non ci è stato richiesto di digitare nuovamente login e password, ma vediamo come fare a rintracciarlo (in questa semplice lezione potremmo utilizzare anche l‘opzione show cookies presente in WebGoat). Nella figura 8 potete vedere che la nostra prima richiesta al server per autenticarci è stata una POST.
Andiamo adesso a vedere con WebScarab come ha risposto il server, selezionando Manual Request nell‘apposito menù e cercando la POST che ci interessa (nello specifico contrassegnata con ID 463).
Figura 10 – Sopra potete scegliere quale request e sotto visionarla e ottenere la risposta corrispondente.
Premiamo adesso il pulsante in basso “fetch response” e osserviamo bene cosa ci ha inviato il server: nel campo set-cookie abbiamo trovato ciò che cercavamo: al login webgoat è associato il cookie 65432ubphcfx.
Ripetendo lo stesso procedimento per l‘utente aspect (l‘altro utente dei due di default) troviamo questo cookie: 65432udfqtb.
Vi dice niente? A prima vista si direbbe di no, per cui si sarebbe portati ad immaginare che i cookies siano generati con qualche sconosciuto algoritmo e che quindi l‘implementazione sia perfettamente sicura.
Osservate però che per utenti così diversi come webgoat e aspect entrambi i cookies contengono 65432 come prime cifre: come avrete sicuramente immaginato, ogni cookie inizierà con queste stesse cinque cifre! Riflettendo ancora più attentamente si potrà notare come i due cookies abbiano in comune la prima “u” dopo la sequenza 65432, che entrambi gli utenti abbiano il login con lo stesso numero di lettere e infine che terminano entrambi con la “t”: quindi a lettera uguale nel login potrebbe corrispondere una lettera uguale nel cookie; nel login abbiamo due “t” e nei cookies due “u”; guarda caso… lettere che nell‘alfabeto inglese sono consecutive.
Provate ora a trasformare seguendo questo stesso procedimento (ad ogni lettera dell‘alfabeto del login sostituirla con la successiva) ogni singola lettera delle parole “webgoat” e “aspect” e avrete rispettivamente “xfchpbu” e “btqfdu”: sono proprio le lettere che compongono i cookies soltanto in ordine invertito!
A questo punto, compreso l‘algoritmo di generazione dei cookies d‘autenticazione degli utenti, potremmo impersonare tranquillamente ognuno di essi a patto di conoscerne il login, proviamo quindi con “alice” come suggeritoci da WebGoat.
Al login “alice” corrisponde il cookie 65432fdjmb: per impersonare quindi “alice” mentre siamo autenticati come “webgoat” o “aspect” ci basterà richiedere un refresh della pagina, intercettare la richiesta del client con WebScarab (figura 12) e “iniettare” il cookie di alice nella request intercettata (figura 13): abbiamo così compiuto uno “spoofing” dei cookies.
Figura 12 – Richiesta di refresh con visualizzazione del campo cookie
Premete adesso il pulsante Accept Changes in basso e avrete intercettato e modificato con successo la richiesta del client verso il server, il quale risponderà autenticandovi come alice nonostante non ne conosciate la password!
Conclusioni
L‘articolo ha voluto essere una breve introduzione al mondo della sicurezza delle applicazioni Web, ricordando brevemente OWASP ed i suoi obiettivi.
Chiaramente l‘implementazione proposta nella lezione di WebGoat è da intendersi come una semplificazione a scopo didattico: l‘uso di algoritmi così prevedibili e per lo più statici sicuramente non rappresenta una soluzione proponibile per la protezione di dati e informazioni critiche. Scopo della lezione è solo quello di focalizzare l‘attenzione sui meccanismi d‘implementazione e sulle loro possibili vulnerabilità .
Infine per chi volesse approfondire gli argomenti trattati in questo articolo, il suggerimento è di consultare la home page del progetto OWASP: un buon punto di partenza per reperire articoli, documenti, ma anche applicazioni e strumenti molto utili come quelli qui velocemente presentati.
Riferimenti
[1] OWASP Home Site
http://www.owasp.org/index.php/Main_Page
[2] OWASP WebGoat Project
http://www.owasp.org/index.php/OWASP_WebGoat_Project
[3] OWASP WebScarab Project
http://www.owasp.org/index.php/OWASP_WebScarab_Project
[4] WebGoat Installation Guide
http://www.owasp.org/index.php/WebGoat_Installation
[5] WebScarab
http://www.owasp.org/index.php/WebScarab_Getting_Started
[6] JDK 1.5
http://java.sun.com/javase/downloads/index_jdk5.jsp
[7] WebGoat 4 (Unix_WebGoat-4.0_Release.zip) http://sourceforge.net/project/showfiles.php?group_id=64424&package_id=61824&release_id=420177
[8] WebScarab 20060718-1904 (webscarab-installer-20060718-1904.jar)
http://sourceforge.net/project/showfiles.php?group_id=64424&package_id=61823&release_id=432994
Marco Ratto ha conseguito la laurea in Scienze dell‘Informazione nel 1999 presso la Facoltà di Scienze Matematiche Fisiche e Naturali dell‘Università degli Studi di Torino con la realizzazione della tesi ‘‘Accesso remoto ad un servizio di creazione di un orario: autenticazione dell‘utente in ambiente Java‘‘ .
Dal 1994 ha iniziato a lavorare come consulente nel settore IT e dal 2000 lavora come esperto di tecnologie J2EE ed Open Source in Banksiel per quanto riguarda il campo bancario/assicurativo e in Finsiel nel campo della Pubblica Amministrazione.
Roberto Margherita è consulente di information security per Almaviva Finance e si occupa di risk analysis e certificazione dei sistemi di gestione ISO27001, standard di cui è lead auditor.
Alessio Lazzara ha conseguito la laurea di primo livello in Informatica nel 2005 presso l‘Università degli Studi di Pisa, nel 2006 ha conseguito il master in Security Management di XCorsi Spa sponsorizzato da Microsoft e Clusit. Ha collaborato alla progettazione dell‘architettura di autenticazione per il progetto HUMAN. Dal 2006 lavora come consulente per soluzioni di autenticazione con utilizzo di certificati digitali presso Almaviva Finance.