Qual è il modo migliore per proteggere le risposte in una singola app Web dopo il logout?

Question

Qual è il modo migliore per proteggere le risposte in una singola app Web dopo il logout?

#1 da (1 voti)
#2 da (0 voti)
#3 da (0 voti)

4

Ho letto alcune delle grandi risposte all'archiviazione e al passaggio delle chiavi di sessione in un'applicazione web a pagina singola (ad esempio, un "sito" web che funziona principalmente sul lato client, ottenendo dati dal server utilizzando un'API ). Ma la mia domanda riguarda la messa in sicurezza (dopo il logout) dei dati che ritornano nella risposta, di cui non ho visto alcuna menzione.

Questi dati sono direttamente accessibili da qualsiasi browser moderno facendo clic sulla vista degli strumenti di sviluppo (anche quando si utilizza HTTPS). Pertanto, può succedere quanto segue:

Utente autenticato (AU) utilizza l'applicazione e scarica le informazioni protette.
AU si disconnette o si disconnette automaticamente.
L'applicazione ritorna alla pagina "Login". Sembra sicuro, quindi AU non chiude la scheda / pagina.
Tuttavia, Utente (malintenzionato) non autenticato (UU) siede alla scrivania e apre gli strumenti di sviluppo. Nella sezione Rete, l'UU può vedere oggetti JSON strutturati con molte informazioni succose.

Questo non accade in un'applicazione web più tradizionale, perché i dati sono incorporati nella pagina HTML, che è scomparsa quando il browser reindirizza alla pagina di accesso.

Usiamo AngularJS per la nostra app Web a pagina singola, che consiglia di utilizzare una funzionalità di modifica della posizione per il logout, che ho confermato non esegue un reindirizzamento effettivo (in base alla progettazione); quindi la pagina non viene aggiornata; quindi le richieste di rete possono essere trovate nella sezione sviluppatori.

Sembra che la strada da percorrere sia quella di NON utilizzare il metodo AngularJS e invece di rompere il modello e utilizzare il reindirizzamento javascript puro per aggiornare il sito nella pagina di accesso. Questo sembra cancellare le richieste di rete. È questo il metodo consigliato?

Mi rendo conto che avere accesso al browser significa che l'UU può installare keylogging, cattura dello schermo e tutti i tipi di cose che sono anche peggiori di questo scenario, e non c'è nulla che possiamo fare al riguardo, ma lo scenario che sto descrivendo qui è uno scenario di ufficio molto comune in cui gli utenti occasionali possono sedersi velocemente su un browser e spiare alcune informazioni senza fare molto lavoro. Dato che abbiamo a che fare con informazioni sanitarie protette, rimane una preoccupazione.

javascript client-side single-page-app

posta Yuri 01.12.2014 - 05:41

fonte

3 risposte

Leggi altre domande sui tag javascript client-side single-page-app

è un cookie HttpOnly e Secure sufficiente a prevenire CSRF in api di riposo? C'è qualche rischio per la sicurezza, se il database con i maniglie delle chiavi per i dispositivi U2F è trapelato?

score 1 · Answer 1

Criptare il contenuto utilizzando una chiave di sessione mentre si è in transito. Decifrare il contenuto in memoria usando una variabile. Al logout, si cancellano chiaramente le variabili contenenti le chiavi e le informazioni decodificate. Inoltre, elimina chiaramente tutte le variabili contenenti informazioni di autenticazione e qualsiasi informazione che è stata utilizzata per generare la chiave di sessione. La chiave di sessione può essere generata da informazioni di autenticazione come hash di nome utente / password e altre informazioni accessibili sia al client che al server, ma NON a qualcuno che osserva il traffico di rete decodificato all'interno di una sessione SSL (come fanno gli Strumenti per sviluppatori). State attenti anche agli attacchi "pass-the-hash" sullo schema di autenticazione - ad esempio se avete hash username / password sul client, fate attenzione che qualcuno possa trovare l'hash della password all'interno degli strumenti dello sviluppatore e poi inviare l'hash stesso per accedere - senza conoscere il password.

Un suggerimento sta seguendo:

1: l'utente effettua l'accesso con nome utente e password.

2: L'applicazione invia Username, H (Username, H (Password, T), T) dove H () è una funzione hash e T è un timestamp. Leggi di più in 3 come viene costruito il timestamp.

3: Server verifica che il record sia valido. Ciò si ottiene facendo in modo che T sia un timestamp che abbia una granularità di 1/2 del tempo di validità previsto. Questo viene generato tagliando i bit da un timestamp di epoca unix standard. Ad esempio, se si desidera una validità di 5-10 minuti, rimuovere gli ultimi 8 bit dal timestamp. Alla convalida, controlla se la corrispondenza hash con T = current_timestamp, T = current_timestamp-1 o T = current_timestamp + 1 per compensare un orologio client che è leggermente spento. Ciò dà una validità di 256-768 secondi, che è di 4-12 minuti.

4: L'applicazione ora genera una chiave di sessione, usando H (Username, Password, T, Static salt). Salva la chiave di sessione nella variabile. (questo garantisce che la sessione possa essere utilizzata per più di 4-12 minuti). NOTA: NON è possibile utilizzare un timestamp per scadere di una sessione, È necessario cancellare le variabili se si desidera scadere la sessione a causa di inattività. Ricorda che le variabili sono accessibili a un utente malevolo se non vengono cancellate: il timestamp viene utilizzato solo per scadere di un hash della password utilizzato in modo che non possa essere riutilizzato.

5: Lo script del server genera una chiave di sessione allo stesso modo, assicurando di utilizzare solo la T che è stata trovata corretta durante la convalida a 3.

6: utilizzare la chiave di sessione per crittografare le informazioni nelle strutture JSON.

7: al logout, cancella la chiave di sessione, il nome utente, la password, H (password, T) e H (nome utente, H (password, T), T) e anche qualsiasi informazione trasferita durante la sessione. Questo si ottiene semplicemente impostando la variabile su nulla, ad esempio key = "";

Lo schema di accesso sopra riportato rende tutto sicuro sia contro attacchi pass-the-hash che protegge le informazioni in transito usando una chiave di sessione univoca. Anche le chiavi di sessione di un'altra sessione non possono essere utilizzate per decodificare le sessioni precedenti.

Ciò garantisce che le informazioni siano crittografate quando sono visibili negli Strumenti per sviluppatori. Non è possibile ottenere i valori delle variabili negli Strumenti per sviluppatori dopo che sono stati cancellati, garantendo l'accesso ai dati.

Se i computer si trovano in un segmento controllato, cosa che dovrebbero essere se si sviluppa un'applicazione di registrazione sanitaria accessibile ai medici, è NECESSARIO disabilitare tutte le funzioni di debug / sviluppatore tramite un criterio di gruppo. Ma è difficile farlo se i pazienti accedono all'applicazione.

score 0 · Answer 2

Credo fermamente in una pagina di accesso / uscita completamente separata. È meglio per comunicare all'utente che sono stati disconnessi. Se cambia solo una parte della pagina, sarebbe facile ignorare se un utente non ha effettuato correttamente il logout.

score 0 · Answer 3

L'hai inchiodato.

It seems that the way to go is to NOT use the AngularJS method, and instead to break the model and to use the pure javascript redirect to refresh the site onto the Login page. This does seem to clear the network requests. Is this the recommended method?

La migliore garanzia è di lasciare la pagina. Dopo aver eliminato il cookie di accesso, è possibile inviare l'utente ovunque. Reindirizzali alla tua home page, stack overflow, questa domanda anche a google. Potresti creare una pagina di solo accesso che utilizzi semplicemente per reindirizzare l'utente in qualche modo utile dopo il logout.