Il flusso del codice di autorizzazione OAuth 2 è vulnerabile al Problema in questione confuso?

Question

Il flusso del codice di autorizzazione OAuth 2 è vulnerabile al Problema in questione confuso?

#1 da (1 voti)

1

Deputy Deputy Problem (noto anche come "The Devil Wears Prada") è una vulnerabilità di OAuth 2 che si verifica quando il protocollo viene utilizzato per l'autenticazione. In sostanza, un client dannoso ottiene un token per un utente e lo presenta a un secondo client. Se il secondo client accetta token come prova di autenticazione, il client dannoso può autenticarsi come utente verso un altro client.

Nella maggior parte delle spiegazioni di questa vulnerabilità, come link e Flusso implicito di OAuth e problema del delegato confuso , è suggerito che questo funziona solo per il flusso implicito.

Tuttavia, il flusso del codice di autorizzazione non dovrebbe risentire dello stesso problema? Sembra che un client malintenzionato possa ottenere un codice di autorizzazione per un utente e quindi offrire tale codice di autorizzazione a un secondo client. Il secondo client ora esegue una richiesta di backchannel al server di autorizzazione e, al completamento, il secondo client ritiene che stia comunicando con l'utente anziché con il client dannoso.

Questa analisi è corretta?

authorization oauth2 confused-deputy

posta Matthijs Melissen 05.12.2017 - 17:32

fonte

1 risposta

Leggi altre domande sui tag authorization oauth2 confused-deputy

Unix - Verifica automatica del checksum MD5 Definizione del timeout di inattività

score 1 · Accepted Answer

In Authentication Code grant flow, il server di autenticazione sarà in grado di capire che il codice di autenticazione è stato fornito a un client diverso dal secondo client.

Per ottenere il codice di autenticazione, al di sotto del campione malevolo verrà inviata una richiesta di esempio:

GET /authorize?response_type=code&client_id=<malicious client ID>&state=xyz
        &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com

Si noti che il server di autenticazione conserva una mappatura del codice di autenticazione e dell'ID client come risultato di una richiesta di codice di autenticazione riuscita.

Ora il client dannoso servirà questo codice di autenticazione all'URI di reindirizzamento per il secondo client e il secondo client a sua volta richiederà un token di autenticazione. Esempio come di seguito:

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

Si noti che l'ID client e il segreto sono codificati nell'intestazione Authorization , di conseguenza, quando auth server elabora tali informazioni, è in grado di stabilire se l'ID client nella richiesta corrisponde all'ID client che il codice di autenticazione è stato inizialmente assegnato a. In questo caso non c'è una corrispondenza, di conseguenza il server di autenticazione non concederà il token di accesso in risposta alla richiesta.

In altre parole, il controllo dell'ID cliente eseguito da auth server nel backend garantisce che tutti i token restituiti in cambio del codice di autorizzazione sono stati emessi per la propria applicazione.