.jpg)
Il software open source ha reso possibile la creazione di siti web di altissima qualità a grandi compagnie, ma anche a piccole aziende e per questo gode della nostra stima incondizionata. Ultimamente, però, stanno venendo al pettine alcuni nodi che rischiano di minarne la reputazione.
Dopo il disastro di Heartbleed, il bug che ha reso vulnerabili i due terzi dei server web collegati alla Rete, è il turno del "covert redirect" (reindirizzamento silente), un problema scoperto dal ricercatore Jing Wang e al quale sono sono soggetti moltissimi siti che usano OAuth e OpenID per loggare i propri utenti.
Proprio come successo con Heartbleed, tra i "moltissimi siti" di cui sopra figurano grandi nomi del Web: da Google a Linkedin, passando per Facebook e Yahoo (che sembra proprio non mancare mai), stavolta si trovano tra i siti vulnerabili anche quelli di Microsoft, che da Heartbleed non erano stati toccati.
Venendo al bug vero e proprio, questa vulnerabilità permette ai cybercriminali di provare a rubare dati personali mascherando le proprie richieste illecite con una finestra di richiesta di accesso a un servizio web famoso assolutamente indistinguibile da quella autentica.
Non tutti si son lasciati cogliere impreparati. Linkedin era già all'opera per risolvere i potenziali problemi già due mesi fa.
In pratica, cliccando su di un link "malevolo", contenuto in un messaggio di posta o in una pagina web costruita appositamente, i cybercriminali fanno apparire una maschera di login a uno dei servizi scelti tra quelli colpiti dal bug in cui si specifica che la web app "civetta" ha richiesto l'accesso ai dati. Se l'utente procede al login, i dati vengono prelevati e inviati a un server predisposto dai criminali.
Per fare un esempio, è possibile che un utente clicchi su uno di questi link malevoli e ottenga come effetto l'apparizione di una richiesta di Facebook ad autorizzare un'app. Solo che mentre in passato nella finestra della richiesta apparivano degli indirizzi web che potevano mettere in guardia l'utente, sfruttando il covert redirect viene visualizzato l'indirizzo legittimo e quindi diventa molto complicato evitare la truffa.
Scendendo ancora di più nel dettaglio, la differenza tra avere un'app vulnerabile e una che crea pericoli sta tutta nel modo in cui lo sviluppatore ha registrato la sua creazione sui siti dei provider. Come spiega anche l'ottimo post su Caffeinalab, se abbiamo creato un'app per Facebook e l'abbiamo registrata sul famoso sito con un reindirizzamento "fisso" come "http://lamiaapp.com/oauth_redirect", non corriamo rischi perché se qualcuno cercasse di usare un reindirizzamento truffaldino il link sarebbe sicuramente diverso da quello che abbiamo indicato.
Se, invece, avessimo deciso di registrare l'app con un reindirizzamento "dinamico", allora avremmo usato un indirizzo con un parametro che diventa vulnerabile. La stringa sarebbe stata qualcosa tipo "http://lamiaapp.com/OAUTH?redirect=http://lamiaapp.it/paginaqualsiasi". Così facendo, un attaccante può usare la prima parte della stringa per fingere di usare la nostra app (http://lamiaapp.com/OAUTH?redirect=) ma usare in fondo un url a sua scelta sul quale mandare i dati o dirottare la navigazione dei malcapitati (basta sostituire " http://lamiaapp.it/paginaqualsiasi" con qualsiasi indirizzo).
La situazione è ancora più grave se si pensa che questa vulnerabilità è in realtà il frutto di una caratteristica ben documentata e nota da tempo. Addirittura, nella documentazione di Auth 2.0 si mette proprio in guardia gli sviluppatori contro l'eventualità di attacchi, incoraggiandoli a prendere le dovute precauzioni (che consistono semplicemente nel non registrare redirect parametrizzati presso i provider).
Quali sono, quindi, le conseguenze di questo bug? Innanzitutto, bisogna precisare che non è possibile "chiuderlo" a priori, ma sta a chi sviluppa siti e app che si appoggiano a servizi più importanti (tipo Facebook o Google) sistemare il problema, eliminando il redirect parametrizzato.
Purtroppo, molti di questi sviluppatori sono molto piccoli e non hanno le risorse o il tempo di sistemare il problema. Bisognerà quindi attendere che i fornitori di identità (Google, Microsoft, etc) obblighino questi sviluppatori ad aggiornare i loro servizi, sospendendoli finché non avranno messo in sicurezza il problema.
Dal canto nostro, l'unica cosa da fare è tenere gli occhi aperti e concedere autorizzazioni all'accesso solo quando sono strettamente necessarie. Niente ok a giochi utilizzabili altrimenti o a programmi che non conosciamo.