Covert Redirect: cos'è e come evitare i rischi di OAuth 2.0 e OpenID

Covert Redirect è una falla di sicurezza dei protocolli OAuth 2.0 e OpenID, usati da quasi tutti i grandi nomi come Google, Facebook, Microsoft, Paypal.

Ieri è stata annunciata da C|Net la “scoperta” di una falla di sicurezza chiamata Covert Redirect nei protocolli OAuth 2.0 e OpenID usati in pratica da quasi tutti i grandi nomi dei servizi digitali come Google, Facebook, Yahoo!, Paypal e molti altri.

La notizia è subito rimbalzata sui vari social network e ha suscitato non poca preoccupazione dopo l’onda del caso Heartbleed.

Dopo il nostro articolo ne hanno parlato:

I possibili rischi

Questa vulnerabilità rischia di compromettere seriamente la sicurezza delle informazioni degli utenti trasferite online, arrivando ad autorizzare i vari Facebook, Google, Linkedin, Microsoft, etc. a fornire i dati dell’utente a una terza parte con intenzioni malevoli, la quale ha inoltre anche la possibilità di redirigere l’utente a un url a sua scelta, dove la sicurezza dell’utente potrebbe essere nuovamente minata (pensiamo ad esempio all’uso che potrebbero fare app di phishing che portino l’utente su siti di banche o carte di credito).

Niente di nuovo, in realtà

Nota: a questo post c’è una semplice introduzione allo scambio sicuro di dati su web.

C’è da dire però che questa problematica non era per nulla sconosciuta, anzi è espressamente descritta nelle specifiche del protocollo OAuth 2.0 Nel flusso di OAuth2 il Client richiede ad un Authorization Server una chiave (Access Token) che gli permetta di ottenere delle risorse (Es. La vostra lista di amici su Facebook) da un Resource Server.

Flusso OAuth2

Il problema nasce nel punto (B), ovvero nell’unico punto in cui chi fornisce questo servizio deve “fidarsi” di quello che gli dice il client, ovvero la URL alla quale redirigere con le credenziali di richiesta del nostro Access Token. Se il protocollo OAuth2 viene implementato correttamente, nel momento della registrazione dell’app al servizio sarà necessario esplicitare correttamente la redirect_url alla quale il servizio redirigerà dopo l’autorizzazione.

Esempi

Nel primo esempio, immaginiamo di aver registrato su Facebook l’app con redirect_url :http://goodapp.com/oauth_redirect

Se qualcuno volesse redirigere il vostro login sul proprio sito (http://evil.com) non potrebbe farlo, perché i domini delle due URLs differirebbero e l’Authorization Server bloccherebbe subito la richiesta.

Nel secondo esempio, dietro alla redirect_url c’è un servizio di redirezione interna :

http://goodapp.com/oauth?redirect=http://goodapp.com/landing_page

In questo caso, l’attaccante può alterare il parametro query redirect e sostituire http://goodapp.com/landing_page  con  http://evil.com  forgiando quindi la seguente redirect_url: http://goodapp.com/oauth?redirect=http://evil.com

In questo modo, l’Authorization Server vede goodapp.com come dominio di richiesta e quindi autorizza il client che però redirige successivamente a http://evil.com cedendo di fatto il vostro Access Token(e quindi l’accesso ai vostri dati) all’utente che ha effettuato l’attacco.

La soluzione

La responsabilità di risolvere il seguente problema è suddivisa tra due parti:

1) Gli Identity Providers(Facebook, Google, etc) devono pre-registrare e richiedere la redirect_url esatta (la maggior parte di loro lo fa già)

2) I Client(le app sviluppate) non devono usare soft redirects nelle redirect_url dell’autorizzazione OAuth2 – e nel caso lo facciano devono controllare sempre la genuinità della URL passata.

Questa falla ha quindi avuto un potenziale impatto negativo sui nostri progetti? No.

“Caffeina ha deciso di usare fin dal principio un sistema di URL Routing, più sicuro perché, evitando la necessità di specificare dei soft redirect, si eliminano i rischi connessi alla vulnerabilità agendo direttamente alla radice del problema.”

Tiziano Tassi, CEO Caffeina


Stefano Azzolini

Stefano si è laureato in Ingegneria Informatica all'Università di Genova. Ha una lunga esperienza nello sviluppo software e nei suoi principali paradigmi e metodologie, fortemente orientato all'innovazione considera il Web la Nuova Piattaforma. In Caffeina ricopre il ruolo di CTO.