Mi mancano alcune lacune con la mia attuale gestione delle sessioni?

Question

Mi mancano alcune lacune con la mia attuale gestione delle sessioni?

#1 da (2 voti)

1

Sto costruendo un sito con Spring, che richiede l'autenticazione per accedere ad alcune pagine.

Il sito è in realtà composto da un host client, che esegue il rendering delle viste e gestisce l'associazione dati e un host RIP API (creato anche con Spring), la responsabilità è la restituzione / manipolazione dei dati, la convalida / generazione del token utente etc ..

Ho deciso di implementare un'autenticazione personalizzata sul lato REST, dopo aver ricevuto un nome utente e una password validi, restituirà:

JWT firmato dall'API REST con AES-256, il carico utile conterrà l'id utente e la data di scadenza.
Il JWT è memorizzato su un cookie, che è solo HTTP, sicuro e valido solo dal dominio del sito client (è sufficiente per contrastare gli attacchi csrf?)

L'unica backdoor che potrei pensare è se l'attaccante ruba il cookie, per il quale potrei aggiungere al payload JWT un valore casuale univoco per l'utente (che è memorizzato nel database), e nel caso l'utente sia sospettando che la sua sessione sia stata rubata, potrebbe emettere una richiesta per reimpostare il valore univoco, rendendo inutilizzabile il token rubato.

Mi mancano le backdoor che potrebbero consentire a un utente malintenzionato di bypassare facilmente l'autenticazione? Dovrei usare Spring Security invece? Temo di non essere in grado di raggiungere il comportamento apolide che attualmente ho ...

Grazie!

jwt cookies xss csrf spring-framework

posta Nadav96 28.03.2017 - 21:17

fonte

1 risposta

Leggi altre domande sui tag jwt cookies xss csrf spring-framework

Perché le specifiche OAuth 2.0 raccomandano l'uso del tipo di supporto "application / x-www-form-urlencoded"? Si tratta di un segno di un attacco XSS di successo?

score 2 · Accepted Answer

Sarai vulnerabile a un attacco CSRF.

Dato che vuoi essere senza stato, l'opzione migliore è usare doppio cookie di invio variazione. Devi stare attento e non farlo in modo ingenuo, vedi questa domanda . In breve, dovrai legare il token CSRF a una sessione di sicurezza:

Genera un token CSRF sufficientemente grande
Includi il token CSRF all'interno del JWT come una delle rivendicazioni
Fornire CSRF al client come risultato di un'autenticazione corretta in un oggetto JSON, ad esempio. Fornirai cookie contenenti il tuo JWT nello stesso passaggio. Il cookie non può essere letto dal client (httpOnly) quindi la necessità di fornirlo in un oggetto JSON o in un altro formato.
Sul lato client, memorizza il token CSRF in sessionStorage o localStorage e invialo al server in ogni richiesta che cambia stato come intestazione.
Sul lato server convalidare il valore dall'intestazione e JWT

La tua soluzione per la revoca di JWT va bene. Assicurati di generare un nuovo ID e emettere un nuovo token quando l'utente cambia password.

Per ridurre al minimo il possibile impatto che un JWT rubato può avere sull'applicazione, mantieni la scadenza più breve possibile.

È possibile implementare una protezione JWT stateless utilizzando Spring Security e evitare di farlo in un controller REST e di eseguire la propria implementazione personalizzata. Vedi questo come buon punto di partenza. Anche se è per Spring Boot, può essere facilmente modificato in modo che funzioni con Spring semplice.