La specifica di connessione openid aggiunge un parametro nonce all'endpoint autorizza, che deve essere ripetuto come rivendicazione nel token_id. Afferma che lo scopo di questo parametro è impedire attacchi di riproduzione e ha alcuni suggerimenti sull'implementazione riguardo all'uso dei cookie solo http.
Capisco che cos'è l'attacco a ripetizione in generale, ma mi piacerebbe avere una migliore comprensione dei dettagli di ciò che un attacco di replay potrebbe proteggere da questo potrebbe sembrare, quindi posso avere un'idea migliore se ho implementato in modo efficace, o fatto un piccolo errore.
Suppongo che l'attacco di riproduzione sia contro l'endpoint di autorizzazione, poiché alcuni terzi ottengono un token corrispondente a un altro utente. È così o è qualcos'altro? Quale livello di informazioni ci aspettiamo che l'attaccante debba ripetere? Hanno il traffico tra l'agente utente e il server di autorizzazione ma non l'applicazione client, motivo per cui sarebbero in grado di riprodurre il traffico verso l'endpoint di autorizzazione ma non sarebbero in grado di riprodurre un cookie precedente all'applicazione client? Oppure hanno la cronologia del browser di entrambi ma non il traffico di rete in modo che non abbiano valori di cookie vecchi? È importante se l'agente utente ha ancora la sessione dell'utente precedente con il server di autorizzazione quando si verifica la riproduzione? Se l'utente precedente ha una sessione valida con il server di autorizzazione e l'utente malintenzionato ha accesso a questo, non può accedere a un token senza eseguire una riproduzione? Se non hanno una sessione valida con il server di autorizzazione, non verrà comunque richiesto all'utente, anche se riproducono una vecchia richiesta? Se all'utente verrà richiesto di autenticare, presumibilmente con credenziali che non hanno, qual è il rischio di una riproduzione?
Ho fatto molte ricerche e ci sono alcune domande simili ( Replay esempio di attacco per la convalida di nonce? e Scopo di convalida nonce nel flusso implicito di OpenID Connect ) nessuno dei due risponde alla domanda su come funziona questo specifico attacco di replay. Il primo cita solo l'implementazione consigliata della specifica, poi parla di token perduti, che mi sembra diverso da un attacco di replay (se l'attaccante ha un gettone trapelato, non hanno già vinto comunque?). Il secondo spiega l'idea generale di un attacco di replay, ma non parla di come funzioni effettivamente questo particolare attacco.
Come sfondo sto facendo un'app di connessione openID usando il flusso del codice di autorizzazione (quindi la ripetizione del reindirizzamento da AS alla mia app non dovrebbe fare nulla perché puoi scambiare lo stesso codice di autorizzazione per un token una volta AFAICT, quindi è necessario riprodurre anche l'endpoint di autorizzazione per un attacco di riproduzione che sia significativo.) La mia app utilizza i token che torno come token al portatore per autenticare le richieste al mio server web, e sono l'insieme dello stato della sessione, lì non è altro stato di sessione significativo o identità gestita localmente per legare i token a. Il mio provider di openid connect richiede un nonce perché è una best practice di sicurezza. È effettivamente utile nel mio caso d'uso particolare? La ragione per cui sono così confuso perché in realtà non fornisce una protezione significativa per la particolare cosa che sto facendo? Se questo ha delle implicazioni sulla sicurezza per me, il 110% vuole essere sicuro di fare la cosa giusta, ma sto attraversando un periodo molto difficile per capire di cosa mi protegge.
Alcune domande dettagliate sull'implementazione sono confuse a causa della mancata comprensione del vettore delle minacce esattamente:
- Convalido il nonce corrisponde a ciò che è stato inviato all'endpoint di autorizzazione dopo averlo ritirato dall'endpoint del token e quindi presume che sia valido per la sessione? O dovrebbe convalidare il cookie id_token contro il cookie nonce essere parte di ogni richiesta proprio come controllare la firma?
- Si suppone che il nonce sia legato alla sessione ma il termine nonce implica che dovrebbe essere usato una sola volta. Se devo inviare un utente con una sessione valida di nuovo attraverso l'endpoint di autorizzazione per qualche ragione (ottenere un nuovo id_token con una scadenza ulteriore in futuro? Richiedere un set più ampio di ambiti?) Creo un nuovo nonce? È un nonce per sessione o per chiamata ad autorizzare?