WebGoat e WebScarab: due strumenti OWASP per la sicurezza delle applicazioni Web

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.

Cos'è 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 > Settings > Control Panel > System nel tab Advanced, alla voce Environment Variables, selezionare il percorso della cartella JRE.

Su un sistema Linux, invece, si devono seguire i seguenti passi:

Estrarre il file zip in un percorso, ad esempio "/usr/local":

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:

cd /usr/local/webgoat4/

Togliere il carattere ASCII 13d dallo script SH e renderlo eseguibile:

mv webgoat.sh webgoat.sh.old
cat webgoat.sh.old | sed "s/^M//g" > webgoat.sh
chmod a+rx webgoat.sh

Facciamo anche un po' di modifiche negli scripts di Tomcat:

cd tomcat/bin
mv startup.sh startup.sh.old
cat startup.sh.old | sed "s/^M//g" > startup.sh
chmod a+rx startup.sh
mv catalina.sh catalina.sh.old
cat catalina.sh.old | sed "s/^M//g" > catalina.sh
chmod a+rx catalina.sh
mv setclasspath.sh setclasspath.sh.old
cat setclasspath.sh.old | sed "s/^M//g" > setclasspath.sh
chmod a+rx setclasspath.sh
mv shutdown.sh shutdown.sh.old
cat shutdown.sh.old | sed "s/^M//g" > shutdown.sh
chmod a+rx shutdown.sh
export JAVA_HOME=/usr/local/java1.5

Proviamo a lanciare lo script:

cd ../..
./webgoat.sh

Output:

Usage: {start8080|start80|stop}

Adesso è possibile lanciare l'applicazione web:

./webgoat.sh start8080

Output:

Using CATALINA_BASE: ./tomcat
Using CATALINA_HOME: ./tomcat
Using CATALINA_TMPDIR: ./tomcat/temp
Using 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:

export JAVA_HOME=/usr/local/jdk1.5.0_06
export PATH=$JAVA_HOME/bin:$PATH

Lanciare il programma di setup:

java -jar webscarab-installer-20060718-1904.jar

e seguire i passi a video molto semplici ed intuitivi.

Per lanciare il programma:

export JAVA_HOME=/usr/local/jdk1.5.0_06
export PATH=$JAVA_HOME/bin:$PATH
java -jar /usr/local/WebScarab/webscarab.jar

Un esempio pratico

Vediamo adesso un esempio concreto dei concetti accennati nei capitoli precedenti.

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.

Fatto questo finalmente potrete iniziare ad usare l'applicazione.

Premuto il tasto Start avrete immediatamente accesso alla prima lezione che vi permetterà di apprendere come avvengono i trasferimenti di dati via protocollo HTTP.

In questo articolo esamineremo in dettaglio la lezione che riguarda come sfruttare una debolezza nel meccanismo di autenticazione tramite i cookies.

I cookie 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 cookie 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 cookie? 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).

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.

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).

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 cookie 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 cookie 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 cookie 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 cookie 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 cookie soltanto in ordine invertito!

A questo punto, compreso l'algoritmo di generazione dei cookie 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 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](http://www.owasp.org/index.php/Main_Page)

• [2] OWASP WebGoat Project

• [http://www.owasp.org/index.php/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](http://www.owasp.org/index.php/OWASP_WebScarab_Project)

• [4] WebGoat Installation Guide

• [http://www.owasp.org/index.php/WebGoat_Installation](http://www.owasp.org/index.php/WebGoat_Installation)

• [5] WebScarab

• [http://www.owasp.org/index.php/WebScarab_Getting_Started](http://www.owasp.org/index.php/WebScarab_Getting_Started)

• [6] JDK 1.5

• [http://java.sun.com/javase/downloads/index_jdk5.jsp](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](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](http://sourceforge.net/project/showfiles.php?group_id=64424&package_id=61823&release_id=432994)