Questa è la traduzione dell'articolo Ajax security basics di Jaswinder S. Hayre e Jayasankar Kelath pubblicato originariamente su SecurityFocus il 22 giugno 2006. La traduzione viene qui presentata con il consenso dell'editore.
Introduzione
Nell'ultimo anno le tecnologie basate su AJAX hanno ottenuto grande visibilità a causa della loro natura "interattiva". Google Suggest e Google Maps sono alcuni dei servizi più noti che fanno uso di AJAX. Le aziende stanno pensando a come poter sfruttare queste tecnologie, gli sviluppatori Web stanno cercando di apprenderne il funzionamento, i professionisti di sicurezza stanno pensando a come poterle rendere più sicure e gli addetti alle verifiche di sicurezza stanno pensando a come violarle. Ogni tecnologia che migliora lo scambio dati con i server, che produce transizioni più fluide fra pagine e rende le applicazioni web più ricche trova facilmente grande visibilità.
AJAX è considerato un grande passo in avanti verso il tanto sbandierato "Web 2.0". Il proposito di questo articolo è di introdurre alcune implicazioni di sicurezza riguardanti l'uso di queste tecnologie. Sebbene le applicazioni basate su AJAX possono essere molto più difficili da testare, la comunità dei professionisti di sicurezza ha già dalla sua gli strumenti e gli approcci di cui ha bisogno. Gli autori verificheranno se la necessità, oggi tanto richiesta, di dire addio al refresh completo delle pagine Web imponga anche di dare il benvenuto a nuovi problemi di sicurezza. Inizieremo quindi con una breve panoramica delle tecnologie che si celano dietro AJAX seguita da un'analisi delle implicazioni di sicurezza che tale tecnologia porta con sé.
AJAX: nozioni fondamentali
Le classiche applicazioni web lavorano su un modello sincrono: ad una richiesta dal Web si fa seguire una risposta che provoca alcune azioni sul livello di presentazione dell'applicazione. Per esempio: il clic su un link o l'invio di un modulo eseguono una richiesta al Web server con i relativi parametri. Il tradizionale comportamento "click and wait" ('clicca e aspetta') limita l'interattività delle applicazioni. Questo problema è stato mitigato dall'uso delle tecnologie AJAX (Asychronous Javascript and XML). Nell'ambito di questo articolo definiremo AJAX come il metodo con il quale vengono eseguite chiamate asincrone al Web server senza causare un aggiornamento completo della pagina Web. Questa interazione è resa possibile da tre componenti differenti: un linguaggio di scripting lato client, l'oggetto XmlHttpRequest (XHR) object e l'XML.
Vediamo in breve questi tre componenti. Il linguaggio di scripting lato client è utilizzato per inizializzare le chiamate al Web server e successivamente, in risposta alla richiesta, è utilizzato per accedere e aggiornare il DOM all'interno del browser. La scelta più diffusa lato client è JavaScript poiché ampiamente integrato nei browser moderni. Il secondo componente è l'oggetto XHR: il cuore di tutto. Linguaggi come JavaScript utilizzano l'oggetto XHR per inviare richieste al Web server "dietro le quinte" utilizzando l'HTTP come mezzo di trasporto. In ultimo abbiamo una terza componente, il cui uso non è tuttavia strettamente necessario: XML, ossia il formato con cui vengono scambiati i dati.
In molti siti si fa uso di JSON (JavaScript Object Notation) al posto di XML poiché permette un più semplice recupero dei dati e un minore eccesso di codice. Usare JavaScript per accedere a dati JSON è semplificato dall'uso della funzione eval(). Anche XPath può essere utilizzato per accedere e restituire XML. Ancora, ci sono diversi siti basati su AJAX che non utilizzano né XML né JSON ma inviano pezzi di vecchio codice HTML da includere dinamicamente nella pagina.
AJAX, dunque, non è una tecnologia nuova di zecca, ma una combinazione di tecnologie già esistenti usate assieme per sviluppare applicazioni Web ad alta interattività. Ognuna di queste componenti infatti non è nata ieri ma presente sin dalla versione 5 di Internet Explorer. Gli sviluppatori hanno trovato diversi usi di AJAX:
in box testuali di suggerimento (come Google Suggest) e in elenchi di dati autoaggiornabili. Tutte le richieste XHT sono
sempre processate da piattaforme server side, come ad esempio J2EE, .NET e PHP. La natura asincrona di AJAX è illustrata nella figura qui sotto:
Le implicazioni di sicurezza di AJAX
Ora che abbiamo esaminato le basi di AJAX passiamo a discutere delle sue implicazioni di sicurezza. AJAX non introduce per sua natura nuove vulnerabilità di sicurezza nel regno delle applicazioni Web. Anzi, le nuove applicazioni hanno di fronte gli stessi problemi di sicurezza di quelle classiche. Sfortunatamente per AJAX non sono state sviluppate buone pratiche comuni, ed è facile per questo incorrere in errore. Tra questi includiamo le giuste autenticazioni, autorizzazioni, controlli di accesso e validazione degli input dell'utente
(cfr.
Ajax Security). Alcune aree potenziali di preoccupazione che riguardano l'uso di AJAX sono:
- Controlli di sicurezza lato client
Qualcuno potrebbe suggerire che la dipendenza dalla programmazione lato client apre la possibilità di introdurre in "prima linea" alcuni noti problemi di sicurezza. Tra questi c'è l'improprio uso di controlli di sicurezza lato client da parte degli sviluppatori. Come già detto, l'uso di AJAX richiede un bel po' di codice di scripting lato client. Gli sviluppatori Web ora stanno cominciando a scrivere codice sia lato client sia lato server e questo potrebbe spingerli a implementare i controlli di sicurezza dalla parte client della programmazione. Questo approccio è del tutto insicuro poiché gli aggressori potrebbero modificare qualsiasi porzione di codice eseguito sui computer client al momento di testare le vulnerabilità dell'applicazione. I controlli di sicurezza devono essere completamente implementati lato server o sempre rinforzati sul server.
- Ampliamento della superficie di attacco
Una seconda sfida è legata alla difficoltà di rendere sicura la sempre più vasta superficie di attacco. AJAX inevitabilmente aumenta la complessità generale del sistema. Nel processo di uso di AJAX, gli sviluppatori devono produrre un gran numero di pagine con accessi lato server, ognuna di queste esegue alcune minime funzionalità (come la ricerca di un codice postale o l'autocompletamento dei campi dei dati di residenza degli utenti) all'interno dell'applicazione. Ognuna di queste piccole pagine diventa un nuovo obiettivo per gli aggressori e un nuova zona da rendere sicura da vulnerabilità. Ciò è simile al concetto, ben noto nel campo della sicurezza, dei punti di accesso multipli ad una casa: confrontate le difficoltà di proteggere una casa con una porta con quelle di proteggerne una con dieci porte.
- Colmare lo spazio tra utenti e servizi
AJAX è un metodo con il quale gli sviluppatori portano gli utenti molto più vicini alle interfacce esposte dalle Service Oriented Architectures (SOA). La spinta a creare architetture cosiddette "loosely coupled" ['a legame debole', applicazioni che comunicano tra di loro senza conoscere quasi nulla delle architetture reciproche; è opposto a tightly coupled, sistemi in cui le comunicazioni fra architetture diverse sono basate su legami più saldi, NdT] basate sui servizi web è una promettente idea che ha benefici in ambiti aziendali (cfr. Andrew van der Stock, AJAX Security [Pdf]). Più vengono sviluppati questi "endpoint" basati su servizi, e più AJAX introduce la possibilità di affidare agli utenti procedure sempre più sofisticate, più cresce la possibilità di allontanarsi dal modello standard "three-tier".
Solitamente, molti Web service all'interno di un'azienda (in contrasto con ciò che si vede su Internet) sono progettati per soluzioni B2B e di conseguenza gli sviluppatori e i designer non si attendono interazioni con veri e propri utenti. Questa mancanza di prudenza conduce ad alcune gravi premesse durante lo sviluppo. Ad esempio: lo sviluppatore iniziale avrebbe potuto ritenere che le autenticazioni, autorizzazioni e la validazione degli input vanno eseguite da altri sistemi di tipo "middle-tier" [come ad esempio un Web server, NdT]. Una volta che si consente ad "esterni" di eseguire chiamate dirette a questi servizi attraverso l'uso di AJAX, un inaspettato ospite viene introdotto sulla scena. Un esempio reale di un tale uso è la costante spinta di Microsoft ad usare Atlas "mano nella mano" con i Web service. Gli sviluppatori possono ora scrivere codice JavaScript per creare degli input XML e chiamare il Web service direttamente dall'interno del browser. Nel passato ciò si otteneva attraverso dei servizi proxy implementati nel server.
- Nuove possibilità di Cross-Site Scripting (XSS)
Un'altra cruda verità è che gli aggressori possono essere più creativi (in altre parole: pericolosi) nello sfruttare vulnerabilità di tipo Cross Site Scripting (XSS, cfr. Technical explanation of the MySpace worm). Solitamente gli aggressori devono saper sfruttare dei buchi XSS in un mondo "a singolo thread", in cui l'attacco è portato mentre il browser dell'utente è in stato di attesa. Questo stato di attesa fornisce alcuni indizi visuali e di comportamento all'utente sul normale funzionamento dell'applicazione. Con l'introduzione di AJAX, un aggressore può sfruttare vulnerabilità Cross Site Scripting in un modo più subfolo. Mentre si controlla la posta elettronica all'interno di una applicazione scritta con AJAX, un eventuale codice nocivo potrebbe inviare mail a tutti i conoscenti senza che il browser conceda nessun indizio visuale di quest'azione.
Adeguati e approfonditi test di sicurezza devono essere eseguiti prima di portare in produzione le applicazioni in modo da circoscrivere queste aree di interesse. Sebbene le applicazioni AJAX sono applicazioni Web, le metodologie standard di test potrebbero essere inadeguate a causa dell'alta interattività di queste applicazioni.
Nella prima parte dell'articolo abbiamo definito le basi tecnologiche di AJAX e abbiamo analizzato i principali problemi di sicurezza che esse introducono. In questa seconda e ultima parte affrontiamo i problemi delle metodologie di security testing.
Come AJAX rende più difficili le metodologie tradizionali di security testing
Nel procedimento di valutazione della sicurezza di un'applicazione web tradizionale, l'addetto parte dalla fase di raccolta delle informazioni (footprinting). L'intento di questa prima fase è quello di intercettare le richieste e le risposte dell'applicazione in modo da capire come essa comunica con il server e le risposte che ne riceve. Le informazioni sono tracciate da alcuni proxy come Burp o Paros. È importante completare in profondità la fase di footprinting in modo da tracciare tutte le richieste delle pagine usate dall'applicazione.
Dopo questo primo passaggio, l'addetto comincerà il processo di introduzione degli errori, sia manualmente sia usando alcuni strumenti automatici, per esaminare i parametri che transitano verso e dal server.
AJAX rende più complicate queste metodologie a causa della sua natura asincrona. Le applicazioni scritte in AJAX sono tipicamente più complesse delle applicazioni web tradizionali. Un'applicazione potrebbe eseguire diverse richieste in background anche quando sembra inattiva agli occhi di un utente. Chi esegue le verifiche di sicurezza deve essere consapevole delle diverse situazioni che potrebbero rendere più difficile il processo di test dell'applicazione. Tra queste ricordiamo
- Il problema dello "stato"
Nel mondo delle applicazioni web tradizionali, lo "stato" di un'applicazione è ben definito. Tutto ciò che di una pagina è memorizzato nel DOM potrebbe essere considerato lo stato attuale di quella pagina. Se c'è necessità di cambiare lo stato di quella pagina, una richiesta viene inviata al server e la risposta definisce come quello stato deve essere modificato.
Nel mondo delle applicazioni AJAX le cose cambiano. L'applicazione può potenzialmente generare differenti tipi di richiesta in dipendenza dello stato corrente della pagina. La richiesta generata da un clic su una list box può essere differente dalla richiesta generata da un clic sulla stessa list box se l'utente ha prima selezionato un pulsante sulla pagina. Inoltre, la risposta può aggiornare parte della pagina in modo da mostrare all'utente nuovi link o controlli da utilizzare. Questo comportamento di AJAX suscita diverse preoccupazioni al momento delle verifiche poiché è molto più difficile determinare se chi esegue il test ha visto o no tutti i possibili tipi di richieste generate da una pagina o da un'applicazione.
- Richieste inizializzate da eventi legati al tempo
Un'altra difficoltà è data dagli aggiornamenti dell'interfaccia utente basati non su interazioni dell'utente ma su eventi a tempo. Le applicazioni potrebbero inviare periodicamente richieste al server per aggiornare le informazioni sulla pagina. Ad esempio, un'applicazione finanziaria può usare l'oggetto XHR per aggiornare una zona della pagina Web che mostra informazioni sul valore delle azioni. Poiché che non ci sono link o pulsanti che suggeriscono all'addetto che ci sono richieste in atto in background, egli potrebbe non essere a conoscenza di questo processo se non intercetta la richiesta al momento giusto.
- Aggiornamento dinamico del DOM
Le risposte di AJAX possono contenere codice JavaScript che può essere elaborato da un'applicazione web e mostrato sull'interfaccia utente. Ciò include nuovi link, accessi a nuovi documenti sul server e così via. Un modo per poter eseguire questo processo è dato dall'utilizzo dell'istruzione
eval(cfr. Ajax Security e un messaggio sulla mailing list WebAppSec). A questo comando viene passato un solo parametro, una stringa, che viene eseguito come se fosse parte del programma.Un buon esempio di tutto ciò è Google Suggest: in questo caso l'applicazione riceve una porzione di codice JavaScript che viene elaborato e mostra un suggerimento per la query che si sta scrivendo. Questo comportamento può essere problematico sia per chi esegue test manuali sia per chi si fa aiutare da strumenti automatici. In entrambi i casi è necessario capire il contesto di come JavaScript viene utilizzato all'interno dell'applicazione. Una maggiore attenzione bisogna prestare inoltre nel momento in cui i parametri di input sono inviati indietro e processati lato client. Ciò potrebbe rientrare negli ambiti degli errori Cross Site Scripting e lo è, ma tali errori sono diventati molto più semplici da violare. Le applicazioni che eseguono una validazione basandosi su blacklist sono ancor più soggette a tali problematiche poiché gli aggressori non hanno bisogno di inviare così tanti tag. In passato, infine, diversi metodi sono stati scoperti per eseguire attacchi XSS senza i tag di script.
- Fuzzing XML
AJAX può essere usato di inviare richieste e ricevere risposte in formato
XML. Semplici strumenti automatici interpretano i metodi GET e POST ma molti non
hanno idea di come interpretare informazioni incluse nel formato XML ['fuzzers'
sono programmi, o anche script o altri tipi di eseguibili, utilizzati nelle
procedure di security testing per verificare la stabilità e la sicurezza di
un'applicazione; con 'fuzzing' si intende l'uso di fuzzers, NdT].
Gli addetti alle verifiche di sicurezza devono assicurare che gli sviluppatori non devino dal modello di architettura sicura. In un sistema sicuro i controlli di sicurezza sono inclusi in un ambiente che è fuori dal controllo dell'utente. Mentre si eseguono revisioni dell'architettura è necessario che qualcuno verifichi il codice scritto lato client per determinare se qualcosa stia modificando lo stato delle variabili (i cookie, i parametri dei FORM, i parametri GET) prima di inviarle al server. Ogni volta che ciò accade, il codice JavaScript deve essere analizzato per capire la ragione di questi cambiamenti.
Proprio come le classiche applicazioni web, tutte le richieste AJAX dovrebbero essere verificare dal punto di vista delle autorizzazioni. Gli sviluppatori potrebbero cadere vittima della credenza che l'autorizzazione non è più necessaria solo perché una pagina è richiamata in background mediante l'uso di un motore di scripting lato client. Ma sarebbe un errore.
Conclusioni
Le applicazioni AJAX forniscono nuove possibilità grazie alle loro componenti interattive. Gli sviluppatori dovrebbero essere consapevoli delle nuove forme di insicurezza introdotte da queste funzionalità. Gli addetti alle verifiche di sicurezza devono aumentare le loro metodologie e i loro strumenti per gestire le applicazioni scritte in AJAX.
In questo articolo gli autori hanno introdotto alcuni problemi di sicurezza riscontrati nelle tecnologie AJAX. Gli addetti ai penetration test dovrebbero aver capito che, sebbene posseggano le conoscenze e gli strumenti per valutare applicazioni AJAX, c'è qualcosa di più difficile da verificare.
Link (inglese)
- Jesse James Garrett, "AJAX: A New Approach to Web Applications", Feb. 18, 2005.
- Ryan Asleson and Nathaniel T. Schutta, "Foundations of AJAX", APress Publications, Oct 2005.
- Nicholas C. Zakas, Jeremy McPeakandJoe Fawcett, "Wrox Professional AJAX", Feb 2006.
- Eric Pascarello, "Eric Pascarello dissects AJAX security vulnerabilities", Feb. 07, 2006.
- Andrew van der Stock, "AJAX and Other 'Rich' Interface Technologies".
Gli autori
Jaswinder S. Hayre, CISSP, e Jayasankar Kelath, CISSP, sono entrambi Senior Security Engineers presso l'Advanced Security Center Ernst & Young di New York.
