2010-05-17 13 views
11

(credo) Capisco perché gli ID di sessione devono essere ruotati quando l'utente esegue l'accesso: questo è un passaggio importante per impedire session fixation.La rotazione dell'ID Session migliora la sicurezza?

Tuttavia, vi è alcun vantaggio nel ruotare in modo casuale/periodicamente ID di sessione?

Questo a mio parere fornisce solo un falso senso di sicurezza. Supponendo che gli ID di sessione non siano vulnerabili a ipotesi di forza bruta e trasmetti l'ID di sessione solo in un cookie (non come parte degli URL), allora un utente malintenzionato dovrà accedere al tuo cookie (molto probabilmente facendo lo snooping sul tuo traffico) per ottenere il tuo ID della sessione. Pertanto, se l'autore dell'attacco riceve un ID di sessione, probabilmente sarà in grado di annusare anche l'ID di sessione ruotato, pertanto la rotazione casuale non ha migliorato la sicurezza.

risposta

5

Se si utilizzano identificativi di sessione memorizzati nei cookie, la risoluzione della sessione non è un problema. Ho sfogliato il foglio che hai incollato e vedo cose come usare DNS e XSS per possedere l'utente, che ovviamente sono problemi molto più grandi (per non dire separati) rispetto alla fissazione della sessione. Se si dispone dell'identificatore di sessione (con un livello accettabile di entropia) memorizzato in un cookie, non esiste alcun motivo ragionevole per ruotarlo. L'unico motivo per farlo ruotare sarebbe perché è ipotizzabile o vulnerabile in qualche altro modo, nel qual caso l'utente viene comunque posseduto.

+5

Penso che ruotare l'ID sessione (SID) al momento del login è necessario anche se è memorizzato in un cookie. Considera questo: l'utente malintenzionato esplora il sito Web su un computer condiviso e viene assegnato un SID (ma non effettua l'accesso). Quindi l'attaccante si allontana. Se il prossimo utente accede e il SID non viene ruotato, l'utente malintenzionato conosce il SID e può usarlo per mascherarsi come utente che ha effettuato l'accesso. * Questo scenario è un po 'inverosimile * (si spera che il computer condiviso sia ancora ha account separati), * ma possibile *. –

+2

Quello che hai detto è una seria vulnerabilità (pensa ai chioschi). Stavo assumendo che il sito assegni un nuovo ID di sessione al login. Ovviamente, dovresti assegnare un nuovo ID di sessione al login. E no, questo attacco non è affatto inverosimile. –

+0

concordato. (nota: il mio commento è stato principalmente in risposta alla prima frase della tua risposta) –

0

Lo sviluppo Web non è il mio genere, ma è possibile perché l'accesso dell'utente può essere un utente malintenzionato? Ad esempio, se accedo e ottengo l'ID di sessione 4, posso indovinare che l'ID di sessione 5 apparterrà a qualche altro utente, modificherà il mio cookie locale e quindi agirò come tale utente?

+2

Questa sarebbe una possibilità se gli ID di sessione fossero generati in sequenza. Tuttavia, i buoni generatori di ID di sessione generano ID casuali proprio per questo motivo, quindi gli aggressori non possono indovinarli. –

0

Suona come un'idea stupida nel complesso.

Sarebbe totalmente rovinare gli utenti se colpiscono il pulsante Indietro come i collegamenti nella pagina precedente ora includevano un id di sessione non aggiornato. Puoi anche eliminare qualsiasi AJAX perché ogni volta che viene creato un RPC sul server, tutti i link/moduli nella pagina richiedono l'aggiornamento poiché ora hanno valori non validi. Se tutto questo è meno sicuro perché significa che la tua applicazione diventa più complicata e ha più possibilità di avere un errore in essa.

Se il ragionamento richiede di "ruotare" id probabilmente significa che i tuoi id sono generati male, e che dovrebbe essere la cosa che viene corretta. Se lo snooping è un problema usa SSL.

+2

Non penso che questo crei un problema con il pulsante Indietro. E penso che sia possibile aggirare le richieste AJAX/quasi simultanee ruotando l'ID di sessione ogni N richieste e conservando quelle vecchie per un breve periodo. Certo, solo perché non rovina quelle cose non significa che sia una buona idea. Sono d'accordo con te nel fatto che non penso che la rotazione periodica di ID di sessione valga la pena sia. Concordo anche sul fatto che se lo snooping è un problema, SSL è un must. –

+0

Non ruotando/cambiando hai effettivamente smesso di ruotare. Cosa succede se la tua app è una singola pagina e non cambia mai. Il tuo ajax su quella pagina finirà per diventare più vecchio del TLD id di sessione. –

+1

È una cattiva idea mantenere comunque ID sessione negli URL. Pertanto, se il sessionID è ordinato in un cookie, i pulsanti back/forward in una SPA non falliscono. – SteAp

0

Secondo questo post del blog SSL Labs (dal 2013), i chiphers RC4 (ancora visibili in natura, 2017) sono deboli e potrebbero consentire a un black hat di rivelare i dati dei cookie di sessione dal traffico HTTPS intercettato (ad esempio tramite Wi-Fi).

L'ID/dati del cookie di sessione ruotanti ogni x unità di tempo (minuti?) E dopo ogni y numero di richieste, è suggerito nel post del blog.

Problemi correlati