WebGoat e WebScarab

Due strumenti OWASP per la sicurezza delle applicazioni Webdi e e

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

Figura 2 - Inserite 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":

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

Figura 9 - Autenticazione tramite parametri.

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.

Figura 11 - Localizzato il cookie corrispondente a WebGoat

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

Figura 13 - Spoofing con il cookie corrispondente all‘identità  di Alice.

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!

Figura 14 - Abbiamo superato con successo la lezione.

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

Condividi

Pubblicato nel numero
114 gennaio 2007
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…
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…
Ti potrebbe interessare anche