JavaScript Hijacking Vulnerability 2.0

Ha fatto fin troppo scalpore la notizia di qualche giorno fa riguardo la sicurezza delle applicazioni Web 2.0 basate, per la maggiore, sull’utilizzo di JavaScript.

Dato che l’allarme non è fasullo ma lo sono in parte le pratiche consigliate per risolvere il problema, scrivo il mio punto di vista scaturito dopo 3 giorni di brainstorming personale per risolvere almeno 1 dei problemi inerenti questo tipo di attacco.

Di cosa stiamo parlando? Il problema non è semplicissimo da capire, tanto meno immediato da replicare e cercherò di fare del mio meglio per spiegarlo in modo comprensibile.

L’attacco si basa su login insicuri, facilmente reperibili in una serie numerosa di siti più o meno noti. Per login non sicuro si intende una pagina che richiede un’autenticazione basata soprattutto su un cookie contenente, nel caso di sviluppatori meno preparati, dati sensibili.

I “biscottini” non sono sicuri, non lo sono mai stati e probabilmente mai lo saranno, salvo rare eccezioni basate su SSL.

E’ comunque una buona pratica non salvare mai dati sensibili in questi cookie, soprattutto dati che permetterebbero a chiunque, una volta letti, di autenticarsi in una qualsivoglia area privata.

Quali conseguenze per la sicurezza? Il succo del discorso è che JavaScript è totalmente dinamico e qualunque pagina di qualunque sito potrebbe inserire un tag di tipo script, aggiungendo un frame nascosto capace di autenticarsi in un sito visitato recentemente, basato su un cookie per l’autenticazione, per leggere poi il contenuto di tale frame e reperire i dati sensibili dell’utente ignaro dell’accaduto.

Allo stesso tempo esistono numerosissimi metodi per modificare il comportamento di elementi e oggetti nativi del linguaggio, in grado di modificare il comportamento di JSON, dell’assegnazione di Array, Object e addirittura del comportamento stesso del DOM.

Tramite pratiche non certo immediate ma possibili diventa quasi “un gioco” prendere le informazioni inviate e ricevute da Ajax ma non è più complicato sfruttare la dinamicità del linguaggio per manipolare il comportamento del codice client remoto al fine di sfruttare a proprio piacere i dati, quindi il problema non riguarda esclusivamente Ajax.

Esiste un modo per difendersi? Questa è la nota dolente. Il report che ha fatto scalpore è, a detta di molti sviluppatori, Douglas Crockford compreso (ci siamo indirettamente scambiati opinioni negli ultimi giorni), assolutamente forviante.

In primo luogo l’analisi è stata basata sui più noti framework client che, salvo rare eccezioni, non possono in alcun modo risolvere la problematica.

La sicurezza è, infatti, una responsabilità dello sviluppatore, non di questa o quella libreria, è assolutamente inutile quindi puntare il dito contro jQuery, Mootools o Dojo perchè non sono certo queste librerie a causare il problema, casomai i loro utilizzatori se poco preparati sull’argomento.

Chiarito questo punto restano gi altri consigli, anch’essi discutibili.

Inviare i dati tramite POST piuttosto che GET non serve assolutamente a risolvere il problema, dato che è possibile modificare il comportamento dell’oggetto XMLHttpRequest; non ha alcun senso, quindi, rassicurare qualcuno sull’uso di POST poichè questo non risolverebbe la problematica.

Utilizzare un id di sessione è altrettanto poco rassicurante dato che fino alla chiusura del browser, o perlomeno entro un tempo stabilito dal server, la sessione rimarrà valida e l’attacco riuscirebbe altrettanto facilmente.

Vero è che nel caso delle sessioni sarebbe molto più difficile risalire ai dati di autenticazione, come è altrettanto vero che se lo scopo è leggere le informazioni del servizio di un utente questa pratica aumenterà la sicurezza di tale servizio di 0 punti.

Nonostante abbia perso, personalmente, tempo e risorse per tentare di evitare che un oggetto nativo risultasse valido, seppur modificato, mi sono praticamente arreso alla meravigliosa dinamicità del JavaScript, crackandomi da solo tutti i tentativi fatti minuto dopo minuto per risolvere questo o quell’altro problema.

L’unico browser capace di resistere alle modifiche, tramite appositi stratagemmi, sembra essere FireFox mentre Internet Explorer, anche in questa occasione deludente per anomalia di comportamento, e Opera sembrano essere vulnerabili a prescindere.

Per concludere?

I think that proposing marginally secure wrappers around the data will encourage people to depend on tricks for their security instead of doing the correct thing, which is to never send data to strangers.

Non bisogna dipendere da stratagemmi più o meno validi per aumentare la sicurezza dei propri applicativi ma fare le cose in modo corretto e soprattutto mai inviare dati sensibili agli sconosciuti.

Non salvate i dati sensibili nei cookie, non pensate che il vostro codice client sia impenetrabile, non lasciate mai al client il compito di garantire la sicurezza del vostro applicativo e soprattutto approfondite le problematiche sulla sicurezza on-line lato server, JavaScript rimane un linguaggio utile, divertente, facile e potente… ma solo uno sviluppatore server accorto saprà come sfruttarlo per aumentare la cosiddetta User Experience senza rinunciare alla sicurezza dei dati.

Un ultimo consiglio personale: non leggete mai un solo report riguardo un problema di sicurezza, documentatevi quanto più possibile e leggete le opinioni di più fonti, soprattutto se il rapporto in questione consiglia soluzioni, accertatevi che siano veramente valide.