Vulnerabilità OAuth e schemi di attacco

I server di autorizzazione OAuth devono validare rigorosamente il parametro redirect_uri. Se il server consente il matching per prefisso o con wildcard (ad esempio, accettando qualsiasi URL che inizi con "https://app.example.com"), un attaccante può creare una richiesta di autorizzazione che reindirizza a "https://app.example.com.attacker.com/steal" o a un open redirect sul dominio legittimo, sottraendo il codice di autorizzazione.

Senza protezione CSRF, un attaccante può avviare un flusso OAuth e indurre il browser della vittima a completare l'autorizzazione. La vittima autorizza così inavvertitamente il client dell'attaccante. Il parametro "state" (RFC 6749) impedisce questo attacco: il client genera uno state casuale, lo include nella richiesta e verifica che corrisponda nel callback. In caso di mancata corrispondenza, il flusso viene interrotto.

Sulle piattaforme mobili, app malevole possono registrare lo stesso schema URI personalizzato di un client OAuth legittimo e intercettare i codici di autorizzazione reindirizzati dopo l'autenticazione dell'utente. PKCE costituisce una difesa completa: il codice intercettato è inutilizzabile senza il code verifier che solo l'app legittima ha generato all'inizio del flusso.

Quando un ID token o un access token è incluso in un frammento dell'URL o in un parametro di query, le navigazioni successive da quella pagina includono l'URL nell'header Referer, esponendo potenzialmente il token a script di analisi di terze parti o a provider CDN. Utilizzare sempre il flusso del codice di autorizzazione con consegna dei token tramite back-channel per evitare che i token compaiano negli URL.

Quando un client supporta più provider OAuth, gli attacchi mix-up inducono il client a inviare all'endpoint dei token del Provider B un codice di autorizzazione ottenuto dal Provider A. Il client deve validare la claim "iss" negli ID token e associare il callback al provider specifico che ha avviato il flusso, usando il parametro state o JARM (JWT-Secured Authorization Response Mode).

Gli attacchi di falsificazione delle richieste dal lato server (SSRF) prendono di mira le implementazioni OAuth che effettuano richieste HTTP dal server verso redirect_uri. Se il server di autorizzazione recupera redirect_uri per verificarlo, un attaccante può fornire un indirizzo IP interno (ad esempio, http://169.254.169.254/latest/meta-data/) per accedere ai metadati dell'istanza cloud o ai servizi interni. Una validazione rigorosa di redirect_uri basata su una allowlist impedisce questo attacco.

Molte applicazioni usano la claim email di un ID token OIDC per collegare gli account tra diversi provider. Se un attaccante controlla un indirizzo email che corrisponde all'account della vittima presso un altro provider, può registrarsi con un provider diverso usando quell'email e ottenere accesso all'account della vittima. Difesa: collegare gli account solo tramite la coppia (iss, sub), mai solo tramite l'email.

Gli attacchi di confusione dell'algoritmo JWT sfruttano implementazioni che si affidano all'header "alg" per selezionare l'algoritmo di verifica. Attacco: cambiare "alg" da "RS256" a "HS256" e firmare il token usando la chiave pubblica del server come segreto HMAC, poiché la chiave pubblica è pubblica. Difesa: specificare sempre esplicitamente l'algoritmo previsto nel codice di verifica; non fidarsi mai del parametro alg nell'header del token.

Gli attaccanti registrano client OAuth malevoli con nomi e loghi apparentemente legittimi, quindi inviano link di phishing ai propri bersagli. La vittima visualizza una vera schermata di consenso OAuth (ospitata da Google, Microsoft e altri) relativa a un'applicazione malevola e concede l'accesso. Difesa: verificare che client_id corrisponda all'applicazione prevista; Google e Microsoft offrono programmi di verifica dei client per le app legittime.

L'escalation degli scope si verifica quando un client ottiene token con permessi più ampi di quelli autorizzati dall'utente. Difetti di implementazione che omettono la validazione degli scope sull'endpoint dei token, memorizzano nella cache token con scope combinati tra richieste diverse o non verificano che lo scope del token emesso non ecceda quello autorizzato possono tutti portare a un'escalation dei privilegi tramite OAuth.

Per proteggere le implementazioni OAuth: usare una validazione di redirect_uri con corrispondenza esatta, richiedere PKCE per tutti i client pubblici, validare il parametro state per la protezione CSRF, associare gli ID token tramite (iss, sub) e non tramite email, specificare esplicitamente gli algoritmi JWT previsti, richiedere scope minimi, usare access token di breve durata con rotazione dei refresh token e verificare l'aspetto della schermata di consenso per individuare rischi di imitazione del brand.

Principali attacchi OAuth: open redirect tramite validazione permissiva di redirect_uri (usare una corrispondenza esatta), CSRF in assenza del parametro state, intercettazione del codice sui dispositivi mobili (mitigata da PKCE), fuga di token negli URL, mix-up nelle configurazioni multi-provider (validare iss), SSRF tramite redirect_uri recuperato dal server, collisione della claim email (usare iss+sub), confusione dell'algoritmo JWT (fissare l'alg previsto) e phishing tramite schermate di consenso contraffatte.