OAuth (Open Authorization) è uno standard aperto che permette a un utente di autorizzare l'accesso ai propri dati da parte di un'applicazione di terze parti, senza condividere la password del proprio account. Gli utenti possono così effettuare l'autenticazione e autorizzare app esterne ad accedere ai propri dati e alle risorse archiviate su un server, come informazioni relative all'account, foto e documenti, senza bisogno di rivelare le proprie credenziali di accesso. OAuth viene utilizzato anche per gli accessi one-click, che permettono agli utenti di identificarsi su un servizio Web senza doversi iscrivere con nome utente e password ogni volta.
Quando un servizio Web si connette a un altro, viene utilizzato il protocollo OAuth per garantire un'interazione sicura senza richiedere agli utenti di condividere le proprie password.
Storia del protocollo OAuth
Condividere le password è sempre sconsigliato, per qualsiasi applicazione. Per questo le grandi aziende del settore IT come Google e Twitter hanno introdotto una soluzione chiamata OAuth.
Nel 2010, Google ha iniziato ad offrire ai piccoli creatori di app un modo per scrivere servizi che utilizzassero le informazioni dell'account Google invece di richiedere agli utenti di condividere con loro le password dei propri account Google. Anziché dover archiviare dati sensibili come le password e dover gestire la sicurezza degli account degli utenti, una app di terze parti può così utilizzare il sistema di Google per chiedere agli utenti di autenticarsi e salvare soltanto un token di accesso, sul quale è memorizzata l'autorizzazione dell'account Google. L'applicazione esterna utilizza quindi il token OAuth per accedere a una serie ben precisa di dati relativi all'account Google.
Nel corso degli anni il protocollo OAuth ha subìto diverse evoluzioni, con gli ultimi significativi miglioramenti nel 2012. Sono svariate le grandi aziende del settore IT che offrono l'integrazione OAuth per sviluppatori di terze parti. Aziende come Amazon, Netflix, PayPal, Microsoft, LinkedIn, Facebook e molti altri consentono agli sviluppatori esterni di integrare i dati relativi agli account degli utenti nelle proprie app, utilizzando OAuth.
Perché viene utilizzato il protocollo OAuth?
Prima dell'introduzione del protocollo OAuth, gli utenti dovevano creare un proprio account con credenziali distinte, su ogni servizio Web che intendevano utilizzare. Tuttavia due servizi non potevano condividere i dati a meno che non offrissero un'API che permettesse lo scambio dei dati tra i due. Anche ammettendo l'esistenza di una specifica API, il passaggio delle password tra i servizi costituisce da sempre una pericolosa vulnerabilità di sicurezza, perché in caso di data breach da parte di uno dei due, sarebbero esposti i dati privati degli utenti anche sugli altri servizi.
Il protocollo OAuth permette agli utenti di autorizzare app di terze parti ad accedere ai propri account per beneficiare di un'ampia gamma di funzionalità. Ad esempio, l'utilizzo dei dati del calendario Google per memorizzare un evento tramite un'app di terze parti, l'archiviazione delle impostazioni delle app sul cloud o magari l'analisi delle playlist musicali degli utenti per offrire loro nuovi suggerimenti di ascolto. In questo modo, le password non sono più necessarie per l'autorizzazione e gli utenti possono revocare l'accesso in qualsiasi momento. Chi sviluppa app di terze parti non deve far altro che memorizzare un token di accesso per recuperare i dati autorizzati che vanno archiviati in modo sicuro, ma non espongono le credenziali dell'utente.
Come funziona OAuth?
Tre entità sono coinvolte in una transazione OAuth:
- L'utente (la persona o organizzazione che autorizza l'accesso ai propri dati)
- Il fornitore di servizi OAuth (è l'app o il servizio che memorizza i dati e le credenziali dell'utente)
- Il consumer (l'applicazione che richiede l'accesso ai dati dell'utente)
OAuth utilizza una procedura specifica per garantire la sicurezza dei dati degli utenti e semplificare le richieste per il consumer. Per prima cosa, l'applicazione che vuole accedere ai dati (consumer) richiede un token di accesso OAuth al fornitore di servizi. Se non hanno già effettuato il login presso il fornitore di servizi, gli utenti sono invitati ad autenticarsi. Il fornitore di servizi mostra quindi a quali dati l'app consumer desidera accedere e chiede all'utente di approvare o negare l'accesso. Se l'utente dà il proprio consenso, il fornitore di servizi invia un token di accesso all'app consumer, che lo memorizza per future richieste di accesso. Una volta convalidato, il token di accesso sarà utilizzato in tutte le richieste di accesso ai dati dell'utente (sempre nell'ambito delle autorizzazioni concesse dall'utente).
Per motivi di sicurezza, i token di accesso hanno una certa scadenza, ma i fornitori di servizi offrono agli sviluppatori la possibilità di aggiornare i token di accesso per richieste future. Il periodo di validità di un token di accesso è impostato dal fornitore di servizi, che ne stabilisce la durata in base ai propri protocolli di sicurezza. Il token di accesso va però archiviato in modo sicuro perché può essere utilizzato da chiunque ne entri in possesso per ottenere i dati dell'utente ed eseguire operazioni per conto dell’utente.
Se gli utenti desiderano revocare l'accesso, possono farlo tramite il fornitore di servizi. Dopo la revoca dell'accesso, il consumer non potrà più accedere ai dati dell'utente sul servizio di terze parti, e nel momento in cui l'utente volesse autorizzare nuovamente l'accesso ai propri dati, dovrà effettuare di nuovo l'autenticazione sull'applicazione del fornitore di servizi. Nel caso in cui il consumer subisse un data breach con la divulgazione dei token di accesso, il fornitore di servizi potrebbe invalidare in modo proattivo tutti i token di accesso per proteggere i dati degli utenti.
Protocollo OAuth e OpenID a confronto
Quando i servizi consumer utilizzano OAuth, il fornitore di servizi fornisce l'accesso autorizzato ai dati solo dopo che l'utente dà il proprio consenso. OAuth è un modo per condividere i dati tramite un token di autorizzazione generato dopo che l'utente ha verificato le proprie credenziali. OpenID è differente da OAuth, ma i due vengono utilizzati insieme.
Il Single Sign-On (SSO) è un popolare sistema di sicurezza che utilizza un provider per autenticare gli utenti su più servizi. OpenID è uno dei primi protocolli SSO, introdotto nel 2005 per l'autenticazione in LiveJournal. Nel corso degli anni ha subìto alcuni aggiornamenti, ma è stato sempre considerato troppo complicato da implementare rispetto ad altri metodi dell'epoca, principalmente Facebook Connect. Poiché Facebook riscuoteva già grande successo, la maggior parte degli sviluppatori è passata a Facebook Connect per far sentire gli utenti più a loro agio nell'autenticarsi sulle proprie app.
Nel 2014, il codice di OpenID è stato riprogettato ed è stato successivamente incorporato in OAuth. Attualmente, OAuth utilizza OpenID come livello di autenticazione, mentre OAuth gestisce il livello di autorizzazione. Per l’utente non cambia molto, ma i consumer possono integrare più facilmente OAuth sia per autenticare gli utenti sia per ottenere l'accesso ai propri dati.
OAuth e SAML
Un vecchio sistema, simile a OAuth, è il Security Assertion Markup Language basato su XML. La differenza principale tra SAML e OAuth è che SAML esegue sia l'autenticazione che l'autorizzazione. OAuth utilizza invece OpenID come livello di autenticazione, ma non gestisce direttamente l'autenticazione. Le app che utilizzano SAML non necessitano di altri servizi per fornire l'autenticazione.
Un'altra caratteristica che differenzia i due protocolli è la lingua utilizzata per trasmettere i dati tra i servizi. SAML utilizza XML; OAuth utilizza invece JSON, il formato tradizionalmente preferito per trasferire dati. La maggior parte dei servizi utilizza principalmente JSON, rendendo di fatto il protocollo OAuth più facile da integrare.
OAuth 1.0 vs OAuth 2.0
Come qualsiasi altro protocollo, anche OAuth si è evoluto e migliorato nel tempo. Il vecchio OAuth 1.0 è più semplice da utilizzare rispetto alla versione aggiornata, ma non è più considerato un modo sicuro per lavorare con gli account utente. Pertanto la maggior parte dei fornitori di servizi consente l'accesso esclusivamente al suo sostituto, OAuth 2.0.
La versione OAuth 2.0 ha aggiunto due passaggi alla procedura di autorizzazione. Supporta il protocollo HTTPS e i signed secret, per cui i token non devono più essere crittografati sugli endpoint (dispositivi degli utenti). L'HTTPS crittografa già i token di accesso in transito, anche se alcuni servizi che memorizzano dati particolarmente sensibili come le informazioni di identificazione personale (PII) o i dati sanitari, crittografano ulteriormente i dati a riposo. Una critica che viene mossa riguardo al protocollo OAuth 2.0 è che esso consente il trasferimento di dati su canali non crittografati, quindi spetta agli sviluppatori il compito di adottare la crittografia TLS/SSL tra i canali.
Esempi di OAuth 2.0
Affinché gli sviluppatori di terze parti possano sfruttare il protocollo OAuth 2.0, il provider di servizi deve ovviamente averlo implementato nel proprio sistema. Tutti i maggiori social media utilizzano OAuth 2.0 per offrire l'integrazione delle proprie piattaforme con app esterne. Ciò rappresenta indubbiamente un vantaggio in termini di marketing che permette loro di espandere ancor di più la propria platea.
Da quando Google ha rilasciato per la prima volta il protocollo OAuth 2.0, molte app hanno scelto di utilizzarlo come provider SSO e come servizio per ottenere informazioni di base sull'utente. In un tipico scenario di utilizzo di OAuth 2.0, il consumer offre un pulsante “Accedi con Google” come opzione per creare un account. Appena l'utente effettua l'autenticazione, Google visualizza l'elenco di risorse e dati a cui il consumer avrà accesso se l'utente dà il proprio consenso.
Se l'utente rifiuta la richiesta di autorizzazione, il consumer non potrà accedere ai suoi dati. Se l'utente accetta, il fornitore di servizi fornisce al consumer un token di accesso valido solamente per i dati elencati nella richiesta di autorizzazione accettata dall'utente. Nella maggior parte delle principali piattaforme, un'app consumer andrà preventivamente verificata dal fornitore di servizi prima di poter accedere a determinati dati. In genere, il consumer definisce quali sono i dati di cui ha bisogno per funzionare e come saranno utilizzati tali dati. Il fornitore di servizi potrà preventivamente accettare o declinare la richiesta.
Il sistema OAuth viene utilizzato anche per integrare una piattaforma in altri servizi. Supponiamo che tu abbia sviluppato un'app che funziona direttamente con un prodotto Google tipo Gmail. Per poter leggere le email degli utenti, l'app necessita della loro autorizzazione. A questo punto entra quindi in gioco OAuth, utilizzato da Google per consentire alla tua app di interagire con l'account Gmail dell'utente. Per utilizzare Gmail all'interno della tua app, dovrai però specificare i dati necessari per il funzionamento dell'app e gli utenti dovranno poi autorizzare l'app ad accedervi.
OAuth è un protocollo sicuro?
Se implementato correttamente OAuth è sicuro. Da un lato il fornitore di servizi deve garantire che il consumer abbia l'autorizzazione dell'utente per accedere ai dati. Dall'altro lato il consumer deve utilizzare il protocollo TLS/SSL per stabilire una connessione protetta e trasferire i dati in forma crittografata. Il fornitore di servizi può garantire che i dati siano trasmessi in maniera sicura richiedendo ai consumer l'utilizzo di connessioni crittografate e rifiutando qualsiasi canale non crittografato.
Rischi legati al protocollo OAuth
Sebbene sia un sistema indubbiamente più sicuro rispetto alla condivisione delle credenziali, OAuth non è esente da rischi. Di seguito analizziamo alcune minacce a cui le organizzazioni dovrebbero prestare attenzione quando permettono agli utenti di collegare app esterne ai propri account utilizzando OAuth.
Phishing
Il phishing è uno dei rischi principali legati all'utilizzo di OAuth. I cybercriminali utilizzano link a pagine Web malevole che richiedono agli utenti di autenticarsi ai propri account. Nonostante la pagina riproduca in tutto e per tutto il contenuto e la grafica di quella ufficiale relativa a un servizio che utilizza OAuth, invece di autenticarsi al servizio ufficiale come credono, gli utenti inseriscono in realtà le proprie credenziali sulla pagina di phishing dei truffatori. Per evitare di cadere nel tranello, è importante che gli utenti controllino sempre l'indirizzo mostrato nella finestra di popup del browser di autenticazione per assicurarsi che il sito sia legittimo.
In una campagna di phishing che abbiamo scoperto, i criminali hanno ottenuto le credenziali degli account Microsoft degli utenti modificando i parametri della stringa di query dell'URL per reindirizzare gli utenti su un sito malevolo per il furto delle credenziali.
La pagina di phishing mostrava un finto messaggio di autorizzazione Microsoft che sembrava del tutto legittimo alla maggior parte degli utenti. La pagina richiedeva agli utenti di accedere al proprio account Microsoft, ma anziché autenticare gli utenti, trasmetteva ai truffatori le credenziali di accesso dell'account Microsoft delle vittime. Avere accesso agli account Microsoft degli utenti, potrebbe aver permesso ai criminali di ottenere dati degli utenti, impossessarsi dei loro account, o accedere ad account degli utenti su altri servizi in cui magari utilizzavano le stesse credenziali di accesso.
Autorizzazioni troppo estese
Spesso quando gli utenti installano e autorizzano app tramite OAuth, cliccano su “accetta” senza leggere attentamente quali autorizzazioni stanno concedendo alle app. Concedere autorizzazioni di accesso particolarmente estese costituisce un potenziale rischio per la sicurezza dei dati.
Le app di terze parti possono essere facilmente compromesse. I cybercriminali possono ad esempio utilizzare l'accesso OAuth per violare e impossessarsi degli account cloud degli utenti. Fino a quando il token OAuth non viene revocato in modo esplicito, i criminali hanno accesso permanente all'account e ai dati dell'utente, anche nel caso in cui l'utente modifichi la password dell'account cloud o utilizzi l'autenticazione a due fattori (2FA).
Dalla nostra ricerca abbiamo scoperto che molte app basate su OAuth per Office 365 hanno livelli elevati di autorizzazioni. Ecco un esempio dei nostri risultati:
- Il 30% degli utenti dispone di app come MailMerge365 con autorizzazione “Invia posta per conto di altri”.
- Il 30% degli utenti dispone di app come TypeApp con l'autorizzazione “Gestisci configurazione di Exchange”.
- Il 70% degli utenti ha mediamente nove app con l'autorizzazione “Invia posta come utente” (come ad esempio l'app Task in A Box).
- Gli utenti Microsoft 365 hanno in media 34 app con l'autorizzazione “Accedi ai dati dell'utente in qualsiasi momento” (come nel caso di OneSync).
- Gli utenti Google Workspace con app di terze parti nella categoria “giochi” hanno in media 10 giochi.
App OAuth dannose
Alcune app e le loro richieste di autorizzazione OAuth sono palesemente malevole. I nostri ricercatori hanno monitorato ad esempio una campagna di attacco denominata OiVaVoii con la pubblicazione di app malevole che sembrano provenire da sviluppatori di app attendibili. Ecco il suo funzionamento:
- I cybercriminali si impossessano dell'account del creatore dell'app.
- Fingendosi lo sviluppatore originale, i criminali creano un'app dannosa e inviano richieste di autorizzazione agli utenti, molti dei quali dirigenti di alto livello, tramite e-mail.
- Gli utenti ignari autorizzano l'app, credendo che provenga dallo sviluppatore attendibile.
- Con le autorizzazioni OAuth concesse, i criminali prendono il controllo dell'account della vittima.
In questa campagna abbiamo riscontrato come i truffatori siano riusciti ad impossessarsi degli account appartenenti ad amministratori delegati, direttori generali, ex membri del consiglio di amministrazione e presidenti. Solitamente il furto dell'account deriva dall'installazione di app OAuth malevole che sottraggono i token o le credenziali OAuth.
Il fatto che le app sembravano essere state pubblicate da sviluppatori riconosciuti ha dato un sostanziale vantaggio ai cybercriminali, con diverse vittime ignare che sono cadute nel tranello finendo per concedere l'autorizzazione ad app malevole. Le autorizzazioni riguardavano principalmente l'accesso alla casella di posta (in lettura e scrittura), che consentiva loro di:
- Inviare e-mail malevole sia all'interno che all'esterno dell'organizzazione
- Rubare informazioni preziose
- Creare regole per la casella di posta tramite cui i criminali continuavano a ricevere la posta degli utenti anche dopo l'attacco
Figura 1: Screenshot di una richiesta di autorizzazione OAuth da un’app malevola.
Abuso tramite App OAuth legittime
Contactually è un'app cloud perfettamente legittima pensata per i professionisti del settore immobiliare che aiuta loro a gestire clienti e vendite. Ma nelle mani sbagliate, le sue potenti funzionalità permettono ai cybercriminali di scalare i privilegi mantenendo l'accesso sull'ambiente della vittima.
Abbiamo rilevato una campagna iniziata con il classico phishing via email, per compromettere gli utenti all'interno delle aziende prese di mira. Utilizzando gli account compromessi, i cybercriminali hanno autorizzato l'app Contactually e configurato le regole che reindirizzavano o eliminavano la posta elettronica. Tali regole servivano con tutta probabilità per inoltrare la posta delle vittime ad account esterni ed eliminare poi le prove dell'attacco.
Contactually è uno sviluppatore perfettamente legittimo. L'app ha però autorizzazioni piuttosto estese, come l'accesso completo ai contatti degli utenti e l'accesso in lettura e scrittura alla loro posta elettronica. Come del resto qualsiasi client di posta elettronica, e comunque ben entro i limiti delle funzionalità pubblicizzate dall'app.
Tuttavia, compromettendo l'account e autorizzando l'app all'interno dell'ambiente, come hanno fatto nella campagna da noi rilevata, i criminali hanno potuto sfruttare tali funzioni per causare seri danni.