2009-04-23 5 views
6

Abbiamo notato che è possibile ricreare una copia di un cookie ASP.NET FormsAuthentication su un'altra macchina, consentendo la seconda macchina per l'autenticazione senza dover effettuare il login.Posso rendere più sicuro il mio cookie ASP.NET FormsAuthentication associandolo all'ID di sessione?

Una soluzione possibile a questo è stato per memorizzare il ID sessione entro FormsAuthenticationTicket.UserData e per verificare che i due valori corrispondano all'interno di Application_AuthenticateRequest().

Stiamo usando:

FormsAuthenticationTicket.IsPersistent = false; 

È questo approccio di associare cookie di FormsAuthentication con l'ID di sessione una buona idea?

+0

È qualcosa che hai effettivamente provato? Hai effettivamente avuto un altro log di macchina utilizzando un cookie da un'altra macchina? Pensavo ci fosse un po 'di crittografia per sessione. –

+0

Un collega l'ha provato. Non so se sia stata configurata alcuna crittografia. – tjrobinson

risposta

18

Penso che tu stia pensando troppo al problema. La possibilità di copiare un cookie è solo un problema intrinseco dei cookie: chiunque può intercettare qualsiasi cookie e impersonare qualsiasi dato ci sia, impostandolo su un'altra macchina.

La "sicurezza" del cookie di autenticazione viene dal fatto che nessuno può (presumibilmente) le imbarcazioni il cookie a mano di falsificare un utente autenticato. Tuttavia, una volta creato il cookie, ovviamente può essere utilizzato per l'autenticazione. Ciò significa che per far si che il tuo "problema" si verifichi, devi comunque avere un accesso utente valido per primo. Se quell'utente sta abusando del sistema copiando il suo cookie su altre macchine per consentire a tutti l'accesso, è esattamente la stessa cosa che l'utente dice semplicemente a tutti il ​​suo nome utente e password, tranne che in modo molto più ottuso. Pertanto, il problema non è la copia del cookie: è l'utente stesso.

Un altro vettore di attacco sarebbe se la rete è compromessa e qualcuno può intercettare il traffico per mettere insieme il cookie tramite uno sniffer o altro - ma ancora una volta, questo è inerente ai cookie stessi. Questo è chiamato Session Hijacking e l'unico modo per proteggersi è usare SSL per il tuo sito.

Se si è veramente preoccupati di ciò, impostarei il tempo di autenticazione e di sessione per essere lo stesso, quindi nel file global.asax, chiamare semplicemente FormsAuthentication.Signout() ogni volta che scade la sessione dell'utente. Ciò invalida l'autenticazione ogni volta che l'utente ha terminato la sessione, costringendoli ad accedere nuovamente in seguito. Naturalmente, questo potrebbe essere un fastidio estremo per gli utenti ...

vorrei anche consigliare vivamente This MSDN article. Probabilmente risponde alle tue domande molto meglio di me.

+0

Grazie per la tua risposta - in realtà è sulla falsariga di quello che stavo pensando, ma volevo una seconda opinione prima di provare a correggere qualcosa che non era effettivamente un problema. I tuoi moduli suggeritiAuthentication.Signout() non sembra applicabile nel mio caso in quanto il cookie di autenticazione scade comunque alla fine della sessione - costringendo gli utenti ad accedere a ogni nuova sessione. O mi sono perso qualcosa? – tjrobinson

+1

E il caso in cui una macchina degli utenti viene infettata da un virus che ruba i loro cookie? SSL non li proteggerà allora. Suppongo che sia solo una variante di Session Hijacking in quel caso. – tjrobinson

+1

Re: primo commento. Non penso che ti sia sfuggito qualcosa. Ci ho pensato un po 'la scorsa notte e ho pensato che potevi provare a inserire alcuni dati utente nel ticket di autenticazione, come il loro indirizzo IP o qualcosa del genere, e se tali informazioni sono cambiate, logele automaticamente. Ciò rende più difficile l'impersonificazione di un'altra macchina ... ma anche l'indirizzo IP può essere falsificato. Tuttavia sarebbe un po 'più sicuro. Re: secondo commento - sì, solo un'altra variazione. – womp