È sicuro archiviare un jwt in localStorage con reazioni?

Attualmente sto sviluppando un'applicazione a pagina singola utilizzando un file reattivo. Ho letto che molte delle ragioni per non utilizzare localStorage sono dovute a vulnerabilità XSS. Poiché React sfugge a tutti gli input dell'utente, ora sarebbe sicuro usare localStorage?

Nella maggior parte delle moderne applicazioni a pagina singola, dobbiamo infatti archiviare il token da qualche parte sul lato client (caso d'uso più comune - per mantenere l'utente connesso dopo un aggiornamento della pagina).

Sono disponibili 2 opzioni in totale: Archiviazione Web (archiviazione di sessione, archiviazione locale) e un cookie lato client. Entrambe le opzioni sono ampiamente utilizzate, ma ciò non significa che siano molto sicure.

Tom Abbott sintetizza bene la sessione JWT Sicurezza del magazzino e del deposito locale :

L'archiviazione Web (localStorage / sessionStorage) è accessibile tramite JavaScript sullo stesso dominio. Ciò significa che qualsiasi JavaScript in esecuzione sul tuo sito avrà accesso all'archiviazione Web e per questo motivo può essere vulnerabile agli attacchi cross-site scripting (XSS) . XSS, in breve, è un tipo di vulnerabilità in cui un utente malintenzionato può iniettare JavaScript che verrà eseguito sulla tua pagina. Gli attacchi XSS di base tentano di iniettare JavaScript attraverso input del modulo, in cui l'utente malintenzionato inserisce <script>alert('You are Hacked');</script>un modulo per vedere se è gestito dal browser e può essere visualizzato da altri utenti.

Per impedire XSS, la risposta comune è quella di fuggire e codificare tutti i dati non attendibili. React (principalmente) lo fa per te! Ecco una grande discussione su quanta protezione di vulnerabilità XSS è responsabile di React .

Ma questo non copre tutte le possibili vulnerabilità! Un'altra potenziale minaccia è l'uso di JavaScript ospitato su CDN o infrastrutture esterne .

Ecco di nuovo Tom:

Le app Web moderne includono librerie JavaScript di terze parti per test A / B, analisi di canalizzazione / mercato e pubblicità. Utilizziamo gestori di pacchetti come Bower per importare il codice di altre persone nelle nostre app.

Che cosa succede se solo uno degli script che usi è compromesso? JavaScript dannoso può essere incorporato nella pagina e l'archiviazione Web è compromessa. Questi tipi di attacchi XSS possono ottenere l'archiviazione Web di tutti che visita il tuo sito, a loro insaputa. Questo è probabilmente il motivo per cui un gruppo di organizzazioni consiglia di non archiviare nulla di valore o di fidarsi di qualsiasi informazione nella memoria web. Ciò include identificatori di sessione e token.

Pertanto, la mia conclusione è che, in quanto meccanismo di archiviazione, l'archiviazione Web non applica alcun standard sicuro durante il trasferimento . Chiunque legga l'archiviazione Web e la usi deve fare la dovuta diligenza per assicurarsi di inviare sempre il JWT su HTTPS e mai HTTP.

So che questa è una vecchia domanda, ma secondo quanto affermato da @ mikejones1477, le librerie e i framework front-end moderni sfuggono al testo offrendoti protezione contro XSS. Il motivo per cui i cookie non sono un metodo sicuro utilizzando le credenziali è che i cookie non impediscono CSRF quando lo fa localStorage (ricorda anche che i cookie sono accessibili anche tramite javascript, quindi XSS non è il grosso problema qui), questa risposta riprende perché .

Il motivo per cui un token di autenticazione viene archiviato nella memoria locale e l'aggiunta manuale a ciascuna richiesta protegge da CSRF è la parola chiave: manuale. Poiché il browser non invia automaticamente quel token di autenticazione, se visito evil.com e riesce a inviare un POST http://example.com/delete-my-account , non sarà in grado di inviare il mio token di authn, quindi la richiesta viene ignorata.

Ovviamente httpOnly è il Santo Graal, ma non è possibile accedere da Reajs o da qualsiasi framework js al di fuori di te ha ancora vulnerabilità CSRF. La mia raccomandazione sarebbe localstorage o se si desidera utilizzare i cookie assicurarsi di implementare una soluzione al problema CSRF come fa Django .

Per quanto riguarda i CDN, assicurati di non utilizzare alcuni CDN strani, ad esempio i CDN come Google o Bootstrap forniti, sono gestiti dalla community e non contengono codice dannoso, se non sei sicuro, sei libero di rivedere.

Fondamentalmente va bene conservare il tuo JWT nel tuo archivio locale.

E penso che sia un buon modo. Se stiamo parlando di XSS, XSS utilizzando CDN, è anche un rischio potenziale di ottenere anche l'accesso / pass del tuo cliente. La memorizzazione dei dati nella memoria locale eviterà almeno gli attacchi CSRF.

