Applicazione Web - Scadenza cookie

Ci sono molti modi in cui un meccanismo di gestione delle sessioni può fallire e questo potrebbe portare a gravi rischi per la sicurezza.

Come buona pratica dovresti:

• Utilizza HTTPS, in modo che le informazioni contenute nei cookie non possano essere intercettate in transito.
• Imposta il flag di sicurezza per i cookie, in modo che non vengano inviati su connessioni non criptate.
• Imposta il flag HTTPOnly per i cookie, in modo che non possano essere letti utilizzando JavaScript
• Assicurarsi che l'identificatore di sessione (il valore nel cookie che identifica una sessione utente valida) non è facile da prevedere. Usa stringhe casuali di grandi dimensioni per questo scopo.
• Assicurarsi che l'identificatore di sessione venga modificato quando l'utente inizia una nuova sessione (effettua l'accesso), per impedire la fissazione della sessione
• Un meccanismo di scadenza della sessione dovrebbe essere implementato sul server. Non fidarti dell'utente per questo lavoro.
• Quando l'utente si disconnette, annulla la sessione sul server, in modo che anche se un utente malintenzionato tenta di utilizzare l'identificatore, non sarà accettato dal server.

Dalla tua descrizione, la tua aplicazione non riesce a raggiungere l'ultimo punto nell'elenco sopra. Dovresti controllare se gli altri punti sono soddisfatti. La somma di tutte le vulnerabilità nell'applicazione è quella che ti offre una visione generale di quanto sei sicuro / vulnerabile.

Devi prendere in considerazione che, sfruttando il problema che hai descritto, si può essere in grado di accedere a un account utente senza credenziali. Quanto è grave questo nel contesto della tua applicazione? Potrebbe questo utente malintenzionato accedere a dati sensibili, effettuare ordini, ecc.? Per un'applicazione può avere un grande impatto, per un altro potrebbe essere meno importante.

Per ulteriori informazioni consulta: Scheda trucco OWASP Session

Hai bisogno della memoria . Se il server non ricorda chi sono i client e quando sono stati autenticati per l'ultima volta, e si fida dei client per tenere traccia di se stessi, i client sono in grado di ingannare il server. Quello che descrivi (salvando e reimpostando il cookie) viene chiamato, in generale, un attacco di riproduzione . Per vedere le cose concettualmente, con la scadenza del cookie, ci si aspetta che il potenziale aggressore sia abbastanza aggraziato da dimenticare alcuni dati sensibili, dove non dimenticare che implicherebbe qualche guadagno per l'aggressore.

Questo porta a due modi principali per evitare il problema:

1. Chiedi al server di ricordare l'ora dell'ultima autenticazione per ciascun utente e applica la scadenza, indipendentemente dal fatto che il browser client abbia scaduto o meno il cookie.

2. Codifica nel cookie la data di scadenza, in modo che il server possa controllarlo. Ciò sta scaricando la memoria del server sui client; per renderlo sicuro (poiché il client potrebbe modificare i suoi cookie per prolungare la durata della sessione), è quindi necessario un po 'di crittografia, ovvero aggiungere un MAC calcolato con una chiave segreta che il server conosce ma che non dice a nessuno (in particolare, i client non lo sanno).

Poiché la crittografia è piena di trappole letali, sei incoraggiato ad applicare il primo tipo di soluzione. Si tratta principalmente di aggiungere una colonna nella tabella degli utenti, nel tuo database (presumo che tu abbia un database sul server); questo sarà economico.

La scadenza dei cookie non è comunque affidabile, anche in contesti non ostili, perché alcuni utenti non impostano correttamente l'orologio del computer. Alcuni sono disattivati di alcune ore (ad es. Sono nel fuso orario sbagliato) e alcuni sono disattivati da diversi anni (semplicemente non gli interessa).

Come minimo, i cookie dovrebbero tenere traccia di dove l'utente si collegava e invalidare al logout (cioè, il record della sessione dovrebbe essere scaduto nel DB). Idealmente, HTTPS dovrebbe essere usato per proteggere il cookie in transito, ma se la sicurezza non è così critica per il sito, scadendo la sessione di cookie dopo un limite di tempo e un logout e limitandolo a un determinato IP, si eseguirà un lavoro minimo di prevenire gli abusi casuali nel modo in cui hai descritto. Non impedirà a un Man in the Middle di essere in grado di dirottare la sessione se possono impedire il logout, o di essere in grado di fare cose mentre l'utente è loggato, ma almeno lo limiterebbe agli attacchi MITM in contrapposizione a qualsiasi persona anziana che capita di ottenere (o indovinare) il cookie. Inoltre, se scegli le tue chiavi di sessione, assicurati che siano grandi e casuali in modo da non essere semplicemente indovinate.

Devo ribadire che la best practice è HTTPS per tutti gli scambi di credenziali, inclusi i cookie di sessione, ma volevo anche dare un approccio migliore se non disponi di HTTPS come opzione.