Ricerca di vulnerabilità nelle componenti lato client di applicazioni Web 2.0

Questa è la traduzione dell'articolo Vulnerability Scanning Web 2.0 Client-Side Components di Shreeraj Shah pubblicato originariamente su SecurityFocus il 27 novembre 2006. La traduzione viene qui presentata con il consenso dell'editore.

Introduzione

Le cosiddette applicazioni Web 2.0 sono una combinazione di diverse tecnologie: Asynchronous JavaScript and XML (Ajax), Flash, JavaScript Object Notation (Json), Simple Object Access Protocol (Soap), Representational State Transfer (Rest). Tutte queste tecnologie, assieme all'accesso ai dati cross-domain, accrescono la complessità dell'applicazione. Stiamo assistendo, dunque, ad un potenziamento del browser che avviene attraverso il caricamento di nuovi programmi e librerie.

Tutti questi cambiamenti introducono nuovi problemi nelle attività di scansione di sicurezza, sia per gli utenti sia per i software. Il fine di questo articolo è quello di far comprendere i seguenti concetti e le seguenti tecniche:

• La complessità di scansione e i problemi che ci sono nelle applicazioni web di nuova generazione
• Gli obiettivi e le metodologie nella scansione di applicazioni Web 2.0
• La scoperta di vulnerabilità in ambito Web 2.0 (in particolare gli XSS nei feed RSS)
• L'injection cross-domain con Json
• Le contromisure e le difese attraverso un sistema di filtraggio ottenibile per mezzo del browser

Complessità della scansione di sicurezza nel Web 2.0 

Le applicazioni Web 2.0 di nuova generazione sono molto complesse e impongono nuovi problemi nella scansione ai fini della sicurezza. La complessità può essere attribuita ai seguenti fattori:

• Interfaccia lato client complessa. Ajax e Flash dotano le applicazioni web di ricche interfacce facendo uso di JavaScript e ActionScript, rendendo difficile identificare la logica dell'applicazione e le risorse critiche nascoste all'interno di questi script.
• Origine dei dati. Le applicazioni di questo tipo recuperano informazioni da diverse sorgenti e creano mashup all'interno dei siti. Le applicazioni aggregano feed RSS o blog da differenti origini e costruiscono un grande deposito di informazioni in un unico luogo.
• Struttura dei dati. Lo scambio dei dati tra diverse applicazioni è eseguito mediante l'uso di Xml, Json, elenchi di script Java e strutture proprietarie.
• Protocolli. Oltre ai semplici GET e POST via HTTP, le applicazioni possono scegliere diversi protocolli, come Soap, Rest e Xml-Rpc.

L'applicazione oggetto della nostra scansione potrebbe recuperare feed RSS da diversi siti, scambiare informazioni con diversi blog utilizzando Json e comunicare con un portale di informazioni finanziarie usando Soap. Tutti questi servizi sono incorporati sotto forma di Rich Internet Application (RIA) che usano Ajax o Flash.

I problemi nella scansione di sicurezza nelle applicazioni Web 2.0

I problemi nella scansione di applicazioni possono essere suddivisi in due parti:

