Registrazione OAuth2 del client: redirect_uri dovrebbe essere univoco tra i client?

2

Quando gestisci un Server di autorizzazione OAuth2 :

The authorization server MUST require the following clients to register their redirection endpoint:

o Public clients.

o Confidential clients utilizing the implicit grant type.

The authorization server SHOULD require all clients to register their redirection endpoint prior to utilizing the authorization endpoint.

...

Lack of a redirection URI registration requirement can enable an attacker to use the authorization endpoint as an open redirector as described in Section 10.15.

C'è un ulteriore vantaggio in termini di sicurezza nell'imposizione di un vincolo di unicità su redirect_uri s registrati? Cioè, ogni dato redirect_uri potrebbe essere associato al massimo a un particolare client?

Penso in particolare al caso dei client pubblici, dove redirect_uri è l'unico mezzo con cui il server di autorizzazione deve identificare il client (poiché il client non è in grado di proteggere le credenziali del cliente), ma sono anche interessato a risposte private clienti.

Sono state rilevate vulnerabilità se un utente malintenzionato poteva registrare un nuovo client con lo stesso redirect_uri di un client esistente?

    
posta bjmc 23.03.2016 - 16:54
fonte

3 risposte

2

Non c'è davvero un buon modo per garantire in modo sicuro che un client sia quello che dice di essere, quindi non ha davvero senso cercare di rendere ogni URI di reindirizzamento univoco per un singolo client. L'unico motivo per cui si registrano gli URI è quello di impedire che lo scenario di reindirizzamento aperto menzionato nella documentazione, che renderebbe banale da dire, configurare un client malevolo a cui si effettua il reindirizzamento dopo l'autenticazione, consentendogli di mascherarsi come client benigno. Non risolve problemi come l'avvelenamento del DNS o le modifiche del file host.

Poiché non c'è modo di garantire che un client sia lo stesso richiedente dell'ultima volta che ha fatto una richiesta, a causa della natura stateless dei server HTTP, ciò significa che a lungo termine è necessario emettere un nonce ogni volta che il client desidera connettersi tramite un certo canale laterale sicuro e autorizzare la richiesta in questo modo. Per i clienti privati, ciò potrebbe anche essere impossibile, perché qualcuno potrebbe capire come farlo mediante il reverse engineering dell'applicazione che lo fa. Per i clienti pubblici, ciò sarebbe fattibile, ma aggiungerebbe ulteriore complessità e un piccolo ritardo per ogni richiesta.

Non esiste uno scenario che renda un vincolo univoco per il cliente più sicuro di quello che non ha una regola del genere, perché qualsiasi modo che potrebbe essere usato per bypassarne uno potrebbe anche essere usato per ignorare l'altro, aggiunge semplicemente uno strato di oscurità. Non sarebbe nemmeno banalmente rallentato un determinato aggressore nel caso di un cliente privato, e i client pubblici sono comunque protetti con altri mezzi (incluso un client secret , un tipo di password che solo quel client dovrebbe sapere).

    
risposta data 23.03.2016 - 18:42
fonte
1

Si noti che l'applicazione dell'unicità causa effettivamente una serie di problemi.

L'esempio più semplice è che stai limitando chi può usare https://localhost:8080/ su un singolo client. Qualsiasi altro cliente che tenta di utilizzare https://localhost:<port>/ dovrebbe giocare a un gioco di ipotesi con le porte per trovare un URI disponibile.

Inoltre, stai creando una forma di rivendicazione di un dominio facendo questo. A meno che tu non stia utilizzando qualcosa come ACME per far sì che i clienti posseggano effettivamente gli URI che stanno registrando, tu Stai permettendo a un cliente di rivendicare un URI che non possiede. Un client incurante (o malevolo) potrebbe registrarsi per URI come https://www.whitehouse.gov/oauth_redirect . Se reale % co_de arriva per registrare un URI, quel valore non è più disponibile e non c'è modo di togliere quell'URI dall'altra parte.

Tale collisione non è necessariamente un evento accidentale probabile tra diverse istituzioni, ma whitehouse.gov potrebbe registrare più client. Qui trovi altri problemi: se whitehouse.gov vuole passare da un client a un altro senza modificare un URI di reindirizzamento, non è in grado di farlo.

Vorrei anche esprimere una leggera preoccupazione generale sull'ipotesi che vedere un dato URI di reindirizzamento significhi definitivamente che il servizio sta interagendo con un cliente specifico. Nessuna assunzione del genere può o deve essere fatta.

    
risposta data 23.03.2016 - 19:47
fonte
0

Gli URI di reindirizzamento non devono essere, né dovrebbero essere, globalmente unici. Dovrebbero essere unici all'interno del profilo di un cliente. Gli URI di reindirizzamento non corrispondono necessariamente a un indirizzo fisico reale. Hanno semplicemente bisogno di essere capiti dal cliente e verificati dal server.

Gli ID cliente dovrebbero tuttavia essere globalmente unici.

Quando un client richiede un'autorizzazione, deve fornire il suo ID client e reindirizzare l'URI.

Se creo un'applicazione per browser client, il mio URI di reindirizzamento dello sviluppo sarà probabilmente qualcosa come link , non dovrebbe importare se qualcun altro ha usato lo stesso URI di reindirizzamento.

    
risposta data 24.03.2016 - 03:05
fonte

Leggi altre domande sui tag