Come proteggere un'applicazione da utenti malintenzionati con accesso completo in lettura al db?

3

Lavoro su un'applicazione web con il lato client come applicazione Javascript a pagina singola e il lato server come servizio REST. Questa applicazione gestisce i dati sensibili degli utenti che non devono essere letti anche da un utente malintenzionato con accesso completo in lettura al database attivo o qualche archivio di database.

Il nostro piano è:

  1. quando l'utente si registra, genera chiavi asimmetriche sul lato client e le invia al server, con la chiave privata crittografata con una chiave derivata dalla password dell'utente
  2. autentica l'utente richiedendo la chiave privata crittografata dal server e decrittografandola sul lato client utilizzando la password dell'utente. La decrittografia eseguita correttamente è un'autenticazione corretta
  3. genera chiavi simmetriche quando viene creato un documento sensibile, crittografa il documento e condividi queste chiavi con gli utenti autorizzati, in stile PGP
  4. per il recupero della password diamo all'utente la sua semplice chiave privata e fidati di lui per tenerlo al sicuro

Si noti che assumiamo che l'attaccante non controlli né il browser né un server in esecuzione.

In questo scenario, quali sono i vettori di attacco che vedi?

È possibile implementare un meccanismo di ripristino più semplice che non richiede all'utente di memorizzare la chiave privata?

Hai altre preoccupazioni / raccomandazioni?

Grazie

    
posta vidi 07.02.2017 - 15:19
fonte

2 risposte

2

In this scenario, what attack vectors do you see?

Se la tua piattaforma è il browser, un possibile attacco potrebbe essere quello di modificare il codice javascript in transito e aggiungere alcune righe di codice che condividono le chiavi generate dai client con i cattivi.

Ciò implica un attacco MITM di successo sul traffico a valle. Ciò può essere reso possibile dalla progettazione in contesti in cui è in atto un filtro dei contenuti tra te e il cliente che ha bisogno di leggere il contenuto crittografato per poter prendere decisioni di filtro. Se un utente malintenzionato ha attaccato il server di filtro dei contenuti anziché il tuo server o il browser client, è probabile che potrebbe posizionarsi correttamente come server e modificare il javascript che il client vede, e non lo sapresti mai.

Hai detto che né il browser né il server sono sotto il controllo di un utente malintenzionato, ma se fosse il caso, ovviamente sarebbe un pezzo di torta interrompere il protocollo.

Fornire al browser un plug-in che può verificare le firme sul javascript scaricato può renderlo più sicuro, ma non so abbastanza del modello di sicurezza del browser per fare un'ipotesi informata.

Is it possible to implement a simpler recovery mechanism that doesn't require the user to store the private key?

In base al tuo commento per chiarire il design, direi di no.

    
risposta data 07.02.2017 - 15:53
fonte
2

Se non fosse il browser, lo schema sarebbe valido. Sfortunatamente, a causa di diversi problemi imposti dal browser, non lo è:

  1. MitM: come accennato in precedenza, gli hacker possono inviare JS errati compromettendo il trasporto. Inoltre, la verifica di javascript non aiuterà, a causa del modello di esecuzione del codice nel browser, potremmo facilmente aggiungere un altro <SCRIPT> , che si sovrapporrà ad alcune funzionalità, invece di sostituirlo.
  2. Supponendo che l'attaccante non possa controllare il browser è un'ipotesi sbagliata che non puoi davvero fare. Tutto nella tua pagina è controllato dal contenuto: qualsiasi parte dell'albero DOM può influenzare qualsiasi altra parte dell'albero DOM. Anche qualsiasi risorsa esterna insicura sulla tua pagina è soggetta a MitM. Includete le risorse tramite le connessioni HTTP? L'attaccante non ha nemmeno bisogno di attaccare la tua connessione.
risposta data 09.02.2017 - 08:42
fonte