http_only per i cookie con token JWT

5

Sto cercando di capire come usare i JWT che vengono trasmessi nei cookies per una SPA. Deve essere nei cookie perché vogliamo che le richieste non-jax inviino anche il jwt, e dovrebbe "funzionare" per tutti sottodomini. Ho il cookie con il token generato e aggiornato bene sul lato server. Quello che sto cercando di capire è come il lato client dovrebbe ottenere le informazioni (is_logged_in e username dell'utente loggato in sostanza) e mantenere tali informazioni in sincronia con il ciclo di vita dei cookie lato server, poiché desidero scadenza dopo dire 1 ora di nessuna richiesta, e dovrebbe apparire sul browser quando ciò accade. Il mio problema è che le informazioni utente che voglio sono in un cookie che è http_only per prevenire XSS. Ho pensato ad un paio di opzioni e vorrei opinioni su ciò che è un ragionevole compromesso di sicurezza:

1) invia il token jwt identico in due cookie, uno utilizzato per l'autenticazione lato server effettiva e & auth, che è contrassegnato http_only e sicuro, e un secondo identico ma non http_only in modo che il client possa decodificarlo per ottenere informazioni sull'utente e tempo di scadenza.

2) invia le informazioni dell'utente in un secondo cookie che non è http_only ed è una vista semplice, ma ha solo il nome utente dell'utente connesso.

3) prova ad avere il client in grado di tenere traccia delle informazioni di accesso per conto proprio, questo sembra problematico finora e facile da inventare ma non ha cookie insicuri in giro.

Penso che potrei mancare qualche aspetto di sicurezza delle opzioni di cui sopra, quindi chiedo qui. grazie!

    
posta Iain Duncan 06.08.2015 - 22:23
fonte

2 risposte

2

Questo suona bene e sembra una buona soluzione per proteggere il cookie di sessione dagli attacchi XSS duplicando il valore del nome utente in un cookie non solo http.

Tutti i controlli di autorizzazione dovrebbero essere comunque effettuati dal lato server. Quindi, se il tuo cliente vuole fare qualcosa sul lato server, invia la richiesta e quindi il server fa controllare l'autorizzazione da solo, non prendendo in considerazione il solo cookie non http - semplicemente usa il cookie di sessione protetto solo da http.

Se il solo non http viene utilizzato solo a scopo di interfaccia utente, non può danneggiare la sessione perché il server vetterà tutte le richieste usando il cookie di sessione.

    
risposta data 10.08.2015 - 12:53
fonte
1

Ho dovuto leggere la tua domanda un paio di volte per capire cosa stavi descrivendo nell'opzione 1 - se il tuo cookie di sessione contiene un valore di testo chiaro prevedibile (nell'esempio il nome utente autenticato e il fatto superfluo che sono autenticati) allora la tua sicurezza è fondamentalmente infranta. La sessione deve essere casuale o crittografata con valori / valori di inizializzazione che variano nel tempo.

Nella tua seconda opzione, supponendo che il cookie di sessione sia sicuro, qual è la conseguenza della compromissione del secondo cookie non sicuro? Non molto. Anche se vale la pena notare che la maggior parte dei mezzi con cui il cookie potrebbe essere compromesso equivale a un uomo nel tipo di attacco del browser (incluso xss) a quel punto l'attaccante sarà in grado di sfruttare il cookie di sessione per creare richieste provenienti dal browser delle vittime .

    
risposta data 07.08.2015 - 03:56
fonte

Leggi altre domande sui tag