Replay l'esempio di attacco per convalidare il nonce?

Question

Replay l'esempio di attacco per convalidare il nonce?

#1 da (1 voti)

3

Sto tentando di convalidare un token JWT ricevuto da Windows Azure. Sto seguendo la documentazione qui: link

Quando richiedi un token, Azure ti fornisce un nonce e il token JWT restituito contiene il nonce che hai inviato e devi assicurarti che corrisponda. Un problema comune in questa situazione è che il server è stateless e potrebbero esserci più server, quindi non è facile memorizzare il nonce per il confronto con il valore nel token quando viene ricevuto il token.

Ecco cosa intendo fare: quando reindirizzo il browser al link memorizzerò il nonce in un cookie. Quando il token viene ricevuto da Azure e il browser invia il token al mio server, otterrò anche il nonce nel cookie e posso confrontarlo per assicurarmi che corrisponda.

Questa è una soluzione facile al problema di dove memorizzare il nonce. Ma la domanda è: questa strategia è coerente con il modo in cui dovrebbe essere usato nonce? Dal momento che il nonce viene trasferito al / dal client, ciò interrompe la protezione offerta da nonce? Questo abiliterà gli attacchi di replay e renderà inutile il nonce? Per rispondere a queste domande ho bisogno di sapere che tipo di attacchi sto cercando di prevenire.

Quindi la domanda è, quali sono alcuni esempi di scenari di attacco di replay che il nonce è progettato per prevenire? L'attaccante è da qualche parte su Internet, nel qual caso è possibile utilizzare SSL per impedirgli di vedere alcuna comunicazione? Oppure l'attaccante si trova sullo stesso computer dell'utente, cioè, dopo che l'utente ha lasciato il computer, l'utente malintenzionato utilizza il computer e il browser che l'utente ha trascurato di chiudere?

Come funziona esattamente un attacco di replay?

jwt man-in-the-middle nonce

posta User52016 17.05.2016 - 16:56

fonte

1 risposta

Leggi altre domande sui tag jwt man-in-the-middle nonce

Vulnerabilità note di GOST Esiste un modo per utilizzare la crittografia con chiave chiara per proteggere i flussi multimediali multimediali HTML5?

score 1 · Accepted Answer

Come per documentazione di OpenID Connect Core :

The nonce parameter value needs to include per-session state and be unguessable to attackers. One method to achieve this for Web Server Clients is to store a cryptographically random value as an HttpOnly session cookie and use a cryptographic hash of the value as the nonce parameter. In that case, the nonce in the returned ID Token is compared to the hash of the session cookie to detect ID Token replay by third parties. A related method applicable to JavaScript Clients is to store the cryptographically random value in HTML5 local storage and use a cryptographic hash of this value.

Quindi sì, è accettabile archiviarlo in un cookie, ma si consiglia di utilizzare un hash sicuro come SHA-2 quando questo valore viene inviato al server di autorizzazione dal browser dell'utente.

Questo protegge da un token rubato, perché l'autore dell'attacco che ha rubato il token non avrà questo cookie di sessione sul tuo sito, e non è in grado di indovinarlo o ricostruirlo perché il valore è hash quando inviato esternamente.

L'utente malintenzionato sarebbe su Internet, perché se l'utente è locale tutte le scommesse sono disattivate - sarebbero in grado di accedere al token inviato alla tua applicazione, e sarebbero in grado di accedere a questa sessione biscotto.

Quindi cosa protegge da?

Ricorda che se ti affidi a OpenID per autenticare i tuoi utenti, ti stai fidando di una terza parte. In un mondo ideale, la sicurezza del provider è assoluta e nessuno può intercettare il token. Tuttavia, se c'è una debolezza nella catena tra l'utente e il provider OpenID, ad esempio c'è una vulnerabilità non dichiarata di perdita di token che consente a un utente malintenzionato di osservare il token, il nonce assicurerà che non possano accedere alla tua applicazione ripetendo il reindirizzamento a il tuo sito.

Il valore di un nonce rispetto alla semplice convalida di una sessione sul tuo sito è che accoppiano il loro accesso originale al tuo sito quando hai reindirizzato al provider, con il ritorno al tuo sito.