Attacchi a OAuth 2.0

OAuth 2.0 è il protocollo di delega dell’autorizzazione alla base del login con Google, GitHub, Facebook e di migliaia di integrazioni API. La sua complessità — flussi multipli, parametri critici, redirect URI — genera una superficie di attacco ampia. La voce OAuth 2.0 descrive il funzionamento corretto; questa voce si concentra sulle vulnerabilità più sfruttate.

CSRF sul parametro state

Il parametro state di OAuth 2.0 serve come token anti-CSRF: il client lo genera casualmente, lo invia al server di autorizzazione, e verifica che lo stesso valore ritorni nel callback. Se il client non lo verifica, un attaccante può eseguire un OAuth CSRF:

1. L’attaccante avvia un flusso di autorizzazione con il proprio account sul provider (es. Google).
2. Ottiene l’URL di callback con il codice di autorizzazione relativo al proprio account.
3. Inganna la vittima a visitare quell’URL (es. tramite un <img> con src sul callback).
4. Se il server dell’applicazione non verifica state, associa l’account Google dell’attaccante all’account della vittima.

La vittima si autentica successivamente con le proprie credenziali ma in realtà entra nell’account collegato all’attaccante — o viceversa, l’attaccante può accedere all’account della vittima tramite il proprio account social.

Difesa: generare state con almeno 128 bit di entropia, legarlo alla sessione, e verificarne la corrispondenza nel callback prima di usare il codice di autorizzazione.

Authorization Code Interception

Nel flusso Authorization Code, il codice viene inviato al client tramite redirect URI. Se il server di autorizzazione non valida rigorosamente la redirect_uri:

• URI parzialmente corrispondenti: il server accetta https://app.it/callback/extra anche se registrato solo https://app.it/callback.
• URI con path traversal: https://app.it/callback/../attacker.
• Open redirect nel client: il server valida la redirect_uri esatta, ma quella pagina ha un open redirect che reindirizza il browser (e il codice nel parametro URL) verso il sito dell’attaccante.

Difesa: confronto esatto della redirect_uri con quella registrata — nessuna corrispondenza parziale, nessun wildcard nel percorso.

Token Leakage nell’header Referer

Nel flusso Implicit (deprecato ma ancora presente), l’access token viene passato direttamente nel frammento URL (#access_token=...). Alcune implementazioni lo spostano in un parametro query (?access_token=...), che finisce nell’header Referer delle richieste successive verso risorse di terze parti (analytics, CDN, immagini esterne) — esponendo il token a server non fidati.

Difesa: non usare il flusso Implicit. Usare Authorization Code + PKCE anche per client pubblici (SPA, mobile).

PKCE Downgrade

PKCE (Proof Key for Code Exchange) è l’estensione che protegge il flusso Authorization Code per client pubblici: il client genera un code_verifier segreto, invia il suo hash (code_challenge) al server di autorizzazione, e dimostra il possesso del verifier quando scambia il codice.

Se il server di autorizzazione non richiede obbligatoriamente PKCE, un client malevolo o un attacco di intercettazione può completare lo scambio del codice senza possedere il code_verifier — annullando la protezione.

Difesa: il server di autorizzazione deve rifiutare richieste di token che non includono il code_verifier se il flusso è stato avviato con PKCE.

Token Scope Escalation

Se il server di autorizzazione non valida che gli scope richiesti al momento dello scambio del codice corrispondano a quelli approvati dall’utente, un client può richiedere scope aggiuntivi al momento dell’emissione del token.

Mix-Up Attack

In scenari con più provider OAuth configurati, un attaccante può far credere al client che la risposta di un provider malevolo provenga da un provider legittimo, portando all’uso di token cross-provider. La difesa è l’uso di iss (issuer) nel token e la verifica dell’issuer lato client.

Relazione con altri argomenti

• OAuth 2.0 — funzionamento corretto del protocollo.
• OpenID Connect — estensione di OAuth 2.0 per l’autenticazione.
• CSRF — il parametro state è un token anti-CSRF applicato a OAuth.
• Open Redirect — spesso combinato per intercettare authorization code.
• JWT — i token emessi da OAuth 2.0 sono spesso JWT; vedi Attacchi ai JWT.
• OWASP Top 10 — A07 Identification and Authentication Failures.