1. Scansione delle componenti lato server. Uno dei principali problemi nella scansione di applicazioni Web 2.0 è identificare risorse nascoste sul server. Quando si scansionano applicazioni tradizionali, un software crawler può essere lanciato alla ricerca della stringa href per identificare e tracciare il profilo delle risorse dell'applicazione. Nel caso di applicazioni Web 2.0, tuttavia, c'è bisogno di identificare i Web service usati, i mashup esterni, i proxy e così via. Questi temi sono stati già trattati in un articolo precedente (anch'esso tradotto da HTML.it, ndr).
2. Scansione delle componenti lato client. Un'applicazione Web 2.0 può caricare nel browser diversi elementi, codici JavaScript, componenti Flash. Questi script e componenti utilizzano l'ogetto XMLHTTPRequest per comunicare con il Web server. È anche possibile accedere ad informazioni cross-domain dall'interno del browser stesso. Gli attacchi di Cross-Site Scripting (XSS) sono potenziali minacce che gravano sull'utente dell'applicazione. La piattaforma Web 2.0 usa diversi script eseguiti sul client e recupera informazioni da origini esterne non verificate. Le tecnologie Ajax e Json, l'accesso cross-domain e la gestione dinamica del DOM stanno aggiungendo una nuova dimensione ai vecchi attacchi XSS. La scoperta di vulnerabilità e la scansione lato client delle applicazioni Web 2.0 sono dunque le nuove sfide che si stanno affacciando all'orizzonte.

Obiettivi della scansione lato client

Per comprendere gli obiettivi della scansione prendiamo come esempio un semplice scenario visualizzato in figura 1. Abbiamo un'applicazione Web che viene eseguita sul sito example.com. Il client accede a questa applicazione mediante il browser.

Figura 1: Schema dell'applicazione Web 2.0

Questa applicazione può essere suddivisa nelle seguenti sezioni in base al suo uso e alla sua logica.

• Le risorse. Queste risorse sono sviluppate dal sito stesso e possono essere di una di queste tipologie: HTML, ASP/JSP o Web Service. Tutte queste risorse sono in un dominio del tutto fidato e in possesso del sito example.com.
• Il proxy per i feed. L'oggetto XMLHTTPRequest non può eseguire direttamente chiamate cross-domain. Per aggirare questa restrizione il sito deve impostare un proxy che fornisce accesso a feed RSS esterni come, ad esempio, feed di notizie. Così facendo example.com può usare qualsiasi feed presente su Internet.
• Accesso ai blog. L'utente usa la stessa applicazione gestita da example.com per accedere ad alcuni blog su Internet. Questo è possibile grazie al caricamento di alcuni script sul browser dell'utente da parte di example.com, cosa che garantisce l'accesso a blog diversi al di fuori del domino principale.

Ecco allora quattro obiettivi critici che bisogna assumere in una scansione destinata alla scoperta delle vulnerabilità lato client: 

1. Rilevazione della tecnologia e delle librerie. Le applicazioni Web 2.0 possono essere create a partire da diverse librerie Ajax o Flash. Queste librerie sono caricate nel browser e usate dall'applicazione ogni volta che ne ha bisogno. È importante rilevare queste librerie e individuare eventuali vulnerabilità note.
2. Punti informativi esterni inaffidabili. In figura 1 abbiamo diviso l'applicazione in due aree: affidabili e non affidabili. Le informazioni che giungono da fonti non affidabili hanno bisogno di essere verificate prima di essere caricate all'interno del browser. Nel nostro esempio queste informazioni transitano attraverso un proxy dell'application server nel caso dei feed e direttamente all'interno del DOM nel caso dei blog.
3. Punti di accesso al DOM. Il browser esegue ogni cosa all'interno del DOM gestito da codice JavaScript Se alcune informazioni nocive sono lasciate transitare in uno di questi punti di accesso il browser può trovarsi in pericolo.
4. Tracce di funzioni e variabili per individuare le vulnerabilità. Una volta che i punti di accesso al DOM e le informazioni esterne sono state identificate è importante capire la logica di funzionamento e le tracce che vi corrispondono in modo da mostrare le minacce e le vulnerabilità.

La scansione client side di un'applicazione (Feed)

In questa sezione adotteremo un approccio manuale al processo di scansione. Questa metodologia può essere automatizzata in alcuni punti ma data la complessità dell'applicazione potrebbe essere difficile scansionare ogni possibile combinazione.

Il nostro obiettivo è la pagina http://example.com/rss/news.aspx così come mostrata in figura 2.

Figura 2: Il widget dell'applicazione per i feed RSS

La pagina mostrata sopra mostra diversi feed RSS impostati dall'utente finale. Entriamo ora nel processo richiesto per la scansione. 

1. Scansione e identificazione della tecnologie

Tutti i possibili codici JavaScript caricati nel browser all'accesso ad una pagina possono essere identificati dalla pagina stessa visualizzando il codice sorgente così come mostrato in figura 3.

Figura 3:  tutti i JavaScript assieme al codice sorgente

Se siete in possesso dell'estensione Web Developer per Firefox potete visualizzare tutti gli script in una singola pagina così come mostrato in figura 4.

Figura 4: tutti i JavaScript eseguiti nella pagina dell'applicazione

L'esame di questi script JavaScript ci permette di ottenere le seguenti informazioni:

• L'uso di Dojo, un framework di sviluppo Ajax, emerge dal nome dojo.js. Il nome del file ci fornisce molti indizi quando andiamo ad identificare le tecnologie. Potremmo anche scansionare il file per un  per verificare quale versione del framework viene usata. Una tecnica simile può essere utilizzata anche per identificare l'uso di Microsoft Atlas e altre tecnologie simili. Queste informazioni poi ci consentiranno di individuare le vulnerabilità note delle architetture che stanno sotto la nostra applicazione.
• Dal browser possono essere visualizzati i file che, gestiti da un'applicazione di feed RSS, contengono funzioni al loro interno. Eccone una breve lista:
  • Il file rss_xml_parser.js contiene delle funzioni tipo processRSS() e GetRSS(). Queste funzioni recuperano feed RSS da un server e poi li processano.
  • Il file XMLHTTPReq.js contiene le funzioni makeGET() e makePOST() che processano le richieste Ajax.
  • Il file dojo.js contiene diverse altre funzioni.

Tutte queste informazioni possono essere organizzate meglio per ottenere una migliore visione del processo.

2. Informazioni esterne non affidabili

La scansione del codice HTML della pagina ci restituisce il seguente codice:

<select id="feeds" onchange="GetRSS();" name="feeds">
<option value="">Pick your feed</option>
<option value="http://www.cnn.com/business.xml">CNN business</option>
<option value="http://www.usatoday.com/business.xml">USA today</option>
<option value="http://xyz.sample.org/news.xml">XYZ business</option></select>

Il codice fa riferimento alla funzione GetRSS() che, ad uno ad uno, esegue delle richieste al proxy per recuperare da vari server i feed la cui affidabilità non può essere controllata.

Nella seconda parte dell'articolo entreremo nel dettaglio del processo di ricerca delle vulnerabilità. 

In questa seconda parte dell'articolo entriamo nel dettaglio del processo di ricerca delle vulnerabilità e cerchiamo di fornire dei metodi di protezione per le applicazioni web.

Punti di accesso al DOM

Dopo aver raccolto tutti gli script JavaScript possiamo iniziare ad individuare le strade attraverso le quali si ottiene accesso al DOM. Cercheremo dunque l'uso dell'istruzione document.* e limiteremo la ricerca a due potenziali candidati:

• document.getElementById(name).innerHTML: funzione usata da molte applicazioni per cambiare dinamicamente i livelli
• document.write(): una funzione usata allo stesso modo per cambiare i livelli HTML nel browser

Ci potrebbero essere tuttavia alcune altre istruzioni che modificano il DOM nel browser. A questo punto, tuttavia, dovremmo concentrarci sulle due funzioni precedenti. Nel sorgente del file cercate di trovare la seguente funzione nella quale è utilizzata l'istruzione innerHTML:

function processRSS (divname, response) {
    var html = "";
    var doc = response.documentElement;
    var items = doc.getElementsByTagName('item');
    for (var i=0; i < items.length; i++) {
        var title = items[i].getElementsByTagName('title')[0];
        var link = items[i].getElementsByTagName('link')[0];
                html += "" 
                + title.firstChild.data 
                + "

";
    }
    var target = document.getElementById(divname);
    target.innerHTML = html;
}

Funzioni e tracce di variabili per la scoperta di vulnerabilità

Possiamo organizzare tutte le informazioni ottenute nei passi precedenti e determinare, attraverso un debug, l'intero flusso della logica lato client dell'applicazione. Questa logica è mostrata in figura 5:

Figura 5: logica di esecuzione  e flusso dei dati per la funzione del feed delle news

Da questa illustrazione è chiaro che il proxy del feed filtra alcuni caratteri particolari, come < e >, rendendo di fatto impossibile iniettare JavaScript nel DOM. Ancora, dal momento che l'esecuzione modifica l'istruzione innerHTML nel DOM precaricato, non è possibile eseguire nessuno script. Ma osserviamo più da vicino la seguente linea di codice che costruisce dinamicamente l'HTML:

html += ""

Che cosa accade se una fonte di feed RSS non affidabile include un link nocivo? Il link non viene validato da nessuna parte come risulta evidente dal codice. Questo è un esempio di un nodo RSS che contiene un codice potenzialmente nocivo:

<title>Interesting news item</title>
<link>javascript:alert("Simple XSS")</link>
<description><![CDATA[]]></description>
<author>XYZ news</author>
<dc:date>2005-11-16T16:00:00-08:00</dc:date>

Notate come l'elemento link dell'XML contiene del JavaScript. Dunque quando un utente cliccherà quel il link lo script verrà eseguito all'interno del contesto del DOM. Questo processo è illustrato nella figura 6:

Figura 6: XSS con un link

L'inclusione di informazioni di una fonte non affidabile all'interno del DOM può mettere a rischio la sessione di un navigatore. Le applicazioni Web 2.0 solitamente mettono a disposizione in un'unica pagina informazioni prelevate da differenti fonti.

Facciamo un altro esempio per capire meglio questa tipologia di attacco.

Injection cross-dominio con JSON

JSON è una struttura di scambio di informazioni XML molto leggera e che può introdurre diverse informazioni aggiuntive. Molte applicazioni, come anche quelle di Google e Yahoo, hanno aggiunto ai loro Web service delle chiamate JSON. Con queste chiamate diverse informazioni cross-dominio possono essere intercettate e processate con funzioni specifiche.

Facciamo un esempio. Poniamo che un sito Web disponibile alla pagina http://blog.example.org ha ampliato i suoi servizi usando delle chiamate JSON per permettere a tutti di accedere alle informazioni usando JavaScript. Accediamo alle informazioni per l'id=10 puntando il browser o inviando una richiesta GET al seguente indirizzo:

Richiesta:
http://blog.example.org/Getprofile.html?callback=profileCallback&id=10

Risposta:
profileCallback({"profile":[{"name":"John","email":"john@my.com"}]})

Come si può vedere riceviamo in risposta del codice JSON incluso all'interno dell'istruzione profileCallback. Con questo codice la funzione  profileCallback() viene eseguita e l'output di JSON viene passato come argomento.

Allo stesso modo se richiediamo id=11 avremo la seguente risposta:

profileCallback({"profile":[{"name":"Smith","email":"smith@cool.com"}]})

Il nostro obiettivo, il sito example.com, ha integrato questo servizio nella sua applicazione. Se diamo uno sguardo al suo codice lato cliente e cerchiamo le istruzioni document.write otteniamo la seguente porzione di codice conservata nella pagina showprofile.html.

<script>
function profileCallback(result) {
     document.write(result.profile[0].name);
     document.write("<br />");
     document.write(result.profile[0].email);
}
</script>
<script src="http://blog.example.org/Getprofile.html?
          callback=profileCallback&id=10" src="text/javascript"></script>

Questo codice esegue dunque una chiamata cross-dominio al servizio di blog.example.org e processa il suo output nella funzione profileCallback. Chiamando questa pagina otteniamo il seguente output, mostrato nella figura qui in basso:

Figura 7: una semplice chiamata JSON

Questa applicazione integrata nel sito example.com utilizza informazioni JSON non affidabili inviate da un sito terzo e le include nel suo codice senza nessuna validazione. Questo metodo rende esposti i dati sensibili degli utenti, come ad esempio sessioni e cookie. Ciò significa che se uno dei client cerca di ottenere informazioni per l'id=101 e questo ha incluso all'interno del codice JavaScript nel campo e-mail, del tipo di quello visualizzato qui sotto in rosso, potrebbe eseguire del codice nocivo nel computer.

profileCallback({"profile":[{"name":"Jack","email":"<script>alert('JSON XSS');</script>"}]})

Nella figura qui sotto forniamo l'immagine del browser della vittima mentre accede al sito example.com:

Figura 8: Attacco XSS atraverso JSON

Applicazioni scritte in Ajax possono essere facilmente compromesse attraverso la gestione di informazioni non affidabili. In questo articolo ne abbiamo esaminate due che fanno transitare codici nocivi direttamente all'utente. Ne esistono comunque anche alcuni altri.

Contromisure

Per proteggere i browser lato-client è importante seguire una massima ripetuta più volte: "non affidarsi a informazioni di terze parti". Nella fase di design dell'applicazione è necessario definire con chiarezza l'ambito dell'applicazione e mettere a punto strumenti di validazione per tutte le informazioni che provengono da sorgenti esterne, siano esse in XML, RSS, JSON, JavaScript e così via. Questo processo è mostrato nella figura 9:

Figura 9: la validazione delle informazioni esterne

Per esempio, prima di inviare collegamenti al DOM è necessario farli filtrare da una semplice funzione, come quella mostrata qui in basso, che esamina qualsiasi tentativo di injection di codice JavaScript

function checkLink(link) {
   if(link.match(/javascript:|<|>/))
   {
      return false;
   } else {
      return true;
   }
}

È importante filtrare tutto il traffico in entrata prima che questo intacchi il DOM all'interno di un browser: una difesa per l'utente finale.

Conclusioni

Nell'ultimo periodo sono stati molti gli incidenti di sicurezza informatica causati da codice mal scritto in applicazioni Web 2.0. Le tecniche automatizzate o manuali di scansione dovranno essere potenziate con solidi meccanismi di individuazione degli errori che potrebbero intaccare il DOM lato client. Potrebbe essere una vera e propria sfida mettere in atto scansioni completamente automatiche per applicazioni Web 2.0, cosa che potrebbe essere risolta usando tecniche automatiche in combinazione con l'intelligenza dell'uomo. Alcune dei più vecchi attacchi come il Cross-Site Request Forgery (XSRF)  sono nuovamente tirati in ballo nell'era Web 2.0. XSS, XSRF e altri attacchi lato client compaiono in diverse vulnerabilità e avvisi di sicurezza per le applicazioni web di nuova generazione.

Il controllo delle applicazioni Web 2.0 deve essere eseguito con attenzione per scoprire possibili attacchi lato client e per mitigare il rischio sui sistemi degli utenti. Questo articolo ha cercato di gettare luce su alcuni potenziali attacchi e sulle tecniche di scansione utilizzate per identificare punti vulnerabili dell'applicazione. Basta scalfire un po' la superficie delle applicazione per scoprire che molte di esse sono vulnerabili a questo tipo di attacchi e che possono essere compromesse da utenti malintenzionati, virus e worm.

Sull'autore

Shreeraj Shah, BE, MSCS, MBA, è il fondatore di Net Square ed è a capo delle attività di consulenza, formazione e ricerca e sviluppo di Net Square. Ha lavorato prima in Foundstone, Chase Manhattan Bank e IBM. È anche l'autore di Hacking Web Services (Thomson) e co-autore di Web Hacking: Attacks and Defense (Addison-Wesley). Oltre a ciò ha pubblicato diversi advisory di sicurezza, software e whitepaper e ha presenziato in numerose conferenze come RSA, AusCERT, InfosecWorld, HackInTheBox, Blackhat, OSCON, Bellua, Syscan e altre. Ha un blog all'indirizzo http://shreeraj.blogspot.com/.

© 2006 SecurityFocus