Quando agisco come un server di autorizzazione (AS) che gestisce OAuth 2.0, penso che due principali funzionalità di sicurezza della libreria da controllare siano:
-
Impedire la fuoriuscita di token di accesso limitando l'URL di reindirizzamento . Nel flusso implicito, l'AS riceve una concessione di autorizzazione da un cliente di cui non può fidarsi. Per non distribuire i token di accesso a nessuno, la libreria dovrebbe consentire all'utente di specificare un elenco (bianco) di URL per ogni client di connessione. Nel test di penetrazione, dovresti verificare se puoi utilizzare un URL nel redirect_url che non corrisponde a uno degli URL nella whitelist (sarebbe un errore).
-
Prevenzione dei falsi e / o delle correzioni delle richieste cross-site con il parametro statale . Il parametro state è un valore casuale, generato dal client. Il parametro sarà quindi sempre incluso nella comunicazione successiva con l'AS. Consente al client di verificare che il token di accesso ricevuto corrisponda alla precedente richiesta di autorizzazione. Senza questo parametro, un utente malintenzionato potrebbe iniettare il proprio token di accesso e quindi concedere l'accesso alle risorse controllate dall'utente malintenzionato. L'utente finale potrebbe quindi ad es. pubblica i suoi dati sull'account dell'attaccante. Pertanto, per il test di penetrazione, è necessario verificare se la libreria convalida correttamente il parametro di stato o se è possibile modificare il valore.
Oh, e ho quasi dimenticato: OAuth 2.0 specifica chiaramente che si basa sul trasporto sicuro SSL / TLS. Pertanto, se non stai servendo esclusivamente il tuo AS su HTTPS, questo è un gran #FAIL nel rapporto sul test di penetrazione.
La specifica iniziale OAuth 2.0 RFC 6749, sezione 10 contiene già molte considerazioni sulla sicurezza. Inoltre, c'è una RFC aggiuntiva dedicata alla sicurezza OAuth 2.0: link
Un'altra grande risorsa che riassume tutto può essere trovata qui: link