10. Considerazioni sulla sicurezza (Security Considerations)
Come framework flessibile ed estensibile, le considerazioni sulla sicurezza di OAuth dipendono da molti fattori. Le sezioni seguenti forniscono agli implementatori linee guida di sicurezza focalizzate sui tre profili di client descritti nella Sezione 2.1: applicazione Web, applicazione basata su user-agent e applicazione nativa.
Un modello e un'analisi completi della sicurezza di OAuth, nonché il contesto della progettazione del protocollo, sono forniti da [OAuth-THREATMODEL].
10.1. Autenticazione del client (Client Authentication)
Il server di autorizzazione stabilisce credenziali del client con i client di tipo applicazione Web ai fini dell'autenticazione del client. Il server di autorizzazione è incoraggiato a considerare mezzi di autenticazione del client più forti di una password del client. I client di tipo applicazione Web devono garantire la riservatezza delle password del client e delle altre credenziali del client (MUST).
Il server di autorizzazione non deve emettere password del client o altre credenziali del client a client di applicazioni native o basate su user-agent ai fini dell'autenticazione del client (MUST NOT). Il server di autorizzazione può emettere una password del client o altre credenziali per una specifica installazione di un client di applicazione nativa su uno specifico dispositivo (MAY).
Quando l'autenticazione del client non è possibile, il server di autorizzazione dovrebbe impiegare altri mezzi per validare l'identità del client, per esempio richiedendo la registrazione dell'URI di reindirizzamento del client o coinvolgendo il proprietario della risorsa nella conferma dell'identità (SHOULD). Un URI di reindirizzamento valido non è sufficiente a verificare l'identità del client quando si richiede l'autorizzazione del proprietario della risorsa, ma può essere usato per impedire la consegna di credenziali a un client contraffatto dopo aver ottenuto tale autorizzazione.
Il server di autorizzazione deve considerare le implicazioni di sicurezza dell'interazione con client non autenticati e adottare misure per limitare la potenziale esposizione di altre credenziali, per esempio token di aggiornamento, emesse a tali client.
10.2. Impersonificazione del client (Client Impersonation)
Un client malevolo può impersonare un altro client e ottenere accesso a risorse protette se il client impersonato non riesce, o non è in grado, di mantenere riservate le proprie credenziali del client.
Il server di autorizzazione deve autenticare il client ogni volta che è possibile (MUST). Se non può autenticare il client a causa della natura del client, il server di autorizzazione deve richiedere la registrazione di ogni URI di reindirizzamento usato per ricevere risposte di autorizzazione (MUST) e dovrebbe usare altri mezzi per proteggere i proprietari delle risorse da tali client potenzialmente malevoli (SHOULD). Per esempio, può coinvolgere il proprietario della risorsa per aiutare a identificare il client e la sua origine.
Il server di autorizzazione dovrebbe imporre un'autenticazione esplicita del proprietario della risorsa e fornire al proprietario della risorsa informazioni sul client e sull'ambito e la durata dell'autorizzazione richiesta (SHOULD). Spetta al proprietario della risorsa esaminare tali informazioni nel contesto del client corrente e autorizzare o negare la richiesta.
Il server di autorizzazione non dovrebbe elaborare automaticamente richieste di autorizzazione ripetute, senza interazione attiva del proprietario della risorsa, se non autentica il client o non si basa su altre misure per garantire che la richiesta ripetuta provenga dal client originale e non da un impersonatore (SHOULD NOT).
10.3. Token di accesso (Access Tokens)
Le credenziali dei token di accesso, nonché qualsiasi attributo riservato del token di accesso, devono essere mantenute riservate durante il transito e l'archiviazione (MUST) e condivise solo tra il server di autorizzazione, i server delle risorse per i quali il token è valido e il client a cui il token è stato emesso. Le credenziali dei token di accesso devono essere trasmesse solo usando TLS come descritto nella Sezione 1.6, con autenticazione del server come definita da [RFC2818] (MUST).
Quando si usa il tipo di grant implicito, il token di accesso viene trasmesso nel frammento URI, il che può esporlo a parti non autorizzate.
Il server di autorizzazione deve garantire che parti non autorizzate non possano generare, modificare o indovinare token di accesso validi (MUST).
Il client dovrebbe richiedere token di accesso con il minimo ambito necessario (SHOULD). Il server di autorizzazione dovrebbe tenere conto dell'identità del client quando decide come soddisfare l'ambito richiesto (SHOULD) e può emettere un token di accesso con meno diritti di quelli richiesti (MAY).
Questa specifica non fornisce alcun metodo affinché il server delle risorse assicuri che un token di accesso presentato da un dato client sia stato emesso a quel client dal server di autorizzazione.
10.4. Token di aggiornamento (Refresh Tokens)
I server di autorizzazione possono emettere token di aggiornamento ai client di applicazioni Web e ai client di applicazioni native (MAY).
I token di aggiornamento devono essere mantenuti riservati durante il transito e l'archiviazione (MUST) e condivisi solo tra il server di autorizzazione e il client a cui sono stati emessi. Il server di autorizzazione deve mantenere il vincolo tra un token di aggiornamento e il client a cui è stato emesso (MUST). I token di aggiornamento devono essere trasmessi solo usando TLS come descritto nella Sezione 1.6, con autenticazione del server come definita da [RFC2818] (MUST).
Il server di autorizzazione deve verificare il vincolo tra token di aggiornamento e identità del client ogni volta che l'identità del client può essere autenticata (MUST). Quando l'autenticazione del client non è possibile, il server di autorizzazione dovrebbe impiegare altri mezzi per rilevare l'abuso dei token di aggiornamento (SHOULD).
Per esempio, il server di autorizzazione potrebbe impiegare la rotazione dei token di aggiornamento, nella quale un nuovo token di aggiornamento viene emesso con ogni risposta di aggiornamento del token di accesso. Il token precedente viene invalidato ma conservato dal server di autorizzazione. Se un token di aggiornamento viene compromesso e successivamente usato sia dall'attaccante sia dal client legittimo, uno dei due presenterà un token invalidato, informando il server di autorizzazione della violazione.
Il server di autorizzazione deve garantire che parti non autorizzate non possano generare, modificare o indovinare token di aggiornamento validi (MUST).
10.5. Codici di autorizzazione (Authorization Codes)
La trasmissione dei codici di autorizzazione dovrebbe avvenire su un canale sicuro (SHOULD), e il client dovrebbe richiedere l'uso di TLS con il proprio URI di reindirizzamento se l'URI identifica una risorsa di rete (SHOULD). Poiché i codici di autorizzazione sono trasmessi tramite reindirizzamenti dello user-agent, possono essere potenzialmente divulgati attraverso la cronologia dello user-agent e gli header HTTP Referer.
I codici di autorizzazione operano come credenziali bearer in chiaro, usate per verificare che il proprietario della risorsa che ha concesso l'autorizzazione presso il server di autorizzazione sia lo stesso proprietario della risorsa che ritorna al client per completare il processo. Pertanto, se il client si affida al codice di autorizzazione per la propria autenticazione del proprietario della risorsa, l'endpoint di reindirizzamento del client deve richiedere TLS (MUST).
I codici di autorizzazione devono essere di breve durata e a uso singolo (MUST). Se il server di autorizzazione osserva più tentativi di scambiare un codice di autorizzazione con un token di accesso, dovrebbe tentare di revocare tutti i token di accesso già concessi sulla base del codice compromesso (SHOULD).
Se il client può essere autenticato, il server di autorizzazione deve autenticare il client e garantire che il codice di autorizzazione sia stato emesso allo stesso client (MUST).
10.6. Manipolazione dell'URI di reindirizzamento del codice di autorizzazione
Quando richiede autorizzazione usando il tipo di grant con codice di autorizzazione, il client può specificare un URI di reindirizzamento tramite il parametro "redirect_uri". Se un attaccante può manipolare il valore dell'URI di reindirizzamento, può far sì che il server di autorizzazione reindirizzi lo user-agent del proprietario della risorsa verso un URI sotto il controllo dell'attaccante con il codice di autorizzazione.
Un attaccante può creare un account presso un client legittimo e avviare il flusso di autorizzazione. Quando lo user-agent dell'attaccante viene inviato al server di autorizzazione per concedere accesso, l'attaccante acquisisce l'URI di autorizzazione fornito dal client legittimo e sostituisce l'URI di reindirizzamento del client con un URI sotto il proprio controllo. Poi induce la vittima a seguire il link manipolato per autorizzare l'accesso al client legittimo.
Una volta al server di autorizzazione, alla vittima viene presentata una richiesta normale e valida per conto di un client legittimo e fidato, e la vittima la autorizza. La vittima viene quindi reindirizzata a un endpoint controllato dall'attaccante con il codice di autorizzazione. L'attaccante completa il flusso inviando il codice al client usando l'URI di reindirizzamento originale fornito dal client. Il client scambia il codice con un token di accesso e lo collega all'account client dell'attaccante, che può ora accedere alle risorse protette autorizzate dalla vittima.
Per prevenire questo attacco, il server di autorizzazione deve garantire che l'URI di reindirizzamento usato per ottenere il codice di autorizzazione sia identico all'URI di reindirizzamento fornito quando il codice viene scambiato con un token di accesso (MUST). Il server di autorizzazione deve richiedere ai client pubblici la registrazione degli URI di reindirizzamento (MUST) e dovrebbe richiederla ai client confidenziali (SHOULD). Se nella richiesta viene fornito un URI di reindirizzamento, il server di autorizzazione deve validarlo rispetto al valore registrato (MUST).
10.7. Credenziali password del proprietario della risorsa
Il tipo di grant con credenziali password del proprietario della risorsa è spesso usato per ragioni legacy o di migrazione. Riduce il rischio complessivo della memorizzazione di nomi utente e password da parte del client, ma non elimina la necessità di esporre al client credenziali altamente privilegiate.
Questo tipo di grant comporta un rischio maggiore rispetto agli altri, perché mantiene l'anti-pattern della password che questo protocollo cerca di evitare. Il client potrebbe abusare della password, oppure la password potrebbe essere divulgata involontariamente a un attaccante, per esempio tramite file di log o altri registri mantenuti dal client.
Inoltre, poiché il proprietario della risorsa non controlla il processo di autorizzazione dopo aver consegnato le proprie credenziali al client, il client può ottenere token di accesso con un ambito più ampio di quello desiderato dal proprietario della risorsa. Il server di autorizzazione dovrebbe considerare l'ambito e la durata dei token di accesso emessi tramite questo tipo di grant.
Il server di autorizzazione e il client dovrebbero minimizzare l'uso di questo tipo di grant e utilizzare altri tipi ogni volta che è possibile (SHOULD).
10.8. Riservatezza della richiesta (Request Confidentiality)
Token di accesso, token di aggiornamento, password del proprietario della risorsa e credenziali del client non devono essere trasmessi in chiaro (MUST NOT). I codici di autorizzazione non dovrebbero essere trasmessi in chiaro (SHOULD NOT).
I parametri "state" e "scope" non dovrebbero includere informazioni sensibili del client o del proprietario della risorsa in testo in chiaro, poiché possono essere trasmessi su canali non sicuri o archiviati in modo non sicuro (SHOULD NOT).
10.9. Garanzia dell'autenticità degli endpoint
Per prevenire attacchi man-in-the-middle, il server di autorizzazione deve richiedere l'uso di TLS con autenticazione del server come definita da [RFC2818] per qualsiasi richiesta inviata agli endpoint di autorizzazione e token (MUST). Il client deve validare il certificato TLS del server di autorizzazione come definito da [RFC6125] e in conformità con i propri requisiti di autenticazione dell'identità del server (MUST).
10.10. Attacchi di indovinamento delle credenziali
Il server di autorizzazione deve impedire agli attaccanti di indovinare token di accesso, codici di autorizzazione, token di aggiornamento, password del proprietario della risorsa e credenziali del client (MUST).
La probabilità che un attaccante indovini token generati, e altre credenziali non destinate a essere gestite dagli utenti finali, deve essere minore o uguale a 2^(-128) (MUST) e dovrebbe essere minore o uguale a 2^(-160) (SHOULD).
Il server di autorizzazione deve usare altri mezzi per proteggere le credenziali destinate all'uso da parte degli utenti finali (MUST).
10.11. Attacchi di phishing
La diffusione ampia di questo protocollo e di protocolli simili può abituare gli utenti finali alla pratica di essere reindirizzati a siti Web nei quali viene chiesto loro di inserire le password. Se gli utenti finali non verificano attentamente l'autenticità di tali siti prima di inserire le credenziali, gli attaccanti possono sfruttare questa pratica per rubare le password dei proprietari delle risorse.
I fornitori di servizi dovrebbero cercare di educare gli utenti finali sui rischi degli attacchi di phishing e fornire meccanismi che rendano facile confermare l'autenticità dei propri siti. Gli sviluppatori di client dovrebbero considerare le implicazioni di sicurezza del modo in cui interagiscono con lo user-agent, per esempio esterno o incorporato, e la capacità dell'utente finale di verificare l'autenticità del server di autorizzazione.
Per ridurre il rischio di attacchi di phishing, i server di autorizzazione devono richiedere TLS su ogni endpoint usato per l'interazione con l'utente finale (MUST).
10.12. Cross-Site Request Forgery
La Cross-Site Request Forgery (CSRF) è un attacco nel quale un attaccante induce lo user-agent di un utente finale vittima a seguire un URI malevolo, per esempio fornito come link, immagine o reindirizzamento ingannevole, verso un server fidato, di solito grazie alla presenza di un cookie di sessione valido.
Un attacco CSRF contro l'URI di reindirizzamento del client consente a un attaccante di iniettare il proprio codice di autorizzazione o token di accesso. Ciò può portare il client a usare un token di accesso associato alle risorse protette dell'attaccante invece che a quelle della vittima, per esempio salvando le informazioni del conto bancario della vittima in una risorsa protetta controllata dall'attaccante.
Il client deve implementare protezione CSRF per il proprio URI di reindirizzamento (MUST). Questo viene tipicamente realizzato richiedendo che ogni richiesta inviata all'endpoint di reindirizzamento includa un valore che lega la richiesta allo stato autenticato dello user-agent, per esempio un hash del cookie di sessione usato per autenticare lo user-agent. Il client dovrebbe usare il parametro di richiesta "state" per consegnare questo valore al server di autorizzazione quando effettua una richiesta di autorizzazione (SHOULD).
Una volta ottenuta l'autorizzazione dall'utente finale, il server di autorizzazione reindirizza lo user-agent dell'utente finale al client con il valore di vincolo richiesto contenuto nel parametro "state". Tale valore consente al client di verificare la validità della richiesta confrontandolo con lo stato autenticato dello user-agent. Il valore usato per la protezione CSRF deve contenere un valore non indovinabile, come descritto nella Sezione 10.10 (MUST), e lo stato autenticato dello user-agent, per esempio cookie di sessione o local storage HTML5, deve essere mantenuto in una posizione accessibile solo al client e allo user-agent, cioè protetta dalla same-origin policy (MUST).
Un attacco CSRF contro l'endpoint di autorizzazione del server di autorizzazione può consentire a un attaccante di ottenere l'autorizzazione dell'utente finale per un client malevolo senza coinvolgere o avvisare l'utente finale.
Il server di autorizzazione deve implementare protezione CSRF per il proprio endpoint di autorizzazione e garantire che un client malevolo non possa ottenere autorizzazione senza la consapevolezza e il consenso esplicito del proprietario della risorsa (MUST).
10.13. Clickjacking
In un attacco di clickjacking, un attaccante registra un client legittimo e poi costruisce un sito malevolo nel quale carica la pagina Web dell'endpoint di autorizzazione del server di autorizzazione in un iframe trasparente sovrapposto a una serie di pulsanti fittizi, attentamente costruiti per trovarsi direttamente sotto pulsanti importanti della pagina di autorizzazione. Quando un utente finale clicca un pulsante visibile ingannevole, in realtà sta cliccando un pulsante invisibile sulla pagina di autorizzazione, per esempio un pulsante "Authorize". Questo consente all'attaccante di indurre un proprietario della risorsa a concedere accesso al suo client senza che l'utente finale ne sia consapevole.
Per prevenire questa forma di attacco, le applicazioni native dovrebbero usare browser esterni invece di incorporare browser nell'applicazione quando richiedono l'autorizzazione dell'utente finale (SHOULD). Nella maggior parte dei browser più recenti, l'uso di iframe può essere impedito dal server di autorizzazione mediante l'header non standard "x-frame-options". Questo header può avere i valori "deny" e "sameorigin", che bloccano rispettivamente qualsiasi framing o il framing da siti con origine diversa. Per browser più vecchi, possono essere usate tecniche JavaScript di frame-busting, ma potrebbero non essere efficaci in tutti i browser.
10.14. Iniezione di codice e validazione dell'input
Un attacco di iniezione di codice si verifica quando un input o un'altra variabile esterna viene usata da un'applicazione senza sanificazione e causa una modifica alla logica dell'applicazione. Ciò può consentire a un attaccante di accedere al dispositivo applicativo o ai suoi dati, causare denial of service o introdurre un'ampia gamma di effetti collaterali malevoli.
Il server di autorizzazione e il client devono sanificare, e validare quando possibile, qualsiasi valore ricevuto, in particolare i valori dei parametri "state" e "redirect_uri" (MUST).
10.15. Reindirizzatori aperti (Open Redirectors)
Il server di autorizzazione, l'endpoint di autorizzazione e l'endpoint di reindirizzamento del client possono essere configurati impropriamente e operare come reindirizzatori aperti. Un reindirizzatore aperto è un endpoint che usa un parametro per reindirizzare automaticamente uno user-agent alla posizione specificata dal valore del parametro senza alcuna validazione.
I reindirizzatori aperti possono essere usati in attacchi di phishing, o da un attaccante per far visitare agli utenti finali siti malevoli usando il componente authority dell'URI di una destinazione familiare e fidata. Inoltre, se il server di autorizzazione consente al client di registrare solo parte dell'URI di reindirizzamento, un attaccante può usare un reindirizzatore aperto gestito dal client per costruire un URI di reindirizzamento che supererà la validazione del server di autorizzazione ma invierà il codice di autorizzazione o il token di accesso a un endpoint sotto il controllo dell'attaccante.
10.16. Uso improprio del token di accesso per impersonare il proprietario della risorsa nel flusso implicito
Per i client pubblici che usano flussi impliciti, questa specifica non fornisce alcun metodo affinché il client determini a quale client sia stato emesso un token di accesso.
Un proprietario della risorsa può delegare volontariamente l'accesso a una risorsa concedendo un token di accesso al client malevolo di un attaccante, a causa di phishing o di un altro pretesto. Un attaccante può anche rubare un token tramite qualche altro meccanismo e poi tentare di impersonare il proprietario della risorsa fornendo il token di accesso a un client pubblico legittimo.
Nel flusso implicito (response_type=token), l'attaccante può facilmente sostituire il token nella risposta del server di autorizzazione, rimpiazzando il vero token di accesso con quello emesso in precedenza all'attaccante.
Anche i server che comunicano con applicazioni native e si affidano a un token di accesso passato nel canale di ritorno per identificare l'utente del client possono essere compromessi in modo simile da un attaccante che crea un'applicazione compromessa capace di iniettare token di accesso rubati arbitrari.
Qualsiasi client pubblico che assuma che solo il proprietario della risorsa possa presentargli un token di accesso valido per la risorsa è vulnerabile a questo tipo di attacco.
Questo tipo di attacco può esporre all'attaccante, cioè al client malevolo, informazioni sul proprietario della risorsa presso il client legittimo. Consentirà inoltre all'attaccante di eseguire operazioni presso il client legittimo con gli stessi permessi del proprietario della risorsa che aveva originariamente concesso il token di accesso o il codice di autorizzazione.
L'autenticazione dei proprietari delle risorse presso i client è fuori dall'ambito di questa specifica. Qualsiasi specifica che usi il processo di autorizzazione come forma di autenticazione delegata dell'utente finale al client, per esempio un servizio di accesso di terze parti, non deve usare il flusso implicito senza meccanismi di sicurezza aggiuntivi che consentano al client di determinare se il token di accesso è stato emesso per il suo uso, per esempio limitando il token di accesso a un'audience (MUST NOT).