[Gtug] Report Incontro Sicurezza su Google Plus (Prima parte)

Archiviata la bella esperienza dell’hackaton di Febbraio eccoci al quarto incontro del Milano GTUG dedicato agli aspetti di sicurezza legati a Google+ (ma non solo). Questa volta siamo ospiti nello splendido contesto di The Hub Milano, spazio di coworking, in via Paolo Sarpi a Milano, che in futuro potrebbe diventare la sede ufficiale dei nostri prossimi incontri.

Ospite d’eccezione e speaker della serata è Claudio Criscione, Security Test Engineer presso la sede Google di Zurigo. Milanese d’adozione (ha studiato al Politecnico), esperto di sistemi di sicurezza con esperienza in ambiti molto sensibili, lavora da oltre un anno in quella che è la seconda sede engineering per importanza nel mondo (dopo Mountain View, ovviamente). 

Nella premessa Claudio sottolinea come gli aspetti di sicurezza delle API sono trasversali a tutti i prodotti Google, ma particolarmente importanti in contesti aperti come Google Plus in cui spesso si accede a contenuti di terze parti di cui non si può conoscerne a priori i contenuti e l’affidabilità.

GooglePlus è infatti una piattaforma che contiene tante cose: non solo testi ma contenuti di tipo rich content (immagini, video, url esterni, e molto altro) in cui potenzialmente potrebbero nascondersi insidie pericolose.

Ma andiamo per gradi e partiamo proprio dalle API di GooglePlus, che si possono dividere in tre tipologie: 

• Il Bottone +1, che in verità fa molte altre cose (ad es. permette di condividere immediatamente il contenuto) 
• Le API REST di accesso ai contenuti 
• Le API di Hangout 

La prima è dedicata ai publishers e non è per gli sviluppatori, perchè evidentemente non c’e’ molto controllo su quello che il bottone fa e su come lo fa. Le terze sono API javascript, decisamente molto potenti ed interessanti, e che meriterebbero una serata dedicata (magari le dedicheremo un prossimo incontro). 

Le seconde sono appunto l’argomento della serata, per cui cominciamo con il dare un occhiata a come sono fatte e come si possono invocare. 

Si tratta di API di tipo REST (Representational State Transfer) a cui si accede componendo un URL con una determinata sintassi (che comprende i parametri della chiamata) e risponde con una struttura, in genere di tipo JSON, che contiene i dati richiesti. 

La reference guide si trova al seguente indirizzo, ed è sempre aggiornata all’ultima versione disponibile:
https://developers.google.com/+/api/latest/ 

In questo momento le API di GooglePlus sono in sola lettura degli stream, non ci sono chiamate che permettano di inserire contenuti. Su questa limitazione e sulla possibilità che vengano rilasciate API in scrittura in un secondo momento si è fatto molto “gossip” sul Web, ma Google non ha mai rilasciato alcuna dichiarazione ufficiale sulle motivazioni. Come sviluppatore personalmente la ritengo una mancanza ma le strategie di BigG sono certamente basate su una visione più completa del prodotto. 

Come già accennato lo stream contiene un sacco di oggetti, non solo testo ma immagini, video, riferimenti a contenuti esterni (URL) e molto altro. Per accedere alle API è necessario abilitare la funzionalità dalla console (come per tutti gli altri prodotti) e per cominciare ad imparare come utilizzarle si può giocare un po’ tramite l’API explorer. Data la natura delle API è meglio utilizzare la modalità autenticata. 

L’utilizzo delle API è molto semplice, vengono illustrati degli esempi in PHP ed in Java che permettono di accedere facilmente al proprio stream (identificato dal parametro “me” nell’URL), nascondendo al programmatore i dettagli delle chiamate REST e delle risposte JSON. Rimandiamo anche noi al ricco materiale online, si veda ad esempio il codice Java necessario a recuperare il proprio stream:
https://developers.google.com/+/api/latest/activities/list#examples 

Ora è il momento di servire il piatto forte della serata, ovvero analizzare tutti gli aspetti di sicurezza correlati all’utilizzo delle API stesse: in primis le questioni di autenticazione (principi di funzionamento di OAuth) ed infine le security pitfalls più comuni, legate alle pubblicazione di contenuti di terze parti sul proprio sito (attacchi XSS, uso del protocollo SSL, vulnerabilità mixed content, sanitizzazione dei contenuti).

Autenticazione 

