Lo storage locale può essere considerato sicuro?

Sono tenuto a sviluppare un’applicazione web che funzionerà offline per lunghi periodi. Affinché ciò sia fattibile, non posso evitare di salvare dati sensibili (dati personali ma non il tipo di dati da archiviare solo con hash) nella memoria locale.

Accetto che questa procedura non sia raccomandata, ma data poca scelta sto facendo quanto segue per proteggere i dati:

  • encoding di tutto ciò che sta andando nell’archiviazione locale usando la libreria crittografica javascript di stanford e AES-256
  • la password utente è la chiave di crittografia e non è memorizzata sul dispositivo
  • serve tutto il contenuto (se online) da un singolo server attendibile su ssl
  • convalida di tutti i dati in entrata e in uscita dalla memoria locale sul server usando il progetto antispam del owasp
  • nella sezione di rete dell’appcache, non usando *, e invece elenca solo gli URI richiesti per la connessione con il server trusted
  • in generale cercando di applicare le linee guida suggerite nel foglio cheat di OWASP XSS

Apprezzo che il diavolo sia spesso nei dettagli e sappia che c’è molto scetticismo riguardo all’archiviazione locale e alla sicurezza basata su javascript in generale. Qualcuno può commentare se ci sono:

  • difetti fondamentali nell’approccio sopra?
  • eventuali soluzioni per tali difetti?
  • un modo migliore per proteggere la memoria locale quando un’applicazione html 5 deve funzionare offline per lunghi periodi?

Grazie per qualsiasi aiuto.

WebCrypto

I problemi con la crittografia nel javascript lato client (browser) sono descritti di seguito. Tutti tranne uno di questi problemi non si applicano all’API WebCrypto , che ora è ragionevolmente ben supportata .

Per un’app offline, è ancora necessario progettare e implementare un keystore sicuro.

A parte: se stai usando Node.js, usa l’API crypto integrata.

Crittografia Native-Javascript (pre-WebCrypto)

Presumo che la preoccupazione principale sia qualcuno con accesso fisico al computer che legge il localStorage per il tuo sito, e tu vuoi che la crittografia aiuti a prevenire localStorage .

Se qualcuno ha accesso fisico sei anche aperto ad altri attacchi e peggio della lettura. Questi includono (ma non sono limitati a): keylogger, modifica dello script offline, iniezione di script locale, avvelenamento della cache del browser e reindirizzamenti DNS. Questi attacchi funzionano solo se l’utente utilizza la macchina dopo che è stata compromise. Tuttavia, l’accesso fisico in uno scenario del genere comporta problemi maggiori.

Quindi, tieni presente che lo scenario limitato in cui la crittografia locale è valida sarebbe se la macchina venisse rubata.

Esistono librerie che implementano la funzionalità desiderata, ad esempio la libreria di crittografia Javascript di Stanford . Esistono tuttavia debolezze intrinseche (come indicato nel link dalla risposta di @ ircmaxell):

  1. Mancanza di generazione di entropia / numero casuale;
  2. Mancanza di un keystore sicuro, ovvero la chiave privata deve essere protetta da password se archiviata localmente o archiviata sul server (che impedisce l’accesso offline);
  3. Mancanza di cancellazione sicura;
  4. Mancanza di caratteristiche temporali.

Ognuna di queste debolezze corrisponde a una categoria di compromesso crittografico. In altre parole, mentre si può avere “cripto” per nome, sarà ben al di sotto del rigore che si aspira alla pratica.

Detto questo, la valutazione attuariale non è così banale come “Javascript crypto è debole, non usarlo”. Questa non è un’approvazione, è solo un avvertimento e richiede di comprendere completamente l’esposizione delle suddette debolezze, la frequenza e il costo dei vettori che affronti e la tua capacità di mitigazione o assicurazione in caso di fallimento: Javascript crypto, in Nonostante le sue debolezze, può ridurre la tua esposizione ma solo contro ladri con capacità tecniche limitate. Tuttavia, dovresti presumere che la crypto di Javascript non ha alcun valore nei confronti di un aggressore determinato e capace che sta bersagliando tali informazioni. Alcuni considererebbero fuorviante chiamare i dati “crittografati” quando si sa che molte debolezze sono intrinseche all’implementazione. In altre parole, è ansible ridurre in modo marginale l’esposizione tecnica ma aumentare l’esposizione finanziaria dalla divulgazione. Ogni situazione è diversa, ovviamente – e l’analisi della riduzione dell’esposizione tecnica all’esposizione finanziaria non è banale. Ecco un’analogia illustrativa: alcune banche richiedono password deboli , nonostante il rischio intrinseco, poiché la loro esposizione a perdite da password deboli è inferiore ai costi dell’utente finale di supportare password complesse.

🔥 Se hai letto l’ultimo paragrafo e hai pensato “Un tizio su Internet di nome Brian dice che posso usare la crittografia Javascript”, non utilizzare la crittografia Javascript.

