Clickjacking, una vulnerabilità che affligge ogni browser
Durante OWASP 2008, evento internazionale dedicato alla sicurezza informatica, i due ricercatori americani Robert “RSnake” Hanses e Jeremiah Grossman, avrebbero dovuto presentare uno studio riguardo le possibili implicazioni di una vulnerabilità presente in tutti i browser maggiormente diffusi.
Le richieste di alcuni vendor e la gravità del problema rilevato li ha però spinti a rimandare la pubblicazione del loro lavoro a quando verrà trovata una soluzione. Tale decisione ha attirato parecchia attenzione sull’argomento, generando numerose ipotesi e speculazioni su quale potrebbe essere la natura di una vulnerabilità così grave e quali rimedi andrebbero adottati.
Il clickjacking é un problema conosciuto da tempo e legato all’architettura web più che ai browser, le sue implicazioni sono però state sottovalutate. In particolare la diffusione del web2.0 ha aperto la strada ad una serie di nuovi metodi per sfruttare la falla.
In pratica l’attacco avviene tramite un oggetto integrato in una pagina web, come un iframe nascosto o un plugin Flash, che esegue delle azioni non volute se cliccato. Tramite DHTML e CSS, l’attaccante é in grado di nascondere il componente in diversi modi non rilevabili dall’utente, il quale può essere facilmente spinto a cliccare l’oggetto.
Le conseguenze sono estremamente varie, a patto ovviamente di disporre delle informazioni e condizioni necessarie. Ad esempio, se la vittima é autenticata in FaceBook e visita una pagina contenente un attacco simile, é possibile rendere pubblico il suo profilo o aggiungere un contatto senza che se ne accorga.
Attualmente, la difesa migliore consiste nella disabilitazione del codice lato client. Gli stessi ricercatori affermano che Firefox + NoScript é in grado di bloccare il 99,99% delle casistiche. Per il restante 0.01 bisogna configurare il plugin in modo che blocchi gli iframes.
Il problema architetturale alla base del clickjacking, consiste nella possibilità di caricare contenuti provenienti da diverse fonti nella stessa pagina web, come ad esempio filmati youtube o widgets per la generazione di mappe. Per la normale navigazione dell’utente tale proprietà é fondamentale ma rappresenta un grosso rischio per quanto riguarda la sicurezza poiché non é previsto un modo per valutare l’affidabilità delle risorse esterne di una pagina.
Non sarà semplice trovare una soluzione efficace in grado di difendere l’utente senza limitare le funzionalità dei contenuti web. Probabilmente si punterà verso l’introduzione di uno o più parametri opzionali negli header HTTP per specificare se una pagina può o meno caricare le risorse esterne in base ad una eventuale Access Control List. Attualmente sembra la direzione più rapida e che richiede meno modifiche, anche se non basta per risolvere completamente il problema. Inoltre necessita di modifiche lato server in quanto gli sviluppatori web dovrebbero specificare quali pagine possono caricare contenuti esterni e da quali fonti possono reperirli, cosa non sempre fattibile.


