Sto comprendendo correttamente come interrompere un determinato attacco di fissazione della sessione OAuth2?

Question

Sto comprendendo correttamente come interrompere un determinato attacco di fissazione della sessione OAuth2?

#1 da (2 voti)
#2 da (1 voti)

3

Trovate qui descritto un attacco di fissazione della sessione OAuth2. L'attacco è possibile? E sto comprendendo correttamente come può essere fermato?

L'attacco

Mallory inizia ad accedere a client.example.com tramite un determinato provider OpenAuth2, ma subito dopo che il provider ha inviato la risposta di autorizzazione ( collegamento ) Mallory chiude il browser e quindi blocca il flusso di accesso OAuth2. Tuttavia, prima di chiudere il browser, ricorda il valore Location nello stato 302 Trovato risposta dal provider:

HTTP/1.1 302 Found
Location: https://client.example.com/oauth-callback?code=12345&state=xyzw

Ora Mallory configura un malvagio server Web per rispondere allo stato 302 Trovato con l'intestazione di posizione sopra. Invia una e-mail ad Alice e dice: "Ciao, guarda questa pagina interessante su Client.Example.Com" con un link al suo malvagio server web. Alice segue il link e viene reindirizzato a client.example.com con il codice OAuth2 di Mallory (cioè 12345 ). client.example.com continua il flusso di autenticazione: invia il codice OAuth2 al provider OAuth2 e ottiene un token di accesso.

Il risultato è che Alice ha effettuato l'accesso a un account controllato da Mallory. Alice però non se ne rende conto e compie un acquisto tramite Client.Example.Com. Client.Example.Com ricorda il suo numero di carta di credito, a cui Mallory può accedere in seguito accedendo all'account e controllando la cronologia dell'account.

Prevenzione dell'attacco

OAuth2 non consente di riutilizzare lo stesso codice di autorizzazione ( 12345 ) più di una volta (vedere il RFC collegato sopra ), ma poiché Mallory ha chiuso il browser nel mezzo del flusso di login, il codice di autenticazione non viene utilizzato più di una volta.

Nella sezione 10.12 della RFC è menzionato che gli attacchi CSRF possono essere fermati tramite il parametro di stato OAuth2 ( xyzw in questo esempio). Tuttavia, Mallory copia anche il parametro state , quindi è probabile che sia uno stato valido, se lo stato è ad es. solo un sostantivo generato a caso. E quando Alice segue il malvagio collegamento di Mallory, client.example.com non ha visto nessuno usare quel particolare stato prima, quindi client.exampel.com probabilmente lo accetta.

La RFC dice che lo stato dovrebbe essere ", ad esempio un hash del cookie di sessione utilizzato per autenticare l'user-agent" . È questa la chiave per prevenire questo tipo di attacco? Alice avrebbe un cookie di sessione a client.example.com e lo stato dovrebbe essere hashWithSha1(the-session-cookie-value) ? La state=xyzw di Mallory sarebbe quindi incompatibile con il cookie di sessione di Alice, quindi client.example.com capirebbe che qualcosa non andava bene con il reindirizzamento dal malvagio server di Mallory?

(Esattamente ciò che suggeriresti come state ? Sarebbe semplicemente hashWithSha1(the-session-cookie-value) sicuro?)

oauth session-fixation

posta KajMagnus 26.07.2014 - 17:41

fonte

2 risposte

Leggi altre domande sui tag oauth session-fixation

Google ha accesso al mio account MSN! Usando HTTPS, si può vedere il dominio di destinazione?

score 2 · Answer 1

Leggendo link , questo è quello che interpreto:

Il client (in questo caso, il server con un account che Mallory sta riparando) indirizza lo user-agent a una richiesta OAuth. state è stato determinato dal client e viene passato con la richiesta e verrà restituito quando lo user-agent viene inviato a redirect_uri con una decisione di autorizzazione. Qual è la supposizione che si suppone stia assumendo che ogni user-agent abbia una sessione legata ad esso e che lo stato può essere calcolato da quell'identificativo di sessione ( hashWithSha1(the-session-cookie-value) ), o è memorizzato in un modo che è codificato per quella sessione identificatore (ad esempio, un valore session[:oauth_request_state] su un server Ruby On Rails, che potrebbe essere impostato su un nonce). Mallory, con la sua sessione, genererà un valore state diverso da quello che si aspetterà dall'interazione di Alice con il client, e ciò causerà il fallimento dell'autorizzazione.

Si prega di inserire qui tutti i soliti avvertimenti su persone che credono su internet, e chiunque potrebbe correggermi rapidamente se sbaglio.

score 1 · Answer 2

SHA (auth-session-cookie) è utile solo se il valore sottostante di auth-session-cookie è di per sé sufficientemente ampio e casuale.

Anche auth-session-cookie dovrebbe essere di breve durata (ad esempio 2 minuti), quindi lo stato non è valido indefinitamente per ridurre il rischio di attacchi di riproduzione.