Effetti del nuovo token sessione casuale per ogni richiesta HTTP

Question

Effetti del nuovo token sessione casuale per ogni richiesta HTTP

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

1

In caso di autenticazione con esito positivo, un'applicazione Web emette un cookie di sessione che è una stringa di lunghezza costante di caratteri esadecimali apparentemente casuali.

2E5F0FE4B7FCAB78CD967B46AB32915CCBFDC85316FAFB9174BDC4A3745339D8AD9C1D70A8EDD3D4F06107F3B1A67E85AEB1CB04F563818BC5D029D9E956652ED0F8F93E7A7EFD1E2E59DF1D378424964541E2C9B8A41436D0092A4114FBC4FA702A94C5090C34D97A3310F88CD3E9BDC8553230343BB1E4641F848102DF9B96AA81D6407273F774CFBD3E3FD68CAF84654B21E177A36DE7FB09EFC5A50A5253E1B5F5D6C5082A01D756CC68680FE1FBCA64CD72F1D6B1865C6FFC4B6BB8DE2C2B510731103F18DDA2289515F604632A26BD68B0E03647B854243EAFD7264B0765F45279BD6735E26D58DF720D5B9061EF316730

Questo cookie di sessione viene inviato per ogni richiesta HTTP e la risposta contiene un valore diverso ogni volta, il che significa che questo valore viene utilizzato sempre una sola volta. Qualsiasi modifica a questo valore invaliderà la sessione.

Di solito vedo i valori di un token di sessione che vengono utilizzati molte volte per un'intera sessione di autenticazione. In termini di disposizione "monouso" sopra descritta, vedo:

Vantaggi

riduzione del rischio di una sessione compromessa in quanto il valore è meno probabile che sia valido quando un utente malintenzionato tenta di utilizzare

Svantaggi

maggiori risorse di calcolo necessarie per generare token non casuali ogni volta
possibile drenaggio dell'entropia del sistema operativo host dall'uso costante di PRNG

Ci sono altre considerazioni che mi mancano qui? Grazie

cpu cookies entropy session-management

posta user1330734 13.11.2018 - 05:28

fonte

2 risposte

Leggi altre domande sui tag cpu cookies entropy session-management

Un computer sulla rete pubblica che stavo usando è penetrato in un codejam. Sono a rischio? Esiste la possibilità di crittografare con diverse chiavi pubbliche e decrittografare con qualcuno di loro?

score 1 · Answer 1

Questa soluzione aiuterebbe a proteggere da un attacco di replay un listener passivo, ma se si stesse facendo la sessione su HTTPS (come si dovrebbe sempre), sarebbe comunque difficile riprodurlo in ogni caso.

Una cosa che consiglierei di pensare è cosa succede se il cliente non riceve una delle sessioni per qualsiasi motivo. Accettate qualcuno degli ultimi 5? Devono riautenticarsi?

score 1 · Answer 2

Questa soluzione è in effetti simile a quella di un meccanismo di timeout di rinnovo e presenta preoccupazioni simili:

Tempi di revoca

Se l'ID della sessione precedente viene immediatamente revocato, è possibile che il client non abbia ancora ricevuto il nuovo ID di sessione prima di tentare di accedere ad altre risorse con la vecchia sessione. Ad esempio, il tuo utente potrebbe diventare impaziente e fare clic su un altro collegamento mentre la tua richiesta è ancora in corso o semplicemente la tua app sta effettuando molte chiamate asincrone.

Un modo per aggirare questo è consentire un intervallo di sicurezza in cui è ancora possibile utilizzare il vecchio token per l'accesso. Tuttavia, ciò significa anche che dovrai mantenere sincronizzate le due sessioni per evitare la perdita di dati alla scadenza del vecchio token.

Condizioni di gara

C'è ancora la possibilità che un utente malintenzionato possa rinnovare l'ID sessione con un ID sessione valido prima di un utente. Se l'attaccante vince la gara, l'utente troverà improvvisamente interrotta la sessione.

Se questo è più o meno probabile con questa soluzione dipenderà se hai anche impostato un timeout di inattività (revoca se non ci sono attività dopo un certo periodo) e un timeout assoluto (revoca dopo un tempo prefissato) per la tua sessione. Se non hai questi set, il tuo utente potrebbe ad esempio accedere a una pagina e lasciarlo lì.

necessità

C'è anche la questione se sia necessario o meno il timeout del rinnovo per evitare il dirottamento di sessione. Il timeout di inattività e il timeout assoluto con una scadenza ragionevole possono già raggiungere risultati simili senza carico aggiuntivo del server. Inoltre, per prevenire il furto di sessione semplice è sufficiente utilizzare semplicemente SSL. Tutto sommato, a meno che non ci siano modifiche al livello di diritti / privilegi di accesso dell'utente, sembra un po 'ridondante cambiare l'ID di sessione.

reference: Gestione sessione OWASP