10. Considerazioni sulla sicurezza (Security Considerations)
Come framework flessibile ed estensibile, le considerazioni sulla sicurezza di OAuth dipendono da molti fattori. Le seguenti sezioni forniscono agli implementatori linee guida sulla sicurezza incentrate sui tre profili di client descritti nella sezione 2.1: applicazione web, applicazione basata su user agent e applicazione nativa.
Un modello di sicurezza OAuth completo e un'analisi, nonché il contesto per la progettazione del protocollo, sono forniti da [OAuth-THREATMODEL].
10.1. Autenticazione del client (Client Authentication)
Il server di autorizzazione (Authorization Server) stabilisce credenziali del client con i client di applicazioni 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 applicazioni web devono (MUST) garantire la riservatezza delle password del client e altre credenziali del client.
Il server di autorizzazione non deve (MUST NOT) emettere password del client o altre credenziali del client ai client di applicazioni native o basate su user agent ai fini dell'autenticazione del client. Il server di autorizzazione può (MAY) emettere una password del client o altre credenziali per un'installazione specifica di un client di applicazione nativa su un dispositivo specifico.
Quando l'autenticazione del client non è possibile, il server di autorizzazione dovrebbe (SHOULD) impiegare altri mezzi per validare l'identità del client - ad esempio, richiedendo la registrazione dell'URI di reindirizzamento del client o coinvolgendo il proprietario della risorsa (Resource Owner) per confermare l'identità.
10.2. Impersonificazione del client (Client Impersonation)
Un client malevolo può impersonare un altro client e ottenere l'accesso a risorse protette se il client impersonato non riesce a, o è incapace di, mantenere riservate le sue credenziali del client.
Il server di autorizzazione deve (MUST) autenticare il client ogni volta che è possibile. Se il server di autorizzazione non può autenticare il client a causa della natura del client, il server di autorizzazione deve (MUST) richiedere la registrazione di qualsiasi URI di reindirizzamento utilizzato per ricevere risposte di autorizzazione e dovrebbe (SHOULD) utilizzare altri mezzi per proteggere i proprietari delle risorse da tali client potenzialmente malevoli.
10.3. Token di accesso (Access Tokens)
Le credenziali del token di accesso (Access Token) (il token di accesso e il segreto emesso dal server di autorizzazione) possono essere utilizzate per ottenere l'accesso al server delle risorse (Resource Server). Le credenziali del token di accesso devono (MUST) essere protette da accessi non autorizzati.
I token di accesso hanno tipicamente una durata limitata e possono essere aggiornati quando scadono. Tuttavia, tali token possono essere intercettati e utilizzati da un attaccante. Le misure per mitigare l'impatto sulla sicurezza includono l'emissione di token con durata breve e ambito limitato.
10.4. Token di aggiornamento (Refresh Tokens)
Il server di autorizzazione può (MAY) applicare requisiti di archiviazione rigorosi per i token di aggiornamento (Refresh Token). Ad esempio, il server di autorizzazione può limitare la durata del token di aggiornamento o limitare l'ambito del token di aggiornamento.
Il server di autorizzazione deve (MUST) mantenere un legame tra il token di aggiornamento e il client al quale è stato emesso. Il token di aggiornamento deve (MUST) essere utilizzato solo dal client al quale è stato emesso.
10.5. Codici di autorizzazione (Authorization Codes)
La trasmissione del codice di autorizzazione (Authorization Code) dovrebbe (SHOULD) avvenire tramite un canale sicuro per garantire la riservatezza e l'autenticità del client.
Il server di autorizzazione deve (MUST) garantire che il codice di autorizzazione venga utilizzato una sola volta. Se un codice di autorizzazione viene utilizzato più di una volta, il server di autorizzazione deve (MUST) rifiutare la richiesta e dovrebbe (SHOULD), se possibile, revocare tutti i token precedentemente emessi sulla base di tale codice di autorizzazione.
10.6. Manipolazione dell'URI di reindirizzamento del codice di autorizzazione (Authorization Code Redirection URI Manipulation)
Se un attaccante intercetta un codice di autorizzazione, l'attaccante può tentare di sostituire l'URI di reindirizzamento utilizzato dal client con un URI controllato dall'attaccante.
Il server di autorizzazione deve (MUST) prevenire questo attacco richiedendo la registrazione dell'URI di reindirizzamento e validando l'URI di reindirizzamento quando il client scambia il codice di autorizzazione.
10.7. Credenziali password del proprietario della risorsa (Resource Owner Password Credentials)
Il tipo di autorizzazione tramite credenziali password del proprietario della risorsa è spesso utilizzato per motivi legacy o di migrazione. Questo tipo di autorizzazione dovrebbe (SHOULD) essere utilizzato solo quando esiste una relazione di fiducia elevata tra il proprietario della risorsa e il client.
10.8. Riservatezza delle richieste (Request Confidentiality)
I token di accesso, i token di aggiornamento, le password del proprietario della risorsa e le credenziali del client non devono (MUST NOT) essere trasmessi senza riservatezza. È raccomandato (RECOMMENDED) utilizzare TLS [RFC5246] versione 1.2 o successiva.
10.9. Garanzia dell'autenticità degli endpoint (Ensuring Endpoint Authenticity)
L'autenticazione del server TLS (definita in RFC5246) dovrebbe (SHOULD) essere utilizzata per verificare l'identità degli endpoint con cui il proprietario della risorsa e il client comunicano.
10.10. Attacchi di indovinamento delle credenziali (Credentials-Guessing Attacks)
Il server di autorizzazione deve (MUST) implementare protezioni contro attacchi brute force per proteggere il server di autorizzazione stesso e i suoi client da attacchi di indovinamento delle credenziali.
10.11. Attacchi di phishing (Phishing Attacks)
L'uso estensivo del reindirizzamento nella progettazione del protocollo OAuth crea opportunità per gli attaccanti di sfruttare il flusso del protocollo OAuth per lanciare attacchi di phishing.
Il server di autorizzazione dovrebbe (SHOULD) utilizzare meccanismi di autenticazione progettati per consentire al proprietario della risorsa di verificare visivamente l'entità presso cui si sta autenticando.
10.12. Falsificazione di richieste intersito (Cross-Site Request Forgery)
La falsificazione di richieste intersito (CSRF) è una tecnica di exploit in cui un attaccante induce l'user agent della vittima a inviare richieste non intenzionali all'insaputa della vittima.
Il client deve (MUST) utilizzare il parametro di richiesta « state » per mantenere lo stato tra la sua richiesta di endpoint di autorizzazione del client e il callback successivo per proteggersi dagli attacchi CSRF.
10.13. Clickjacking (Clickjacking)
Nel clickjacking, un attaccante registra un sito target fornito da un server legittimo in un iframe e lo posiziona sopra l'iframe come livello trasparente.
Il server di autorizzazione dovrebbe (SHOULD) utilizzare il campo di intestazione X-Frame-Options per prevenire attacchi di clickjacking.
10.14. Iniezione di codice e validazione dell'input (Code Injection and Input Validation)
Tutti i valori di input ricevuti dal server di autorizzazione, dal client e dal server delle risorse devono (MUST) essere validati per prevenire attacchi di iniezione.
10.15. Reindirizzatori aperti (Open Redirectors)
Il server di autorizzazione, l'endpoint di autorizzazione e l'endpoint di reindirizzamento del client non devono (MUST NOT) essere progettati per agire come reindirizzatori aperti.
10.16. Uso improprio del token di accesso per impersonare il proprietario della risorsa (Misuse of Access Token)
Nel flusso di autorizzazione implicita, un attaccante può utilizzare un token di accesso intercettato per impersonare un proprietario della risorsa impersonando un altro client.
Gli sviluppatori di client dovrebbero (SHOULD) adottare misure per garantire che i token di accesso siano utilizzati solo dal server delle risorse previsto.