Devi essere consapevole di entrambi e scegliere ciò che desideri. Entrambi gli attacchi non sono tutto ciò di cui devi essere consapevole, ricorda: LA TUA INTERA APP È SOLO SICURA COME L'ULTIMO PUNTO SICURO DELLA TUA APP.

Ancora una volta la memorizzazione è OK, sii vulnerabile a XSS, CSRF, ... non lo è

Non è sicuro se si utilizzano CDN:

JavaScript dannoso può essere incorporato nella pagina e l'archiviazione Web è compromessa. Questi tipi di attacchi XSS possono ottenere l'archiviazione Web di tutti che visita il tuo sito, a loro insaputa. Questo è probabilmente il motivo per cui un gruppo di organizzazioni consiglia di non archiviare nulla di valore o di fidarsi di qualsiasi informazione nella memoria web. Ciò include identificatori di sessione e token.

via stormpath

Qualsiasi script richiesto dall'esterno potrebbe essere potenzialmente compromesso e potrebbe prelevare qualsiasi JWTS dalla memoria del client e inviare i dati personali al server dell'attaccante.

Localstorage è progettato per essere accessibile tramite JavaScript, quindi non fornisce alcuna protezione XSS. Come menzionato in altre risposte, esistono molti modi possibili per eseguire un attacco XSS, da cui localstorage non è protetto per impostazione predefinita.

Tuttavia, i cookie hanno flag di sicurezza che proteggono dagli attacchi XSS e CSRF. HttpOnly flag impedisce a javascript lato client di accedere al cookie, Secure flag consente solo al browser di trasferire il cookie tramite ssl e il flag SameSite garantisce che il cookie sia inviato solo all'origine. Anche se ho appena controllato e SameSite è attualmente supportato solo in Opera e Chrome, quindi per proteggere da CSRF è meglio usare altre strategie. Ad esempio, l'invio di un token crittografato in un altro cookie con alcuni dati di utenti pubblici.

Quindi i cookie sono una scelta più sicura per la memorizzazione dei dati di autenticazione.

Un modo per esaminare questo è considerare il livello di rischio o danno.

Stai creando un'app senza utenti, POC / MVP? Sei una startup che deve arrivare sul mercato e testare rapidamente la tua app? Se sì, probabilmente implementerei solo la soluzione più semplice e mi concentrerei sulla ricerca del prodotto adatto al mercato. Usa localStorage in quanto spesso è più facile da implementare.

Stai costruendo una v2 di un'app con molti utenti attivi ogni giorno o un'app da cui persone / aziende dipendono fortemente. Essere hackerati significherebbe poco o nessun spazio per il recupero? In tal caso, darei una lunga occhiata alle tue dipendenze e prenderei in considerazione la memorizzazione di informazioni sui token in un cookie solo http.

Utilizzando sia localStorage che cookie / sessioni di archiviazione hanno i loro pro e contro.

Come indicato dalla prima risposta: se l'applicazione presenta una vulnerabilità XSS, nessuno dei due proteggerà l'utente. Poiché la maggior parte delle applicazioni moderne ha una dozzina o più dipendenze diverse, diventa sempre più difficile garantire che una delle dipendenze dell'applicazione non sia vulnerabile XSS.

Se l'applicazione presenta una vulnerabilità XSS e un hacker è stato in grado di sfruttarla, l'hacker sarà in grado di eseguire azioni per conto dell'utente. L'hacker può eseguire richieste GET / POST recuperando il token da localStorage o può eseguire richieste POST se il token è memorizzato in un cookie solo http.

L'unico lato negativo della memorizzazione del token nella memoria locale è che l'hacker sarà in grado di leggere il token.

Non è accettabile né localStorage né httpOnly cookie? Per quanto riguarda una libreria di terze parti compromessa, l'unica soluzione che conosco che ridurrà / impedirà il furto di informazioni riservate sarebbe l' integrità delle risorse secondarie .

L'integrità delle risorse secondarie (SRI) è una funzione di sicurezza che consente ai browser di verificare che le risorse recuperate (ad esempio da una CDN) vengano fornite senza manipolazione imprevista. Funziona consentendo di fornire un hash crittografico che una risorsa recuperata deve corrispondere.

Finché la libreria di terze parti compromessa è attiva sul tuo sito Web, un keylogger può iniziare a raccogliere informazioni come nome utente, password e qualsiasi altra cosa tu inserisca nel sito.

Un cookie httpOnly impedirà l'accesso da un altro computer ma non farà nulla per impedire all'hacker di manipolare il computer dell'utente.

È sicuro conservare il token in localStorage fintanto che lo si crittografa. Di seguito è riportato uno snippet di codice compresso che mostra uno dei molti modi in cui è possibile farlo.

    import SimpleCrypto from 'simple-crypto-js';

    const saveToken = (token = '') => {
          const encryptInit = new SimpleCrypto('PRIVATE_KEY_STORED_IN_ENV_FILE');
          const encryptedToken = encryptInit.encrypt(token);

          localStorage.setItem('token', encryptedToken);
     }

Quindi, prima di utilizzare il token, decodificarlo utilizzando PRIVATE_KEY_STORED_IN_ENV_FILE