È sicuro memorizzare la password in sessionStorage HTML5?

In linea di principio, i valori memorizzati in sessionStorage sono limitati allo stesso schema + nome host + porta univoca, e se il browser ha un'uscita pulita questi valori dovrebbero essere cancellati alla fine della sessione. Tuttavia, secondo questo post può sopravvivere a riavvio del browser se l'utente sceglie di "ripristinare la sessione" dopo un arresto anomalo (il che significa che i suoi valori esistono anche nella memoria persistente fino a quando non vengono cancellati, quindi tienilo a mente). Se ben implementato, direi che è abbastanza sicuro, soprattutto rispetto alla tua alternativa all'uso di un cookie (che ha molte insidie che non prenderei nemmeno in considerazione). La specifica W3C afferma anche che l'archiviazione Web potrebbe effettivamente essere utilizzata per archiviare dati sensibili (anche se non è chiaro se questa pratica sia approvata o meno)

Per quanto riguarda i rischi, è semplicemente una questione di compromessi: stai rendendo il tuo sito un po 'più conveniente per i tuoi utenti, mentre aumenti un po' la finestra di opportunità per la password da catturare (sia per mezzo di un XSS vulnerabilità, dal valore che persiste nell'archiviazione persistente per un tempo più lungo di quanto previsto dall'utente o dall'aver lasciato il computer incustodito prima di completare la registrazione). Idealmente, le password non dovrebbero mai lasciare la RAM, ma di solito non è pratico, quindi è necessario un compromesso. Vorrei solo consigliare di cancellare la password da sessionStorage non appena la registrazione ha esito positivo e di tenere d'occhio le vulnerabilità sulle implementazioni sessionStorage che potrebbero eventualmente venire alla luce.

Avrai difficoltà a decidere quale dei due valori memorizzati utilizzare come password prevista dall'utente (quella nella memoria locale o quella nel campo di input), se nessuno di questi è vuoto ma per alcuni motivo diverso.

Questo può potenzialmente fornire un vettore di attacco di ingegneria sociale, in cui l'attaccante prepara una trappola aprendo il modulo di registrazione, riempiendo la memoria locale / di sessione usando il proprio codice e in seguito rimuovendo eventuali tracce (notifiche di errore di input) con un editor DOM, o inserendo la password desiderata direttamente nella memoria locale / di sessione (entrambi sono supportati su alcuni browser ed estremamente facili da fare), poi chiedendo alla vittima di registrarsi con il tuo sito web e, beh, usarlo. Poiché il tuo codice può essere facilmente ispezionato / testato per vedere come gestisci tali casi, l'autore dell'attacco potrebbe farlo in modo leggermente diverso da quello che ho descritto (anche le iniezioni di script direttamente nell'archiviazione locale / di sessione non sono fuori questione, se procederai successivamente quel valore localmente sul modulo POST), ma con lo stesso effetto.

La vittima non sospetterà nulla finché non si disconnette e prova a ricollegarsi. A seconda della persistenza della sessione utente, questo processo di disconnessione e di accesso potrebbe non essere necessario e la vittima non ho notato che la sua password non era quella che inseriva nel campo della password, ma invece la password di scelta dell'utente malintenzionato è stata utilizzata per creare il suo nuovo account.

Agli aghi, l'attaccante ha appena ottenuto l'accesso all'account appena creato della vittima e tutti i dati che la vittima ha inserito, anche se la vittima era cauta e si è assicurata che non vi fosse alcun coinvolgimento delle spalle.

Quindi il punto d'appoggio qui è che potenzialmente dovrai gestire due diverse posizioni del sistema con gli stessi dati di registrazione, che potrebbero per qualsiasi motivo differire e decidere quale utilizzare in un modo sicuro sia per il tuo sistema, così come l'utente finale che si sta registrando. Questo potrebbe rivelarsi piuttosto difficile da fare correttamente, quindi consiglierei di non farlo.

Piuttosto, assicurati che il tuo modulo di registrazione sia servito tramite HTTPS, quindi semplicemente riempi il campo della password, poiché è stato inserito l'ultima volta nella richiesta POST dell'utente e se soddisfa i tuoi vincoli, anche se alcuni degli altri campi di input sono compilato in modo errato e il modulo deve essere ripubblicato.

Suggerisco un altro approccio: invece di inviare il modulo al server, usa un XMLHttpRequest per creare l'account. Se la convalida lato server fallisce, il modulo e tutto il suo contenuto sono ancora disponibili. Se ha avuto successo, reindirizza alla pagina di destinazione.

Ciò richiede che JavaScript sia abilitato, ma è comunque possibile tornare all'invio normale del modulo. L'accesso a SessionStorage richiede comunque anche JavaScript.

Userei alcune comunicazioni intertab per distribuire la password invece di memorizzare la password in qualsiasi archivio persistente (cookie, localstorage, ecc. ci sono innumerevoli soluzioni, controlla evercookie). In questo modo la password vivrà nel browser fino a quando non chiuderai l'ultima scheda per il dominio attuale.

Puoi fare comunicazioni intertab in sicurezza con BroadcastChannel o SharedWorker o postMessage probabilmente ci sono altri metodi che non conosco, stanno sempre reinventando la ruota. I primi due inviano i messaggi a ogni scheda, l'ultimo invia solo a schede aperte dalla stessa scheda padre, quindi è un po 'restrittivo, ma supportato da più browser.

Se si memorizzano le password nella memoria js, è necessario impedire XSS con intestazioni speciali . E ofc. devi controllare il contenuto visualizzato per i tag HTML e devi sempre codificare JSON i dati che vuoi iniettare direttamente in javascript come variabile.

Il post di TildalWave è interessante, penso che questi metodi non siano vulnerabili, perché la sincronizzazione è quasi istantanea e puoi anche sincronizzare login, logout, ecc.

Se si decide comunque di utilizzare lo spazio locale, è preferibile utilizzare un userid, un timeout e un sale firmati anziché la stessa password. È possibile inviare le credenziali al server, che può verificarle e inviare i dati con la firma indietro. Possono essere memorizzati in un cookie o qualsiasi altra memoria persistente desiderata. Questi token vengono talvolta utilizzati dalle API REST se esiste un client browser, poiché questa soluzione è stateless e dà comunque la sensazione di avere una sessione classica. A volte firmano ogni richiesta, non solo l'ID utente per migliorare la sicurezza.