Qual è lo scopo del controllo redirect_uri di OAuth 2.0?

Non convalidando redirect_uri un provider OAuth può essere utilizzato come vettore di phishing ideale. Il redirect_uri è un indirizzo utilizzato dai provider OAuth come posizione per fornire access_token mediante un reindirizzamento del browser. Il popolare provider di OAuth Facebook si è imbattuto in molte vulnerabilità relative al reindirizzamento OAuth.

In questo attacco, l'attaccante presenta alla vittima un URL di un portale di autenticazione che la vittima si fida (come Facebook) e, utilizzando questo portale di autenticazione, il token di accesso segreto della vittima viene consegnato a un server HTTP controllato dall'attaccante.

L'autenticazione riguarda l'intenzione, ingannare un utente e consentire l'accesso a una risorsa non voluta è una vulnerabilità.

Modificato in base ai commenti. In precedenza pensavo che l'OP si riferisse alla convalida redirect_uri durante la richiesta di autorizzazione e collegata a un esempio di attacco qui . Ho aggiornato la risposta di seguito.

TL; DR: se è necessario registrare un URL di reindirizzamento statico ed è strettamente corrispondente dal provider, non credo che il redirect_uri sarà richiesto durante la richiesta del token di accesso.

I requisiti di registrazione (3.1.2.2) indicano che l'URI di reindirizzamento deve essere registrato. Tuttavia, non tutti i provider eseguono corrispondenze esatte dell'URI di reindirizzamento, sebbene le specifiche lo richiedano. La specifica OAuth tenta più contromisure per evitare queste possibilità, con redirect_uri < - > requisito di binding del codice di autorizzazione descritto nel Modello di minaccia e Security Considersations RFC (5.2.4.5) .

Ad esempio, GitHub ha abbinato i prefissi URL, che portano all'attacco descritto qui di Egor Homakov. In particolare, i bug 1 e 2 consentivano a un utente malintenzionato di utilizzare un URI di reindirizzamento elencato in bianco per ottenere un codice e quindi di utilizzare tale codice per completare il flusso di callback e ottenere l'accesso all'account della vittima. In questo caso, il client (Gist) ha inviato l'URI di reindirizzamento corretto al provider (GitHub) e GitHub non avrebbe concesso il token di accesso se avesse verificato che l'URI di reindirizzamento fosse lo stesso utilizzato durante la richiesta di autorizzazione:

It was flawed: no matter what redirect_uri the Client sent to get a token, the Provider responded with valid access_token.

The attacker could hijack the authorization code issued for a "leaky" redirect_uri, then apply the leaked code on real Client's callback to log in Victim's account.

Per riassumere, redirect_uri è richiesto quando si ottiene un token di accesso per garantire che un codice trapelato da un reindirizzamento a una pagina in cui l'utente malintenzionato può inserire il codice non comprometta immediatamente il flusso OAuth. Una panoramica più completa del vettore di attacco è descritta qui da Egor pure:

The attack is straightforward: find a leaking page on the client's domain, insert cross domain image or a link to your website, then use this page as redirect_uri. When your victim will load crafted URL it will send him to leaking_page?code=CODE and victim's user-agent will expose the code in the Referrer header.

Now you can re-use leaked authorization code on the actual redirect_uri to log in the victim account.

Remediation: flexible redirect_uri is a bad practise. But if you need it, store redirect_uri for every code you issue and verify it on access_token creation.

Come ha detto Egor, link 1 :

all oauth exploits are based on tampering with the redirect_uri parameter.

e link 2 :

Vector 2. If spec was implemented properly then tampering redirect_uri to other, "leaky", values is pointless. Because to obtain access token you must send redirect_uri value with client creds. If actual redirect_uri was "leaky" and not equal real redirect_uri Client will not be able to obtain access_token for this code.

redirect_uri è il callback per il client che riceve Authorization Code .   Il Cliente tratta chiunque porti il codice come proprietario di risorse.

L'attaccante può sostituire redirect_uri con uno malevolo nel passaggio A per ottenere il codice.   Quindi può ricostruire e attivare l'uri per dirottare la sessione che appartiene al proprietario della risorsa.

Tuttavia, ogni codice ha il corrispondente redirect_uri che è stato emesso per ,   vale a dire, il codice verrà calcolato in base al% di co_de inquinato nel passaggio C.

Si noti che la richiesta nel passaggio D è effettuata dal cliente. Utilizzerà sempre la forma corretta di redirect_uri . Infine, Authorization Server risulta che il codice non corrisponde all'URI, quindi nessun token verrà risposto al punto E.