Per il caso d’uso descritto nella domanda sembrerebbe avere più senso per gli utenti crittografare la partizione locale o la home directory e utilizzare una password complessa. Questo tipo di sicurezza è generalmente ben testato, ampiamente affidabile e comunemente disponibile.

Bene, la premessa di base qui è: no, non è ancora sicuro.

Fondamentalmente, non puoi eseguire crypto in JavaScript: JavaScript Crypto Considerato Nocivo .

Il problema è che non è ansible ottenere in modo affidabile il codice crittografico nel browser e, anche se fosse ansible, JS non è progettato per consentirne l’esecuzione in sicurezza. Quindi, fino a quando i browser non dispongono di un contenitore crittografico (che fornisce Encrypted Media Extensions, ma vengono radunati per i loro scopi DRM), non sarà ansible farlo in modo sicuro.

Per quanto riguarda un “modo migliore”, non ce n’è uno in questo momento. L’unica alternativa è quella di memorizzare i dati in testo semplice e sperare per il meglio. O non memorizzare affatto le informazioni. In entrambi i casi.

In alternativa, o se hai bisogno di quel tipo di sicurezza e hai bisogno di spazio di archiviazione locale, crea un’applicazione personalizzata …

Come esplorazione di questo argomento, ho una presentazione dal titolo “Securing TodoMVC Using the Web Cryptography API” ( video , codice ).

Utilizza l’ API di crittografia Web per archiviare l’elenco di cose crittografato in localStorage tramite la protezione della password dell’applicazione e utilizzando una chiave derivata da password per la crittografia. Se si dimentica o si perde la password, non c’è ripristino. ( Disclaimer: era un POC e non era destinato all’uso in produzione ) .

Come le altre risposte dichiarano, questo è ancora suscettibile di XSS o malware installato sul computer client. Tuttavia, qualsiasi dato sensibile verrebbe anche memorizzato quando i dati sono memorizzati sul server e l’applicazione è in uso. Suggerisco che il supporto offline potrebbe essere il caso d’uso convincente.

Alla fine, la crittografia localStorage probabilmente protegge solo i dati dagli autori di attacchi che hanno accesso in sola lettura al sistema o ai suoi backup. Aggiunge una piccola quantità di difesa in profondità per OWASP Top 10 item A6-Sensitive Exposure dei dati e ti consente di rispondere “Qualcuno di questi dati è memorizzato in testo chiaro a lungo termine?” correttamente.

Questo è un articolo davvero interessante qui. Sto considerando l’implementazione della crittografia JS per offrire sicurezza quando si utilizza l’archiviazione locale. È assolutamente chiaro che questo offrirà protezione solo se il dispositivo viene rubato (e implementato correttamente). Non offrirà protezione contro i keylogger, ecc. Tuttavia questo non è un problema di JS in quanto la minaccia di keylogger è un problema di tutte le applicazioni, indipendentemente dalla loro piattaforma di esecuzione (browser, nativo). Per quanto riguarda l’articolo “JavaScript Crypto Considerato Nocivo” a cui si fa riferimento nella prima risposta, ho una critica; afferma “È ansible utilizzare SSL / TLS per risolvere questo problema, ma è costoso e complicato”. Penso che questa sia un’affermazione molto ambiziosa (e possibilmente piuttosto di parte). Sì, SSL ha un costo, ma se si considera il costo di sviluppo di applicazioni native per più SO, piuttosto che basate sul Web a causa di questo problema, il costo di SSL diventa insignificante.

La mia conclusione: esiste un posto per il codice di crittografia sul lato client, tuttavia, come con tutte le applicazioni, gli sviluppatori devono riconoscere i limiti e implementare se adatti alle loro esigenze e garantire che vi siano modi per mitigarne i rischi.

Non accessibile a qualsiasi pagina web (true) ma è facilmente accessibile e facilmente modificabile tramite strumenti di sviluppo, come chrome (ctl-shift-J). Pertanto, la crittografia personalizzata è necessaria prima di memorizzare il valore.

Ma se javascript ha bisogno di decifrare (per validare) allora l’algoritmo di decriptazione è esposto e può essere manipolato.

Javascript ha bisogno di un contenitore completamente sicuro e della capacità di implementare correttamente variabili e funzioni private disponibili solo per l’interprete js. Ma questo viola la sicurezza dell’utente, dal momento che i dati di tracciamento possono essere utilizzati con impunità.

Di conseguenza, javascript non sarà mai completamente sicuro.

No.

localStorage è accessibile da qualsiasi pagina web, e se si ha la chiave, è ansible modificare qualsiasi dato desiderato.

Detto questo, se riesci a escogitare un modo per crittografare le chiavi in ​​modo sicuro, non importa come trasferisci i dati, se puoi contenere i dati all’interno di una chiusura, allora i dati sono (in qualche modo) sicuri.