L’autenticazione e la gestione delle sessioni includono tutti gli aspetti relativi alla gestione dell’autenticazione dell’utente e alla gestione delle sessioni attive. L’autenticazione è un aspetto critico di questo processo, ma anche meccanismi di autenticazione solidi possono essere minati da funzioni di gestione delle credenziali difettose, tra cui il cambio della password, ho dimenticato la mia password, ricorda la mia password, aggiornamento dell’account e altre funzioni correlate. Poiché gli attacchi “passanti” sono probabili per molte applicazioni web, tutte le funzioni di gestione dell’account dovrebbero richiedere la reautenticazione anche se l’utente ha un id sessione valido.
L’autenticazione dell’utente sul web prevede tipicamente l’uso di un userid e una password. Esistono metodi di autenticazione più forti disponibili commercialmente, come i token crittografici basati su software e hardware o la biometria, ma tali meccanismi sono proibitivi per la maggior parte delle applicazioni web. Una vasta gamma di difetti nella gestione dell’account e della sessione può portare al compromesso degli account utente o di amministrazione del sistema. I team di sviluppo spesso sottovalutano la complessità della progettazione di un sistema di autenticazione e gestione delle sessioni che protegge adeguatamente le credenziali in tutti gli aspetti del sito. Le applicazioni web devono stabilire sessioni per tenere traccia del flusso di richieste da parte di ciascun utente. HTTP non fornisce questa capacità, quindi le applicazioni web devono crearla da sole. Spesso, l’ambiente dell’applicazione web fornisce una capacità di sessione, ma molti sviluppatori preferiscono creare i propri token di sessione. In entrambi i casi, se i token di sessione non sono adeguatamente protetti, un attaccante può dirottare una sessione attiva e assumere l’identità di un utente. Creare uno schema per creare token di sessione forti e proteggerli durante tutto il loro ciclo di vita si è rivelato elusivo per molti sviluppatori. A meno che tutte le credenziali di autenticazione e gli identificatori di sessione non siano protetti con SSL in ogni momento e protetti contro la divulgazione da altri difetti, come lo scripting cross-site, un attaccante può dirottare la sessione di un utente e assumere la sua identità.
Soluzione
L’uso attento e corretto dei meccanismi di autenticazione e gestione delle sessioni personalizzati o pronti all’uso dovrebbe ridurre significativamente la probabilità di un problema in quest’area. Definire e documentare la politica del tuo sito in merito alla gestione sicura delle credenziali degli utenti è un buon primo passo. Assicurarsi che la tua implementazione applichi in modo coerente questa politica è fondamentale per avere un meccanismo di autenticazione e gestione delle sessioni sicuro e robusto. Alcune aree critiche includono:
- Forza della password – le password dovrebbero avere restrizioni che richiedono una dimensione e una complessità minime per la password. La complessità richiede tipicamente l’uso di combinazioni minime di caratteri alfabetici, numerici e/o non alfanumerici nella password di un utente (ad esempio, almeno uno di ciascuno). Gli utenti dovrebbero essere obbligati a cambiare la loro password periodicamente. Gli utenti dovrebbero essere impediti di riutilizzare le password precedenti.
- Uso della password – Gli utenti dovrebbero essere limitati a un numero definito di tentativi di accesso per unità di tempo e i tentativi di accesso falliti ripetuti dovrebbero essere registrati. Le password fornite durante i tentativi di accesso falliti non dovrebbero essere registrate, in quanto ciò potrebbe esporre la password di un utente a chiunque possa accedere a questo registro. Il sistema non dovrebbe indicare se è stato l’username o la password ad essere sbagliato se un tentativo di accesso fallisce. Gli utenti dovrebbero essere informati della data/ora del loro ultimo accesso riuscito e del numero di tentativi di accesso falliti al loro account da quel momento.
- Controlli sul cambio della password – Dovrebbe essere utilizzato un unico meccanismo di cambio della password ovunque agli utenti sia consentito cambiare una password, indipendentemente dalla situazione. Gli utenti dovrebbero sempre essere obbligati a fornire sia la vecchia che la nuova password quando cambiano la loro password (come tutte le informazioni dell’account). Se le password dimenticate vengono inviate per e-mail agli utenti, il sistema dovrebbe richiedere all’utente di ri-autenticarsi ogni volta che l’utente sta cambiando il suo indirizzo e-mail, altrimenti un attaccante che ha temporaneamente accesso alla loro sessione (ad esempio, avvicinandosi al loro computer mentre sono loggati) può semplicemente cambiare il loro indirizzo e-mail e richiedere che una password ‘dimenticata’ gli venga inviata.
- Conservazione delle password – Tutte le password devono essere conservate in forma criptata o hashata per proteggerle dall’esposizione, indipendentemente da dove vengono conservate. La forma hashata è preferibile in quanto non è reversibile. La crittografia dovrebbe essere utilizzata quando è necessaria la password in chiaro, come quando si utilizza la password per accedere a un altro sistema. Le password non dovrebbero mai essere codificate in modo fisso in alcun codice sorgente. Le chiavi di decrittografia devono essere fortemente protette per garantire che non possano essere prese e utilizzate per decrittare il file delle password.
- Protezione delle credenziali in transito – L’unica tecnica efficace è crittografare l’intera transazione di login utilizzando qualcosa come SSL. Le semplici trasformazioni della password, come l’hashing sul client prima della trasmissione, offrono poca protezione poiché la versione hashata può semplicemente essere intercettata e ritrasmessa anche se la password in chiaro effettiva potrebbe non essere nota.
- Protezione dell’ID di sessione – Idealmente, l’intera sessione di un utente dovrebbe essere protetta tramite SSL. Se ciò viene fatto, allora l’ID di sessione (ad esempio, il cookie di sessione) non può essere preso dalla rete, che è il rischio maggiore di esposizione per un ID di sessione. Se SSL non è praticabile per motivi di prestazioni o altri, allora gli ID di sessione stessi devono essere protetti in altri modi. Prima di tutto, non dovrebbero mai essere inclusi nell’URL poiché possono essere memorizzati nella cache dal browser, inviati nell’intestazione del referrer o inoltrati accidentalmente a un ‘amico’. Gli ID di sessione dovrebbero essere numeri lunghi, complicati, casuali che non possono essere facilmente indovinati. Gli ID di sessione possono anche essere cambiati frequentemente durante una sessione per ridurre quanto tempo un ID di sessione è valido. Gli ID di sessione devono essere cambiati quando si passa a SSL, si autentica o si effettuano altre transizioni importanti. Non dovrebbero mai essere accettati ID di sessione scelti da un utente.
- Liste di account – I sistemi dovrebbero essere progettati per evitare che gli utenti possano accedere a un elenco dei nomi degli account sul sito. Se devono essere presentate liste di utenti, si consiglia di utilizzare una sorta di pseudonimo (nome utente) che mappa l’account effettivo elencato al suo posto. In questo modo, il pseudonimo non può essere utilizzato durante un tentativo di accesso o qualche altro hack che va a colpire l’account di un utente.
- Caching del browser – I dati di autenticazione e di sessione non dovrebbero mai essere inviati come parte di un GET, dovrebbe sempre essere utilizzato POST al suo posto. Le pagine di autenticazione dovrebbero essere contrassegnate con tutte le varietà del tag no cache per impedire a qualcuno di utilizzare il pulsante indietro nel browser di un utente per tornare alla pagina di login e reinviare le credenziali precedentemente digitate. Molti browser supportano ora il flag AUTOCOMPLETE=OFF per prevenire la memorizzazione delle credenziali nelle cache di autocompletamento.
- Relazioni di fiducia – L’architettura del tuo sito dovrebbe evitare la fiducia implicita tra i componenti ogni volta che è possibile. Ogni componente dovrebbe autenticarsi con qualsiasi altro componente con cui interagisce a meno che non ci sia una forte ragione per non farlo (come le prestazioni o la mancanza di un meccanismo utilizzabile). Se sono necessarie relazioni di fiducia, dovrebbero essere in atto forti meccanismi procedurali e architettonici per garantire che tale fiducia non possa essere abusata man mano che l’architettura del sito evolve nel tempo.
Per una scansione completa delle vulnerabilità e per una protezione adeguata, valuta la possibilità di collaborare con una soluzione affidabile come INFRA (www.infrascan.net). INFRA offre servizi avanzati di scansione della sicurezza con check.website e servizi di monitoraggio per identificare e affrontare tutte le vulnerabilità, garantendo così la solidità delle tue applicazioni web.