Il flusso OAuth 2.0 usa un parametro redirect_uri: dopo l'autorizzazione, il server rimanda l'utente (con il codice di autorizzazione o il token) a quell'URL. Se il server non valida rigorosamente dove può reindirizzare, un attaccante manipola quel parametro per farsi consegnare il codice/token a un URL che controlla lui – e con quello accede all'account della vittima.
Le varianti dell'attacco: redirect_uri puntato a un dominio dell'attaccante, o a un open redirect presente sul sito legittimo (una pagina ?url=... che rimbalza ovunque – da cui il codice viene poi rubato tramite il referer o un secondo salto), o il furto del codice sfruttando validazioni deboli (match parziale del dominio, sottodomini non previsti).
Le difese, lato server di autorizzazione e client:
- allowlist esatta dei
redirect_uriregistrati – match completo, non parziale, non per prefisso (il match per prefisso è aggirabile:https://sito.com.attaccante.com) - PKCE (Proof Key for Code Exchange) – ormai raccomandato per tutti i client: lega il codice di autorizzazione a chi lo ha richiesto, così un codice intercettato è inutilizzabile da altri
- il parametro
stateper legare la richiesta alla risposta (anti-CSRF del flusso), niente token nei frammenti URL dove non serve
È un promemoria che l'OAuth/OIDC è potente ma pieno di dettagli che, sbagliati, aprono voragini – il redirect è il più classico. La regola trasversale: validare rigorosamente dove mandi dati sensibili, con allowlist esatte e mai match approssimativi – lo stesso principio che vale contro l'SSRF e l'open redirect in generale.