Quali sono le migliori pratiche per la sicurezza (basata su token) in un'app Web?

4

Sto progettando un'applicazione web utilizzando Spring MVC con controller REST e pagine JS angolari che comunicano con questi controller REST.

Ho implementato un meccanismo di sicurezza / autorizzazione basato su token che funziona. (Questo è basato sulla sicurezza basata su token JHipster.)

Questo token ha una scadenza (in questo momento sono 30 minuti - il valore predefinito).

Mi stavo chiedendo quali sono le migliori pratiche per rendere questa webapp il più sicura possibile mantenendo al contempo la semplicità d'uso per l'utente.

In questo momento, se un utente (ri) carica la pagina, il token nel cookie viene controllato se è ancora valido. Se lo è, il token verrà rinnovato (quindi viene generato un nuovo token valido per --time -).

Se un utente non visita la pagina più a lungo di --time-- e dopo aver visitato nuovamente, verrà disconnesso perché il suo token non è più valido.

Qual è la procedura migliore per mantenere l'utente connesso il più a lungo possibile, mantenendo comunque tutto protetto?

Inoltre, se l'utente è inattivo per, diciamo 30 minuti (nel mio caso la validità del token), e NON ricarica la pagina e quindi fa un'azione (che fa una chiamata REST sotto il cofano) non verrà autorizzato (ci sarà un errore 401 che mostra che la sicurezza sta funzionando). Sarebbe una buona idea monitorare la validità in background con javascript e se il token è quasi scaduto, chiedere una password e rinnovare il token o addirittura disconnettersi dall'utente? L'unica soluzione, come ora, sarebbe quella di ricaricare la pagina e accedere di nuovo ...

Qualche idea su quali sono le migliori pratiche saranno molto apprezzate!

    
posta E. V. d. B. 14.05.2015 - 20:07
fonte

1 risposta

3

In qualche misura può dipendere dal design della tua app web e dal livello di sicurezza la tua app richiede (in base a una valutazione del rischio). In breve, non c'è una risposta adatto a tutte le situazioni. La chiave per una buona esperienza utente è garantire il tuo il livello di sicurezza è in linea con i requisiti effettivi. Sicurezza troppo severa i requisiti con un timeout troppo breve porteranno alla frustrazione anche per l'utente poco li esporrà a rischi eccessivi.

Capire come viene utilizzata la tua app è molto importante. Niente frustra un utente più che essere costretti a ri-autenticarsi più volte in quello che considerano a singola sessione. Ad esempio, ho alcune app che tengo aperte a lungo, ma Potrei usare attivamente l'app solo poche volte al giorno. Non voglio re-autenticare dopo ogni 30 minuti di inattività, ma sono felice di ri-autenticarsi una volta a giorno. Altre app, come ad esempio la mia app per i servizi bancari, desidero richiedermi la re-autenticazione se la sessione è rimasta inattiva solo per un breve periodo.

Penso che l'obiettivo più importante sia rendere il processo di re-autenticazione come il più indolore possibile Costringendo qualcuno a reinserire le proprie credenziali e quindi a inviare raramente la loro home page è una buona soluzione. Quello che vuoi è un processo che interrompe brevemente il flusso di lavoro degli utenti, ma una volta autenticato di nuovo, li inserisce di nuovo nel loro flusso di lavoro nel punto in cui è stato interrotto dall'autenticazione processo.

Questo può essere un po 'complicato con le applicazioni tradizionali basate su dove gran parte del lo stato del flusso di lavoro viene mantenuto sul server, specialmente se si utilizza la sessione timeout. Tuttavia, sembra che la tua applicazione stia usando un sacco di javascript e quindi sospetto che tu mantenga lo stato locale.

Una soluzione consiste nel fare in modo che l'API di riposo verifichi il token / sessione e se la decisione è fatto che è necessario re-autenticare, passare i dati JSON che essenzialmente dice la tua app per eseguire nuovamente l'autenticazione prima di inviare nuovamente la richiesta. Javascript sul tuo il cliente può quindi utilizzare queste informazioni per far apparire una finestra modale da raccogliere dati di autenticazione, inviarlo al servizio di autenticazione per ottenere un nuovo token e quindi invia nuovamente la richiesta originale con il nuovo token.

per un'applicazione più tradizionale, la soluzione generale è usare il server reindirizza. Quando si tenta di accedere a un'API REST e il token è scaduto, reindirizzare il file browser alla pagina di accesso, ma avere la pagina di accesso accetta anche un url 'successivo'. Una volta il l'utente è autenticato, il servizio di login utilizzerà il parametro successivo per reindirizzare il il browser torna alla chiamata API REST originale. La sfida con questo può essere assicurata si mantengono tutte le informazioni di stato necessarie.

Un'altra aggiunta a volte accettabile è il servizio di autenticazione configurato in modo tale che se ottiene una richiesta di autenticazione che include un token che è ancora valido, non richiede all'utente di ri-autenticarsi. Invece, semplicemente emette un nuovo token. Ciò consentirà alla tua applicazione di rinnovare il token senza utente interazione in background. Le tue API REST possono essere configurate per reindirizzare a servizio di autenticazione se il token sta per scadere entro la prossima X secondi / minuti. Il vantaggio di farlo è che se qualcuno ha un tempo molto lungo sessione, non sono costretti a reinserire le proprie credenziali semplicemente perché il valore hai impostato per la scadenza del token è scaduto.

La maggior parte delle volte, le applicazioni su cui lavoro non hanno un'elevata sicurezza requisiti. Per queste applicazioni, tendo a utilizzare un valore di scadenza lungo per token e un timeout di scadenza ragionevole della sessione in base al tempo di inattività. In questo modo, il l'utente non è obbligato a ripetere l'autenticazione semplicemente a causa di una scadenza arbitraria per il token di autenticazione, ma sono tenuti a ri-autenticarsi se la sessione è rimasto inattivo per un determinato periodo di tempo.

    
risposta data 22.05.2015 - 01:06
fonte

Leggi altre domande sui tag