Design di alto livello per applicazioni web sicure

2

Sto cercando alcuni consigli su come progettare un'applicazione web sicura per memorizzare le password. Perché reinventare la ruota? Perché non mi fido di una terza parte con tutte le mie password.

Ecco i miei pensieri:

  • Ci sono 3 componenti principali: Client, Application Server, Database Server. Idealmente, mi piacerebbe che il sistema fosse abbastanza robusto, così che se l'Application Server o il Database Server sono compromessi, l'hacker non ottiene tutti i dati (se il client è compromesso, non riesco a vedere alcun modo per proteggere i dati).
  • Per riuscirci, penserei che fare tutto il codice di crittografia sul client abbia senso. Quindi, se il server database è compromesso, otterrebbero solo i dati crittografati e, se il server delle applicazioni è compromesso, non otterrebbero le chiavi di crittografia perché il client le mantiene.
  • Questo crea almeno 2 problemi:

    • Crypto lato client in questo contesto indica crypto javascript che è problematico . Ecco come sto pensando di risolvere alcuni dei problemi principali.

      • Non buono CSPRNG. Utilizza solo i browser con getRandomValues () e utilizza una libreria crittografica js che lo supporta.
      • L'uomo nel mezzo. Forza TLS per tutte le connessioni (non aiuta se App Server è compromesso, ovviamente).
      • vulnerabilità XSS. Scrivi uno script utente complementare (Greasemonkey) che calcola gli hash di ogni pagina nell'app e avvisa l'utente quando il contenuto di una pagina è cambiato. Ovviamente, questo porterà a falsi positivi quando si effettuano gli aggiornamenti, ma dovrebbe consentire di rilevare se qualcuno ha modificato il proprio codice sul server delle app o di aver inserito correttamente qualsiasi contenuto nella pagina.
    • La ricerca su dati crittografati è complicata .

      • Non ho ancora soluzioni concrete per questo, ma se il piano generale sembra fattibile, ci sono buone opzioni là fuori.

Mi rendo conto che questa domanda è un po 'ampia, quindi sentitevi liberi di chiuderla se non è adatta al sito. Spero solo di avere qualche indicazione generale su cosa potrei mancare o dove sono i buchi nel mio piano.

Aggiornamento: Grazie a tutti per il feedback molto utile. Alla luce di alcuni dei problemi sollevati, il mio nuovo piano è rendere tutto molto più semplice. Mantenere un singolo file JSON compresso e crittografato sul server. Scrivi un'app JS che viene eseguita localmente. Tutto ciò che fa è prendere il file, decodificarlo localmente e quindi ricaricarlo quando vengono apportate modifiche. Pensieri?

Inoltre, vedo il tuo punto sull'uso di un sistema ben controllato e comprovato. Chiamami un paranoico dalla stagnola, ma non posso fidarmi di qualcun altro con così tanto accesso. Tutto ciò che serve è un dipendente / collaboratore scontento o un buco di sicurezza per per avere una giornata davvero brutta.

    
posta Dominic P 22.01.2015 - 23:06
fonte

2 risposte

2

Il problema di un'app Web è che è fondamentalmente insicuro se il codice sorgente (ad esempio JavaScript) viene consegnato al client tramite TLS. Puoi eseguire la migliore crittografia che desideri, ad es. one-time pad o cipher in cascata, ma solo è sicuro quanto i cifrari e la "sicurezza" nella suite TLS che è non sicuro contro le agenzie di spionaggio . Ci sono stati errori fondamentali in TLS per anni . Probabilmente di cattivo design perché NSA è su tutte le comitati di standard . Leggi anche il fiasco OpenSSL Heartbleed . Per non parlare dell'intero protocollo è banalmente insicuro contro gli avversari dello stato nazione con una sola CA in tasca . Tutto quello che devono fare è MITM la connessione e scambiare alcune righe di JavaScript dubbia per rubare le chiavi e le password di crittografia.

Hai avere per creare un'estensione per il browser o eseguire il codice Web localmente dal percorso del file. Utilizzare CORS per effettuare richieste al server delle applicazioni. Tutto il codice viene caricato ed eseguito localmente. Tutta la crittografia fatta lato client. Nessun codice fornito dal server.

Puoi anche aggiungere codice personalizzato sul client e sul server delle applicazioni per crittografare il traffico di trasporto dal client al server delle app per proteggere anche i metadati, se lo desideri.

    
risposta data 23.01.2015 - 00:15
fonte
1

Questo è uno di quei posti di lavoro migliori per i professionisti INFOSEC. Troppo per sbagliare. La cosa più vicina che ho visto a ciò che stai descrivendo è Clipperz:

link

Esecuzione da un file locale hardcoded con I.P. del server. l'indirizzo su SSL o IPsec sarebbe un inizio. Concordo con NDF1 sul fatto che un'app nativa sia migliore principalmente a causa della ridotta superficie di attacco e amp; maggiore flessibilità di sviluppo per la tecnologia di ingegneria della sicurezza. Ecco perché progetti come KeePass hanno già creato per noi utili gestori di password multipiattaforma. Direi che basta usare uno strumento come KeePass o studiare i metodi di tali strumenti se si sceglie di eseguire il rollover. Inoltre, per aiutare, ecco il mio saggio su molti approcci all'avanguardia e tipici per la sicurezza delle applicazioni web con link:

link

    
risposta data 23.01.2015 - 03:14
fonte

Leggi altre domande sui tag