IsacaRoma (IR): Salve Stefano e Giorgio. Volete presentarvi per i nostri lettori?
Stefano Di Paola (SdP): Mi sono laureato in ingegneria informatica nel 2002 a Firenze, con una tesi sull'elaborazione delle immagini, e la mia passione per la ricerca mi ha portato ad approfondire i temi della sicurezza informatica dal 1998. L'approccio ingegneristico tende a considerare tutte le problematiche come una questione di ottimizzazione e razionalizzazione. Reputo le tematiche della sicurezza applicativa una naturale continuazione di questo pensiero. Attualmente sono consulente ICT e sicurezza per diverse aziende private e pubbliche e collaboro con l'università di Firenze. Ho partecipato come relatore a diverse conferenze e seminari e collaboro con Owasp italia nel progetto di Testing Guide [2] portato avanti da Matteo Meucci [3].
Giorgio Fedon (GF): Mi sono laureato in economia aziendale presso l'Università Bocconi di Milano, con la quale collaboro nel corso di Information Security. Sono impiegato come consulente di sicurezza senior presso Emaze Networks e mi occupo di Analisi Forense, Code Auditing, Penetration Testing, Vulnerability Assessment, Analisi Malware per molte aziende, istituti di credito ed enti sul territorio nazionale. In ambito di ricerca mi sono interessato al web dal 2004 soprattutto riguardo tecniche di automazione di exploiting e ricerca di vulnerabilità in applicazioni web (client e server). Ho partecipato come relatore presso diverse conferenze internazionali ed ho lavorato precedentemtne nel System & Technology Group dell'IBM di Dublino.
IR: AJAX sta riscuotendo sempre più successo. Si tratta, per semplificare, di una tecnica per superare il classico modello sincrono del web: fino ad oggi le applicazioni web si basavano sul classico "click and wait"; AJAX (Asychronous Javascript and XML) utilizzandoopportunamente tecnologie già note e disponibili (scripting lato client, chiamate XmlHttpRequest, XML) permette una maggiore (e veloce) interattività. Quali sono i problemi di sicurezza di questo nuovo approccio? Si tratta semplicemente di gestire i problemi di sicurezza già esistente nelle applicazioni classiche (autenticazione, riservatezza, validazione, buffer overflow) o si creano nuovi aspetti di cui tener conto?
Stefano e Giorgio (SeG): Il problema è nell'approccio. Come da qualche anno cerchiamo di spiegare nelle conferenze, la complessità delle applicazioni svolge un ruolo fondamentale nella sicurezza. Più un'applicazione è complessa, più è esposta ad eventuali falle. Un pò come una cittadella su una rocca e una metropoli aperta a tutti. Verranno sempre più alla luce problematiche ancora poco considerate, e che nell'ambiente della sicurezza non sono ancora del tutto state sviscerate. Come ad esempio le problematiche inerenti l'XML Injection e l'attacco ai servizi WEB anche detti SOA.
IR: Spesso, parlando di AJAX, si cita il rischio di attacchi di tipo Cross-Site Scripting (XSS). Di che si tratta? Sono una vera minaccia?
SeG: Così come la code injection è il problema maggiore per le web application lato server, il XSS lo è per il lato client. In particolare il XSS è una vulnerabilità che permette ad un malintenzionato di iniettare codice che viene successivamente interpretato e eseguito dal browser della vittima.
La minaccia c'è e ci sarà sempre di più finché questa problematica verrà ritenuta una questione di second'ordine. Infatti i XSS continuano a essere scoperti su siti che spaziano da google ad amazon fino a quello della biblioteca vicino casa. Tralasciando per un attimo la diffusione dei XSS e focalizzandoci sugli impatti, al momento, è possibile tramite esecuzione di codice javascript su un browser avere visione in tempo reale di ciò che l'utente sta facendo e addirittura modificare il flusso di comunicazione tra il server e l'utente stesso. Queste problematiche erano conosciute già da tempo. Ne abbiamo un esempio con XSS Proxy di Anton Rager che le aveva gia messe in luce a fine 2004. Sfruttando le potenzialità di AJAX è possibile superare tutta una serie di limitazioni come il numero di dati inviati per richiesta e il controllo della comunicazione senza che l'utente possa esserne a conoscenza. Non, inoltre è da sottovalutare inoltre il fatto che un XSS può essere un vettore di attacchi anche al sistema operativo, come ad esempio il recente NamedPipes Attack [4] in ambienti windows.
IR: Un argomento di cui si discute è se l'importanza del 'lato client' che AJAX presuppone non richieda un sforzo troppo spropositato nel rendere sicuro questo aspetto. Qual è la vostra visione?
SeG: Purtroppo la mancanza di uno standard nello sviluppo di applicazioni AJAX impone uno sforzo implementativo, notevole anche solo per fare funzionare programmi di media entità. Figuriamoci mettere in conto la sicurezza! Le applicazioni AJAX portano gli sviluppatori a dover gestire un numero maggiore di eventi lato client e lato server: questo senza dubbio impatta notevolmente sui tempi di sviluppo e rende il vecchio modello di testing applicativo inadeguato. Relativamente ai problemi di sicurezza, vorremmo sottolineare l'importanza della corretta strutturazione del design applicativo nella gestione degli input: come un altro progetto di Owasp, CAL9000 [5] mette in luce, è estremamente arduo difendersi da XSS lato client, infatti mediante tecniche di offuscamento e di iniezione di codice all'interno di tag esistenti è molto difficile stabilire se una stringa contiene istruzioni potenzialmente pericolose. Ad esempio, non bastano controlli sull'esistenza dei tag <script> perchè ci sono mille e uno modi per raggiungere lo stesso scopo. Infatti, grazie alle maggiori potenzialità offerte dai client AJAX, anche gli effetti indotti dalle vulnerabilità classiche acquistano maggiore pericolosità.
IR: Infine il "security testing". AJAX richiede un nuovo modo di progettare le applicazioni. Anche il modo di testarle deve variare? Dunque anche il security testing deve trovare una nuova formula adatta al modello asincrono?
SeG: Su questo tema vi sono diversi aspetti che devono essere presi in considerazione. La maggiore problematica nel testing di applicativi AJAX è che il client porta con se degli stati interni non immediatamente estrapolabili. Ne segue che non è più sufficiente estrarre tutti i link e le form da una pagina per essere sicuri di avere tutte le informazioni che vengono scambiate tra client e server. Inoltre, il fatto che le richieste vengano inviate senza il controllo diretto dell'utente implica che tali richieste debbano essere intercettate da un software chiamato application proxy. Owasp mette a disposizione un application proxy chiamato WebScarab [6] che permette di verificare le applicazioni web con discreta semplicità.
Un altro aspetto è che il test deve essere applicato a tutte le tecnologie che compongono il sistema. Infatti, mentre nella verifica di sicurezza di pagine web classiche i controlli avvengono su parametri e valori scambiati tra client e server in maniera piuttosto semplice, il web 2.0 complica le modalità di comunicazione introducendo nuovi linguaggi come l'XML e nuove grammatiche come il WSDL. Questo implica una conoscenza ancora più approfondita da parte del professionista di sicurezza che diventa sempre meno improvvisato. All'interno della Testing Guide [7] di Owasp ci sarà un paragrafo sulle metodologie di test delle applicazioni AJAX.
IR: Che letture (o risorse) consigliate a chi volesse approfondire il tema della sicurezza di AJAX?
SeG: C'è ancora molto poco in letteratura. Andrew Van Der Stock [8] di Owasp, Jeremiah Grossman [9], Bill Hoffman (AJAX (In)security) si stanno dando molto da fare per sensibilizzare l'opinione pubblica attraverso presentazioni e pubblicazioni presso conferenze ad eventi di alto livello come il BlackHat [10].
In ambito di ricerca c'è un nostro studio in fase di pubblicazione dal titolo "Hijacking AJAX for fun and profit" e inoltre saremo presenti al 23esimo Congresso del CCC [11] a Berlino per presentare alcune nuove tecniche di attacco che sfruttano le caratteristiche di AJAX.
IR: Infine una domanda per Stefano. Cos'è Wisec - The WIse SECurity [12]? Si occuperà anche di AJAX?
SdP: Wisec.it nasce come progetto personale seguendo un approccio non convenzionale non direttamente legato agli attacchi, ma anche alla difesa delle applicazioni, ponendo particolare attenzione al web. Su Wisec sono state pubblicate diverse vulnerabilità che ho scoperto in applicativi come Mysql e Php, ma anche alcune ricerche e soluzioni su tematiche come il design nelle applicazioni web e la generazione automatica di regole per ModSecurity [13].
Al momento è un sito che amministro da solo ma nel 2007 è in programma una nuova veste grafica e l'apertura ad altri ricercatori. Sicuramente nell'immediato così come in futuro si porrà come complemento ad Owasp nella ricerca avanzata in ambito sicurezza per temi caldi come Web 2.0 e non solo.
IR: Grazie e buon lavoro
Seg: Grazie a voi
IsacaRoma link
- La top 10 dei possibili attacchi al web 2.0 [14]
- Intervista Alberto Revelli Technical Director di OWASP Italy ed autore di sqlninja [15]
- Codice sicuro: intervista a Paolo Perego, thesp0nge, ideatore di OWASP Orizon [16]
- Application security: intervista ad Antonio Parata di OWASP [17]
- OWASP: i vincitori dell'Autumn of Code 2006 [18]
- Intervista a Matteo Meucci di Owasp Italia [19]
- SMAU: OWASP, applicativi web vulnerabili [20]
- Matteo Meucci: Web Application Security e il progetto OWASP (pdf [21] zip, 2 M)
Chi è Agatino Grillo?
Agatino Grillo, CISA, CISM, CISSP, fa parte del comitato direttivo di IsacaRoma. Precedentemente è stato nel comitato direttivo di AIEA.Altri articoli pubblicati per IsacaRoma Newsletter
- ENISA: Intervista al dott. Louis Marinos, Risk Management Senior Expert [22]
- ENISA: Interview with Dr Louis Marinos, Senior Expert on Risk Management [23]
- Intervista all’ing. Carlo Notari, presidente del PMI Northern Italy Chapter (PMI-NIC) [24]
- Intervista Alberto Revelli Technical Director di OWASP Italy ed autore di sqlninja [25]
- Codice sicuro: intervista a Paolo Perego, thesp0nge, ideatore di OWASP Orizon [26]
- Wikipedia: la voce "IT governance" [27]
- Application security: intervista ad Antonio Parata di OWASP [28]
- Wikipedia: la voce "IS auditing" [29]
- IIA – sesta guida GTAG: "Managing and Auditing IT Vulnerabilities" [30]
- ISACA: Standard, direttive e procedure – l’analisi dei rischi (24-09-2006) [31]
- ISACA: Standard, direttive e procedure – prima parte (23-09-2006) [32]
- Intervista a Ross Anderson (02-11-2005) [33]
- Lezioni di IS Auditing [34] (03-01-2006)
- Conversazione con Simon Singh [35] (28-10-2005)
- COSO Enterprise Risk Management Framework [36] (12-09-2006)
- Bruce Schneier: domande e risposte [37] (01-11-2005)