Best practice per la sicurezza dei dati su un'applicazione web

5

Ho letto un paio di articoli sulla privacy / sicurezza ma non riesco ancora a ottenere un quadro chiaro delle migliori pratiche per garantire che un utente malintenzionato non sia in grado di accedere alle informazioni private degli utenti.

Per memorizzare password o altri dati che verranno controllati solo per verificare l'autenticità, capisco che algoritmi di hashing come SHA-256 sono candidati perfetti in quanto la password stessa non ha bisogno di essere archiviata (o anche conosciuta) sul server- lato.

Tuttavia nel mio caso, oltre alla password, permetto agli utenti di archiviare altri segreti che il server deve essere in grado di decifrare per il lavoro in background che leggerà questi segreti per fornire statistiche storiche, senza che l'utente sia loggato Questi "segreti" sono solitamente chiavi di accesso a servizi esterni, che potrebbero essere pericolosi se in mani sbagliate.

Una possibile soluzione sarebbe stata quella di utilizzare la sessione utente oi cookie per memorizzare i segreti, ma oltre a essere soggetti a cookie o dirottamenti di sessione, richiede che l'utente sia connesso per lavorare e nel mio caso ho bisogno il server per poter decodificare e utilizzare i segreti per le attività in background senza che l'utente abbia effettuato l'accesso.

Quindi un'altra soluzione sarebbe quella di crittografare i segreti nel database usando ad esempio AES-256 e mantenendo la chiave di crittografia fuori dal database. Se l'autore dell'attacco accede al database, non può decrittografare i segreti dell'utente. Se l'autore dell'attacco accede al filesystem del server, ottiene l'accesso alla passphrase, ma non al DB ... oh, aspetta un minuto, perché non il DB? Se l'autore dell'attacco accede al filesystem del server, inclusa la configurazione, ottiene anche l'accesso al database poiché le stringhe di connessione si trovano anche nella configurazione sul filesystem. Quindi se l'attaccante ottiene l'accesso al filesystem, ottiene l'accesso alla passphrase AND il db ...

Non riesco a pensare ad alcuna soluzione per separare veramente la passphrase dal db. Mi sto perdendo qualcosa? Esiste una soluzione reale per proteggere i segreti degli utenti in modo che almeno 2 diversi sistemi (DB / file) debbano essere hackerati per ottenere l'accesso ai segreti, sapendo che il server deve essere in grado di crittografare / decifrare i segreti senza l'aiuto degli utenti?

Il mio progetto verrà eseguito nel cloud con nodejs come server Web e mongodb come database e prima di aprirlo al pubblico mi piacerebbe assicurarmi che sia quasi impossibile per un utente malintenzionato recuperare i segreti degli utenti, cosa che non fa Sembra che sia così.

Modifica: invece di memorizzare la passphrase nella configurazione, potevo effettivamente passarla nel comando all'avvio del web server (nodejs nel mio caso). Quindi, invece di leggere la passphrase dal file flat di configurazione, lo legge dalla riga di comando. Fare ciò assicurerebbe che la passphrase non venga mai scritta in un file (supponendo che io possa disabilitare la cronologia di bash) ed è solo in memoria, il che è più difficile da hackerare no? L'unico svantaggio è che ho bisogno di avviare manualmente il server se si abbassa, poiché l'avvio automatico inizierà senza conoscere la passphrase (quindi ho bisogno di avviarlo da solo). Ma funzionerebbe? È una pratica conosciuta e usata?

    
posta Thomas 28.01.2014 - 23:11
fonte

1 risposta

1

Hai ragione che non esiste una soluzione eccezionale.

Sì, l'accesso tramite CLI e l'archiviazione nella RAM vengono talvolta utilizzati, ma il dumping della ram non è troppo difficile. Esistono moduli di sicurezza hardware specializzati in questo scenario (cerca questo termine se questo problema è abbastanza importante).

In generale, è meglio memorizzarlo in una cartella che ha le sue autorizzazioni molto limitate, quindi concentrarsi sull'indurimento del server in modo che l'attaccante debba fare due cose difficili (sfruttare un servizio, quindi privilegiare i privilegi). Non memorizzarlo nel database o in una directory accessibile all'utente web.

Crittografarlo usando AES sarebbe buono. Se l'utente malintenzionato può controllare il testo in chiaro o osservare il testo cifrato in qualsiasi scenario, è necessario prendere precauzioni molto maggiori per assicurarsi che sia implementato correttamente.

    
risposta data 29.01.2014 - 04:05
fonte

Leggi altre domande sui tag