Trovato come ottenere Oauth2 client_id lungo il segreto corrispondente ma redirect_uri è autorizzato come requisito. È ancora sicuro?

Question

Trovato come ottenere Oauth2 client_id lungo il segreto corrispondente ma redirect_uri è autorizzato come requisito. È ancora sicuro?

#1 da (1 voti)

1

Se ottieni un OAuth 2.0% diclient_id e un secret corrispondente, puoi teoricamente impersonare il sito web di destinazione.

induci la vittima a visitare il tuo URL;
Attraverso client_id e OAuth 2.0% corrispondente disecret li si registra silenziosamente in background; Il sistema OAuth 2.0 reindirizza al provider OAuth 2.0 dalla prima pagina Web, quindi il provider OAuth 2.0 reindirizza al valore del parametro redirect_uri (che di solito reindirizza al sito Web che ha avviato il log in). Il processo imposta un cookie di sessione che viene utilizzato sia per l'autenticazione sul sito Web che per l'interazione con l'API del provider OAuth 2.0.
A seconda della situazione, se l'utente ha già effettuato l'accesso sia sul sito Web reale che sul provider OAuth 2.0, può essere connesso al sito Web dell'utente malintenzionato senza dover inserire alcuna credenziale o fare clic su qualsiasi cosa . Quindi questo funziona silenziosamente come un attacco XSS dal punto di vista dell'utente.
Poiché l'utente si fida del vero sito Web con le credenziali di OAuth 2.0 rubate, ha dato l'autorizzazione al sito Web per accedere ai dati del provider OAuth 2.0. Tuttavia, poiché l'autore dell'attacco può impersonare tecnicamente il sito Web di destinazione tramite un cookie di sessione, l'utente malintenzionato può riutilizzare l'autorizzazione trusted nel parametro scope.

Ma nel mio caso, il provider OAuth 2.0 richiede l'impostazione di una lista bianca per il parametro redirect_uri , quindi è impossibile reindirizzare direttamente.

Mentre sfruttando un reindirizzamento completamente aperto sul sito Web reale potrebbe portare a una minaccia reale, Mi chiedo se le cose rimarranno sicure finché tale seconda vulnerabilità non viene sfruttata in base alle specifiche rfc6749 .

oauth2 exploit-development

posta user2284570 06.12.2018 - 03:05

fonte

1 risposta

Leggi altre domande sui tag oauth2 exploit-development

Come prevenire la persistente vulnerabilità XSS con il framework Java Struts 1? 127.0.0.1 accesso a Internet [chiuso]

score 1 · Answer 1

Supponendo che non ci siano ulteriori difetti logici nell'implementazione di OAuth 2.0 (l'implementazione è conforme alle specifiche), senza incatenare la tua scoperta con un altro problema come lo scripting cross-site sull'host in white list che ti permette di rubare il Token OAuth, hai ragione ad assumere che questo scenario non sia sfruttabile.

Sezione 10.6. della RFC copre questo scenario di attacco in modo molto dettagliato.

In order to prevent such an attack [authorization code redirection URI manipulation attack], the authorization server MUST ensure that the redirection URI used to obtain the authorization code is identical to the redirection URI provided when exchanging the authorization code for an access token. The authorization server MUST require public clients and SHOULD require confidential clients to register their redirection URIs. If a redirection URI is provided in the request, the authorization server MUST validate it against the registered value.