Protezione dei dati dell'utente contro un utente malintenzionato che può ottenere root del server

Question

Protezione dei dati dell'utente contro un utente malintenzionato che può ottenere root del server

#1 da (8 voti)
#2 da (1 voti)

3

Sto progettando un'applicazione web che gestirà dati molto sensibili, archiviandola per conto dei suoi utenti. Una specie di cassastrong online, se vuoi.

I dati protetti di un utente dovrebbero essere visibili solo a lei, nemmeno al software o al proprietario del server. Ciò apre la strada a solide pratiche di sicurezza, come l'utilizzo di una password per l'utente finale per crittografare / decodificare i suoi dati, o meglio, per crittografare una chiave simmetrica utilizzata per crittografare i suoi dati. Quest'ultimo consentirebbe di cambiare la propria password senza ricodificare tutti i record sul DB.

Posso garantire che un utente malintenzionato non possa accedere ai dati protetti, anche se dovessero ottenere l'accesso root al mio server?

Mi è venuta in mente la necessità di crittografare / decrittografare i dati utente sul lato client. I moderni browser e hardware consentono alla password e alla chiave di crittografia dell'utente di non lasciare mai il suo browser. Tutte le altre tecniche che posso immaginare hanno difetti fatali, in cui un utente malintenzionato può leggere la memoria del mio software server in esecuzione e trovare la chiave di crittografia.

Ma poi, come posso evitare che l'attaccante pianta un bug web nel mio sito web, o semplicemente cambiando il mio script sul lato client, per inviare le chiavi di crittografia degli utenti a modo loro?

Esiste una tecnologia, supportata da uno o più browser, in cui posso richiedere che tutti gli script sul lato client del mio sito Web siano firmati con un mio certificato? Per rispondere a questa domanda, supponiamo che i miei utenti credano che io possa scrivere un buon software, quindi si fidano del mio certificato.

Esiste un'estensione del browser che esegue tali controlli, che potrei consigliare ai miei utenti di installare?

Nel caso in cui non ci sia, come viene affrontata questa minaccia nel settore? Il controllo è l'unica soluzione? Ad esempio, controllando periodicamente il mio sito web da IP esterni, per assicurarmi che gli script sul lato client non abbiano cambiato hash crittografico.

Devo rinunciare all'idea di fare qualcosa del genere con tecnologie web aperte e risolvere il problema utilizzando un sistema di distribuzione software affidabile come gli app store Apple / Google? Questo dovrebbe solo spostare il problema sul server di qualcun altro, o in realtà affronta il problema sottostante?

Puoi consigliare qualche buona pratica libri / blog / articoli sull'argomento?

client-side encryption web-application

posta Tobia 07.11.2014 - 23:51

fonte

2 risposte

Leggi altre domande sui tag client-side encryption web-application

Come proteggere i file da qualcuno che ha accesso al computer che contiene quei file? Posso fidarmi dell'intestazione Host ricevuta nella richiesta?

score 8 · Answer 1

Forse uno dei casi di studio più interessanti proprio di questo tipo di situazione è www.blockchain.info, che impiega la crittografia lato client e ovviamente ha molto in gioco: il contenuto di milioni di portafogli bitcoin degli utenti.

Il loro approccio iniziale era un'estensione del browser che verificava le risorse di origine del sito Web rispetto a un elenco predefinito di somme hash: link . Questo approccio è durato un anno o due, quando è stato ritirato a favore di un'estensione del browser che impacchetta l'intera base di codice lato client nell'estensione stessa.

Purtroppo non riesco a trovare un blog o un articolo da loro che spieghi questo cambiamento, ma googling per questi termini ti troverà commenti che suggeriscono che l'approccio del "verificatore" non era completamente a prova di pallino.

L'approccio all'estensione riduce sicuramente il vettore di attacco poiché il codice responsabile della crittografia lato client viene scaricato solo una volta e inoltre, poiché gli store di app come Chrome Web Store o Google Play richiedono che gli aggiornamenti siano firmati con la stessa chiave di la versione iniziale, assicurando che gli aggiornamenti non possano essere manomessi, ovviamente supponendo che tu riesca a mantenere la tua chiave privata protetta e che non vengano trovati exploit contro il browser o la piattaforma dell'app store.

Sicuramente ti interesserebbe leggere il famoso articolo "Javascript Cryptography Considered Harmful" e i numerosi follow-up e confutazioni là fuori: link

score 1 · Answer 2

Il problema con un approccio di estensione del browser è che molti utenti non sarebbero disposti o abilitati a installarlo (ad esempio, registrati al loro posto di lavoro non sarebbero in grado di installare estensioni). Devi anche distribuire in modo sicuro l'estensione che è un problema stesso.

Un approccio bancario online Ho visto la banca mettere un browser / bin personalizzato su un CD-ROM o una chiavetta USB di una carta di credito. Ogni browser ha chiavi SSL univoche dell'utente e viene eseguito su un supporto di sola lettura. Il server Web può quindi verificare che la connessione del browser appartenga al client specifico. Potrebbe anche avere plugin personalizzati per verificare le risorse web.

Questo giorno è qualcosa come Apache Cordova o PhoneGap che pacchetti HTML + JS in app mobili create per tutte le piattaforme mobili è probabilmente uno spot di dolci . Sono un cliente di HSBC e la loro app sembra e si presenta come l'app HTMl + JS. Effettuerà "download degli aggiornamenti" occasionalmente quando l'app si apre (quali app native mobili non fanno) possibile scaricando nuove risorse web nell'archivio locale. Tutte le app di App Store sono firmate e le violazioni dei grandi negozi di Apple o di Google rappresentano una grande novità e vengono rapidamente corrette. Possono permettersi più audit e otterranno più attenzione al cappello bianco di quanto tu stia facendo da solo.

Potresti eseguire protocollo password SRP invece di inviare la password in formato testo. Vedi Can Io uso la stessa password sia per SRP che per la crittografia lato client? SMS per inserire un codice a quattro cifre da inserire mentre provano ad accedere e avrai anche l'autenticazione a due fattori.

Se non puoi seguire la rotta Cordova e i tuoi usi insistono nell'usare browser web arbitrari, beh, i rischi sono che la loro macchina è piena di virus ed è priva di patch. È possibile correggere i server, pagare per i test di penetrazione e sottoscrivere un servizio che monitora siti falsi, registrazioni DNS simili, DNS avvelenato, e-mail di phishing ecc. NetCraft fornisce tali servizi. Internamente puoi eseguire opensource tripwire per verificare gli hash di tutti i file nelle tue finestre di frontline per confermare che non sono stati caricati rootkit o bug web. Se l'utente ha un PC compromesso con un registratore di tastiera o un telefono su cui è stato effettuato il jail, non c'è nulla che tu possa fare per loro. L'esecuzione di SRP, l'autenticazione a due fattori, la crittografia lato client e il rilevamento di intrusioni tripwire di opensource sul tuo sito Web potrebbero essere sufficienti.