Ecco lo scenario - un utente accede al tuo sito web, torna domani e ... deve eseguire nuovamente il login.L'idea del "ricordati di me" - e diciamocelo, tutti abbiamo visto questo prima - è che il loro stato autenticato viene mantenuto al di là del campo di applicazione immediata di utilizzo. Che cosa questo significa è che si può chiudere il browser, spegnere il PC poi tornare domani o la prossima settimana o il mese prossimo o comunque molto più tardi si determina è un lasso di tempo ragionevole e il sito lo sa ancora chi sono e li offre tutte le stesse caratteristiche che avevano quando hanno lasciato.
Sto parlando di questo ragazzo poco qui:
Sembra facile, vero? Può essere, ma come vedrete non è inoltre raro fare un pasticcio assoluto di esso e anche quando non lo fanno bene, c'è una fila di persone pronte a dirvi come si è, infatti, non abbastanza giusto . Cominciamo con il proprio roba sbagliata e lavorare da lì.
Anti-modelli
Questo sembra ovvio, no? Voglio dire l'attuazione di una funzione di "ricordati di me" è abbastanza fondamentale, non è il genere di cose facilmente ottenuto sbagliato, no? Pare di no.
Vorrei condividere due anti-pattern e vedremo i problemi con loro prima di parlare di come farlo nel modo giusto. Il primo esempio viene fornito per gentile concessione di Black & Decker, che sarebbe la stessa B & D di recente ho scritto in sicurezza è difficile, l'insicurezza è facile . Ecco l'idea quando si effettua il login:
Questo è tutto abbastanza standard, il bit interessante viene dopo l'accesso Diamo uno sguardo ai biscotti:
Questo è abbastanza impressionante serie di biscotti, ma è quelli evidenziati che sono veramente interessanti. Questi cookies non otterranno impostare se non si seleziona la casella "Ricordami" così la loro funzione è puramente password potrebbero tornare in seguito. Il mio indirizzo e-mail è abbastanza chiaramente in là, ma che non è la mia parola d'ordine, invece sembra essere una sorta di fortezza impenetrabile di crittografia ... appendere - che è la codifica Base64! La cosa di codifica Base64 è che è perfettamente completato da Base64 di codifica che significa che si può staccare, per un posto comebase64decode.org e fare questo:
Ora, non tutti usano Base64 come mezzo di "crittografia" (sì, alcune persone veramente fare questo ), e in effetti si tratta di un modo perfettamente legittimo di rappresentare i dati in un formato ASCII, la vera storia qui però è che questa è la mia password seduto lì nel mio browser in testo normale. Vi chiederete - perché questo è un problema? E 'nel proprio browser, giusto? In che modo un utente malintenzionato ottiene?
Ho intenzione di parlare di due modi molto semplici e il primo si riferisce al collegamento in precedenza circa l'insicurezza essere facile. Black & Decker erano esposti i registri ELMAH e in quei registri di stato ogni eccezione non gestita server interno, da qualche parte a nord di 50.000 di loro al momento ho riferito a loro. Quando ELMAH registra un'eccezione si registra anche tutte le intestazioni di richiesta che significa che i cookie sono registrati. Che si combinano con l'enorme numero di eccezioni non gestite essere generate dal sistema e ora avete un tesoro di credenziali utente. Sì, dovrebbero avere assicurato il loro log ELMAH correttamente per cominciare, ma si tratta di un buon esempio di come si può essere facilmente annullata da una semplice configurazione errata.
Ecco un altro:
Questo è Aussie Agricoltori diretto ed è una abbastanza tipico log vedendo in forma. Facciamo il login, dirgli di "ricordati di me", poi dare un'occhiata ai biscotti:
Oddio, di nuovo stesso problema, ma senza alcuna codifica Base64. In realtà questo è particolarmente grave perché si può fare cose come questa:
XSS tuo biscotto JSON? Certo! L'altra peculiarità è che cambiando la password non cambia il cookie in modo da tornare al sito in seguito e si tenta di accedere in voi con quello vecchio. Oops.
Aussie Gli agricoltori diretti non hanno esposto i registri ELMAH (essendo sorta di PHP aiuta in questo!) Ma hanno altri rischi, quali XSS (per inciso, questo è stato divulgato in modo responsabile e il rischio sommariamente respinto - più volte). L'altra cosa su entrambi i siti di cui sopra è che quei biscotti che tengono le password non vengono contrassegnati come HttpOnly, si può vedere questo nella seconda colonna da destra nelle liste dei cookie. Che cosa questo significa è che lo script client può accedere a quei biscotti che significa che se si può ottenere un pezzo di XSS sul sito - così come è possibile sul sito Agricoltori australiano - è possibile rubare i cookie contenenti le password se è possibile ottenere un cliente di caricare il carico utile XSS (e ci sono molti modi per farlo). L'attributo HttpOnly manca è sciatto per conto di entrambi i siti, ma il nocciolo della questione è la memorizzazione delle password nei cookies che poi li rende vulnerabili tramite altre sviste.
C'è una ragione di più di fondamentale importanza perché entrambe queste pratiche sono negligenti, che stanno proteggendo le credenziali dei clienti utilizzati su altri siti. Ogni volta che un cliente che utilizza la funzione "ricordati di me" su uno dei siti di cui sopra fa una richiesta, c'è una buona possibilità che stanno inviando il nome utente e la password per la posta elettronica, il loro eBay o la propria banca attraverso il filo, a volte in pianura testo, a volte accessibile tramite script client, sempre seduto lì non protetto nel browser. password riutilizzo è dilagante e mentre quei dannati gli utenti dovrebbero prendere qualche sanguinosa responsabilità (sto parafrasando qui!), noi - come sviluppatori - dobbiamoriconoscere che siamo protezione molto più di nostro sito quando gestiamo credenziali.
Così che dovrebbe stabilire se vi sia un vero e proprio fraintendimento di come la funzione "ricordati di me" dovrebbe essere costruito, andiamo ora passare sulle buone pratiche.
Una implementazione di riferimento del campione
Uno dei mantra si sente spesso nel mondo della sicurezza è "non rotolare il proprio - utilizzare ciò che è già stato dimostrato di essere robusto". Questo è molto spesso applicato alla crittografia e schemi di autenticazione, ma in questo caso si può estendere questo per la caratteristica "ricordati di me", al fine di iniziare con una buona implementazione di riferimento prima di approfondire i dettagli.
In un nuovo sito Web ASP.NET MVC 4 provisioning con Visual Studio 2012 si ottiene questo diritto fuori dalla scatola:
Altri quadri hanno altri modi standard di implementazione di questa funzione, ma questo è un compito facile per me fare riferimento. Quando abbiamo Login con i campi come sopra (cioè non chiedendole di ricordarsi di me), risultati di autenticazione riusciti nel seguente biscotto da restituire:
path = /; HttpOnly
Questo è semplicemente un cookie di autenticazione e nel mondo senza stato che è HTTP è l'unico piccolo pezzo di dati che lega tutte le richieste altrimenti del tutto indipendenti da una persona insieme.Ogni volta che questo unico-a-me cookie viene inviato, il sito web sa che sono io e che ho già autenticato. Lo possiamo vedere po 'più chiaramente quando lo guardiamo nella raccolta Cookies di Chrome:
Per inciso, il secondo cookie è un token antifalsificazione per prevenire attacchi CSRF e non ha nulla a che vedere con il nostro stato autenticato. Oltre a questo, non ci sono altri biscotti.
Vediamo ora il login e chiedere al sito di ricordare me, ecco la risposta di biscotto:
expires = Tue, 02-Jul-2013 00:27:05 GMT; path = /; HttpOnly
Aha - si vede che?! Si diventa più chiaro quando lo vedi suddiviso in Chrome:
Ora abbiamo una scadenza del cookie, che è di 48 ore da oggi al contrario di non avere scadenza del cookie che significa che verrà scartata quando il browser viene chiuso. Diamo uno sguardo più da vicino a questo.
Guardando auth cookie di scadenza
Questo è in realtà un ridicolmente facile costruire la sicurezza ed è solo alla luce degli esempi precedenti che mi piacerebbe anche pensare che vale la pena scrivere, ma qui siamo. In questa implementazione, il "Remember Me" si riduce semplicemente a quando il cookie di autenticazione scade, perché quello che stai facendo veramente qui è il controllo per quanto tempo si desidera che qualcuno a rimanere connesso per, è così semplice.
Nel precedente esempio, il default ASP.NET di utilizzare un cookie di sessione o in altre parole, un cookie che non ha una data di scadenza esplicita e sarà quindi forzatamente scade quando il browser viene chiuso. Questo è un approccio, un altro è impostare esplicitamente un breve periodo di scadenza in modo che, anche se il browser viene lasciata aperta l'utente verrà automaticamente disconnesso dopo un periodo di tempo. Naturalmente è anche possibile controllare questo comportamento sul server e si può anche tenere estendere la durata di un cookie di autenticazione se il sistema viene utilizzato attivamente dal server aumentando la data di scadenza sulla risposta.
Ricordando qualcuno può essere semplice come mantenere vivo il cookie auth. Quanto tempo dovrebbe essere mantenuto in vita per? L'esempio sopra il default è due giorni che è probabilmente un po 'corto per molti usi legittimi della funzione (anche se è facilmente configurabile in ASP.NET), prova a Facebook e anche se avrai i cookie che durano per un anno. Durata inferiore significa meno rischi ma più inconveniente, durata maggiore rende più facile per l'utente, ma aumenta la finestra di potenziale attacco. Diamo un'occhiata a questo rischio in modo più dettagliato.
Sfruttando stato di autenticazione di lunga durata
Mentre non si dispone dell'autenticazione, la sessione non può essere dirottato. Lo so, roba perspicace!Ma sul serio, prendere un caso come Aussie Agricoltori diretto di cui sopra; che cookie scadrà tra sei mesi e combinato con il fatto che non è contrassegnato come HTTP solo e che non hanno difetti XSS nel sito c'è ora una mezza finestra anno in cui solo a seguito di una link potrebbe causare me a consegnare inavvertitamente le mie credenziali per un attaccante. Se questo periodo è stato, diciamo, un mese sì, avrei ancora alcuni gravi difetti nel loro design, ma poi la finestra di opportunità per un attaccante è stato appena tagliato.
D'altra parte, Black & Decker ha un breve periodo di scadenza di una settimana rispetto così nel loro caso con i registri ELMAH a vista, sì, ci fu una serie di brutti errori da parte loro, ma a meno che qualcuno si era connesso con il "ricordati di me" casella evidenziata nella scorsa settimana e ha causato un'eccezione non gestita, le credenziali non sarebbero stati messi in mostra pubblica. Ok, se siete sul sito per cominciare c'è una buona possibilità che stai già effettuato l'accesso (almeno rispetto al caso di agricoltori in cui non si dovrebbe andare consapevolmente nessuna parte nei pressi del sito di perdere la tua password), ma si può vedere come tale profilo di rischio cambia con il periodo di scadenza dei cookie.
Naturalmente alla base di tutto questo è che il cookie auth deve essere attentamente tutelato; attributi HttpOnly e sicuro sono un must assoluto. Tutte le minacce classiche dirottamento restano pertinenti, ma poi di nuovo, ma si sezionare i questa funzione si sta andando a finire con una dipendenza biscotto quindi si sta andando ad avere bisogno di guardare molto, molto attentamente quei biscotti.
In definitiva si tratta di un compromesso che ha bisogno di prendere in considerazione fattori come il valore di un attaccante di dati dell'utente sul sito, la barriera che non viene autenticato pone a un utente di ritorno e il profilo di sicurezza del resto del sito. Per esempio, Facebook ha alcuni dati molto utili di carattere sociale e gli utenti si aspettano un basso attrito (anche senza processo-attrito) al ritorno, più che hanno fatto enormi investimenti nel loro profilo di sicurezza. Aussie Farmer'S, d'altra parte, contiene i dati di identificazione personale degli utenti più informazioni finanziarie al tempo stesso un servizio che le persone si aspettano per l'autenticazione (servizi di pagamento) hanno ancora una scarsa conoscenza di importanti concetti di sicurezza. Sono profili di rischio molto differenti e che dovrebbero essere molto diverse strategie di scadenza del cookie auth.
Rafforzare l'approccio
Ci saranno persone che guardano l'approccio cookie di autenticazione e roteare gli occhi in preda alla disperazione. La cosa di sicurezza è che c'è sempre un modo migliore a seconda del tempo / denaro / complessità che sei disposto ad aggiungere e c'è anche sempre qualcuno pronto a dirti che hai sbagliato!Utilizzando il cookie auth scadenza come punto di partenza, diamo un'occhiata ad alcuni possibili modi di rafforzare l'approccio.
Un argomento contro la lunga scadenza del cookie auth è che stanno efficacemente mantenendo l'utente autenticato e al rischio di attacchi come CSRF o clickjacking. Ovviamente l'applicazione deve esporre altri rischi in ordine per un utente malintenzionato di sfruttare la lunga durata dei cookie, ma l'intera difesa in profondità l'argomento viene in su di nuovo. Un'alternativa è quella di avere un biscotto dedicato calettata contro l'utente che dopo convalida l'autenticità di esso con il server, possono poi avviare una nuova sessione autenticata il loro ritorno. La sessione originale può quindi scadere rapidamente, il trucco è quello di ripristinare una nuova quando l'utente torna con il "ricordati di me" cookie dedicata e comprende alcuni convalida supplementare nel processo.
Un modo per fornire un'ulteriore convalida è includendo l'indirizzo IP dell'utente / user agent / altro segno distintivo del "ricordati di me" cookie. La logica è che questo offre una certa difesa contro dirottamento del cookie. Il problema, naturalmente, è che ci sono casi in cui tali cambiamenti uso legittimo. Nel mondo mobile, in particolare, non è raro per tornare a un sito con un IP diverso. Anche nel mondo delle connessioni fisiche non si può necessariamente fare affidamento su l'ISP fornisce un indirizzo IP statico. Per quanto riguarda gli interpreti, con browser come Chrome e Firefox l'aggiornamento a quello che sembra come ogni altro giorno, a meno che non sei un po 'selettivi su ciò che gli attributi della stringa user agent che stai memorizzare e confrontare che sta per essere un approccio rischioso. Le stesse difese intorno utilizzando attributi utente e uniche per aggiungere sicurezza sono spesso discussi nel contesto di sessione e cookie auth e mentre sono sicuro che ci sono casi di utilizzo validi per questo (torna al settore bancario di nuovo), non posso dire di ' ve effettivamente visto nel luogo in uno qualsiasi dei siti che ho provato prima. C'è probabilmente una buona ragione per questo ...
A mitigazione più pragmatico è quello di separare ancora il cookie auth da un "ricordati di me" cookie dedicato e utilizzare quest'ultimo per ri-autenticare l'utente , ma imporre alcune restrizioni . La realtà è che il processo di persistenza dello stato automaticamente autenticato di qualcuno - attraverso qualsiasi mezzo - introduce compromessi al modello di sicurezza. A mitigazione potrebbe essere quella di richiedere un utente automaticamente ri-autenticato per fornire espressamente le proprie credenziali di nuovo prima di visualizzare alcune categorie di dati o l'esecuzione di determinate attività. Questo non è inaudito anche al di fuori del campo di applicazione del "ricordati di me", si potrebbe vedere che durante l'esecuzione di attività di alto valore, come il bonifico bancario. In questo caso, stiamo dicendo che l'utente autenticato è più a rischio perché c'è più probabilità che non sono chi dicono di essere (cioè qualcun altro si è seduto al PC ed efficace highjacked una sessione).
L'altra tempra possiamo applicare a questo approccio è di assicurare che il cookie utilizzato per ricordare all'utente viene resettato dopo che è stata utilizzata. Questo significa anche invalidarla sul lato server in modo ci deve essere sia l'unicità e la persistenza del valore del cookie, ad esempio un nonce persisteva sia nel database e il cookie. Questo ha il vantaggio di garantire che, se il cookie
viene ottenuto da un utente malintenzionato ha ha solo un unico ambito l'uso - e questo è se l'utente non può utilizzare legittimamente prima di loro. C'è un po 'di buona articolo
qui che parla di alcune mitigazioni a questo modello e di nuovo, ci sono casi d'uso in cui questo può essere utile, ma che si sta per investire ulteriore sforzo costruirlo e ci sono casi in cui sarà utenti legittimi disagi (cioè cercando di ricordare te sullo stesso sito su più PC).
L'ultima cosa degna di nota è che gli stessi principi di gestione degli account che devono essere considerati per le sessioni autenticate attivi sono rilevanti nel "ricordati di me" contesto. Ad esempio, sono più sessioni autenticate contemporaneamente consentite da quello utente? Se l'utente cambia la password ti è scollegare le altre sessioni? Può un amministratore di terminare la sessione autenticata? Ci sono tutti i tipi di problemi che vengono in su che sono in realtà parte della discussione su come sessioni autenticate sono verificati e gestiti, la discussione qui è solo su come ripristinare quello.
Quando non si deve permettere "ricordati di me"? (E alcune alternative intermedia)
A volte semplicemente non ha senso per consentire a un utente autenticato di rimanere autenticato per lunghi periodi di tempo. Bancario, ad esempio, è il caso d'uso stereotipato per quando si desidera forzare una nuova autenticazione al più presto possibile in quanto i rischi sono troppo significativi per lasciare le sessioni del browser non utilizzati autenticate in giro il posto.
Ma vi è in realtà un po 'di terra di mezzo che può essere presa qui:
Questo non è del tutto quello che sembra - quando si torna dopo una sessione scaduta, dove lei ha chiesto al sito di "Remember Me", otterrete questo:
Ho non offuscato il nome utente, il nome utente come appare sopra le stelle sono memorizzati in un cookie che dura per tre mesi insieme ad alcuni altri dati che identificano inevitabilmente l'utente.Francamente, non vedo un sacco di valore in questo, ricordando il nome utente di solito non è il problema!
Ma, inoltre, non deve essere tutto o niente, non c'è via di mezzo. Ad esempio, il punto che ho fatto in precedenza su ri-autenticare prima di processi chiave vengono eseguite se la sessione fosse stata ripresa da una funzione di "ricordati di me". E 'un po' il meglio dei due mondi.
In conclusione ...
Questa è una di quelle caratteristiche che sembra una buona idea, al momento (e talvolta lo è) e di solito è molto facile da ottenere, almeno sufficientemente giusto per ogni uso. Francamente, è ancora un po 'sconcertante come sbagliato i due esempi precedenti si sono particolarmente se si considera che sarebbe stato sufficiente per estendere semplicemente la durata del cookie che già hanno!
L'altro punto di togliere da questo post di là solo la meccanica della funzione "ricordati di me": così la sicurezza è un multi-tiered, bestia come interdipendenti. Potreste essere in grado di cavarsela con le credenziali in cookie di per sé, ma che si combinano con la situazione ELMAH o mancanti solo HTTP attributi e difetti XSS e improvvisamente un sciocche seppur pratica relativamente innocuo diventa un rischio serio. Di che si trattava "difesa in profondità" di nuovo?!