I meccanismi di autenticazione sono importanti perchè nello sviluppare un applicazione reale molto spesso si ha la necessità di utilizzare i dati di qualcun altro: nel caso di GooglePlus il suo stream, i suoi contatti e le sue cerchie, e altro. Ma per accedere ai contenuti di terze parti è necessario ottenere l’autorizzazione del proprietario, ed è qui che entra in gioco OAuth.

Infatti ci si potrebbe chiedere: perchè non chiedere direttamente la password? Per vari motivi (abbastanza ovvi): consegnare la propria password ad una terza parte equivale ad un completo trasferimento di fiducia. Ed anche se la terza parte fosse fidata, con la password egli può accedere a tutto, non c’e’ modo di restringere l’ambito di accesso (profilazione).
Esiste una ricchissima letteratura che analizza questi aspetti, e numerosi prodotti che ne danno una soluzione più o meno complessa o più o meno sicura: molto spesso si sceglie un compromesso tra semplicità d’uso e robustezza e sicurezza della soluzione. 

Negli ultimi tempi viene spesso utilizzato OAuth 2.0, un protocollo open adottato da Google nonchè dai maggiori social networks. Si noti che esiste anche una versione precedente di OAuth (1.0) ma sebbene sia ancora utilizzata, risulta più complessa e “dolorosissima” per gli sviluppatori. 

Non ci addentriamo nei dettagli del protocollo, essendoci centinaia di siti sui quali approfondirne la conoscenza (compreso l’utile OAuth playground che permette di prendere dimestichezza con il protocollo), ma ci limitiamo ad evidenziarne i vantaggi principali: poter garantire l’accesso a terzi senza dover fornire la password e poter segmentare l’accesso a parti specifiche. 

I passi che un’applicazione deve fare per ottenere un’informazione da terze parti sono illustrati nel seguente schema:

1. L’utente interagisce con il sito MIOSITO, powered by G+ 
2. MIOSITO lo manda a Google per richiedere il permesso 
3. Google chiede all’utente se vuole autorizzare MIOSITO ad accedere alle risorse Google+ (con più o meno dettaglio a seconda della segmentazione offerta dal tipo di prodotto) 
4. Google restituisce all’utente un TOKEN (una stringa univoca e segreta) 
5. L’utente prende il token e lo manda a MIOSITO 
6. MIOSITO verifica il token passandolo a Google 
7. Google verifica che il TOKEN sia valido (visto che è stato emesso da lei stessa) e corrispondete al tipo di autorizzazione concessa, e consegna le informazioni. 

Rispetto ai punti critici prima discussi si noti che: 

1. la password non viene mai comunicata a MIOSITO 
2. il token è limitato nello scope, è come essere in una sandbox. 

Ed ora che siamo autenticati cosa succede? Per quanto tempo è valido l'accesso? Come posso mantenere al sicuro queste informazioni?

Esistono due grandi modalità di interazione: una veloce ed una di lunga durata.
Senza addentrarci nei dettagli del protocollo diciamo che il meccanismo di autenticazione restituisce un codice di accesso intermedio (AuthorizationCode) che è temporaneo e di brevissima durata, tramite il quale è possibile ottenere due tipi di token: un RefreshToken (di lunga durata, resta valido finchè l’utente stesso non lo revoca) ed un AccessToken (di breve durata). Inoltre il RefreshToken può essere utilizzato in ogni momento per ottenere un AccessToken.
Quindi una applicazione (o un sito) può decidere di effettuare un accesso ai dati terzi a breve termine (di durata pari ad una sessione di lavoro) utilizzando solamente l’AccessToken e senza bisogno di salvare il RefreshToken ; nelle sessioni successive dovrà ripetere l’intera sequenza di accesso (compresa la richiesta di autorizzazione da parte dell’utente). Oppure conservare il RefreshToken.
La prima modalità (appropriata per applicazioni residenti su device poco sicuri, come smartphone che possono essere smarriti o sottratti) si chiama UserAgentFlow, la seconda (appropriata per applicazioni lato server dove il refresh token può essere salvato ad esempio su un database) si chiama ServerFlow.
Se proprio un’applicazione su uno smartphone volesse conservare il RefreshToken sarebbe meglio che non lo facesse in chiaro (Claudio diffida dalla sicurezza dei metodi di crittazione, ma “un po’ di polvere magica crittografica” non fa male).

(fine prima parte, tra poco la seconda sulle trappole di sicurezza più comuni).

Disclaimer: questo resoconto è una rielaborazione indipendente degli argomenti presentati durante la serata, ma ogni opinione qui espressa è strettamente personale.

Pubblicato da

Tweet