Gestione sessione: imposta il nuovo valore dell'ID sessione dopo la modifica dei privilegi e altre operazioni sensibili

È importante citare anche le frasi precedenti:

The session ID must be renewed or regenerated by the web application after any privilege level change within the associated user session. The most common scenario where the session ID regeneration is mandatory is during the authentication process, as the privilege level of the user changes from the unauthenticated (or anonymous) state to the authenticated state. Other common scenarios ...

In altre parole, OWASP riassume il caso in cui un utente cambia ciò che è autorizzato a fare o con ciò che è autorizzato. Darò un esempio di ogni caso:

1. L'utente cambia ciò che è autorizzato a fare: un utente che accede a un altro account (ad esempio google "accede come un altro utente") deve annullare la sessione corrente prima di poter accedere all'altro account. Questo è importante perché stai mantenendo una sessione aperta per un periodo di tempo limitato (per rendere più difficile il dirottamento di una sessione).

   Ora, se uno degli account a cui l'utente ha credenziali è compromesso e l'altro no, l'utente malintenzionato potrebbe utilizzare le sessioni sovrapposte per eseguire qualcosa come l'account che non è riuscito a compromettere. Pertanto è importante che la sessione precedente venga uccisa (non importa se la sessione precedente o quella nuova è quella per un account compromesso).

   Come extra, se un utente malintenzionato può forzare un utente che ha effettuato l'accesso a due account passa da uno all'altro ripetutamente, potresti non riuscire a contare il tempo di sessione ed essere vulnerabile alla fissazione. È più facile (e meno incline agli errori) invalidere semplicemente la sessione in loco, piuttosto che provare algoritmi intelligenti per mantenere vivi entrambe le sessioni. Questo è meno probabile, ma è comunque un modo per aumentare la superficie di attacco di un attaccante.

2. L'utente cambia il modo in cui è autorizzato (effettivamente autenticato, ma poi autorizzato): un utente che cambia la password deve avere la sua vecchia sessione distrutta sul posto perché è ciò che l'utente si aspetta che accada. Se la tua sessione dura 10 minuti e un utente cambia la sua password, si aspetta che un aggressore che crede abbia la sua password non possa più accedere al suo account. Non crede che l'attaccante possa usare il suo account per altri 10 minuti.

   Si noti che questo non è lo stesso requisito richiesto all'utente di inserire la vecchia password e la nuova password su una schermata di modifica della password. Dovresti assolutamente farlo, poiché impedisce a un utente malintenzionato in possesso di un ID di sessione di modificare la password dell'utente. Ma ciò che questa citazione di OWASP sostiene riguarda la distruzione della sessione precedente nel momento in cui viene ricevuta la richiesta POST con la modifica della password. In modo che un utente malintenzionato in possesso di un ID sessione non può utilizzare l'account dell'utente nel momento in cui la password viene ripristinata.

Considera un esempio comune di modifica dei privilegi: Amazon.

Se hai mai usato Amazon, il tuo browser ha un cookie persistente che dice ad Amazon chi sei, anche se non hai effettuato l'accesso. Quando apri il browser e accedi ad Amazon, mostrerà il tuo nome in alto a destra e avrai la possibilità di aggiungere oggetti al tuo carrello. Potresti chiamare questa autenticazione di livello 1.

Il cookie di autenticazione di livello 1 ha una durata molto lunga (potrebbe essere infinita) ed è persistente, il che significa che chiunque abbia accesso al tuo negozio di cookie potrebbe rubarlo.

Ora, diciamo che hai aggiunto alcuni articoli al tuo carrello e desideri completare un acquisto. A questo punto, Amazon richiederà l'inserimento della password. Una volta che hai fatto, hai privilegi aggiuntivi. Potresti chiamare questa autenticazione di livello 2.

Il cookie di autenticazione di livello 2 è molto più difficile da rubare. È un cookie di sessione solo http e si spegne quando chiudi il browser. E funziona solo per circa 30 minuti, credo.

Nota: è impossibile per il server dire se un cookie è http-only o se è un cookie di sessione, perché un browser mostra solo il valore del cookie stesso, non i suoi attributi. Quindi dal punto di vista del server web, tutto dipende dal valore del cookie stesso.

Ora immagina che Amazon non si sia preso la briga di cambiare l'ID di sessione al momento dell'accesso. Invece, mantiene lo stesso ID di sessione, ma memorizza una variabile di sessione che indica il privilegio elevato. Ecco un attacco plausibile:

1. Hacker ruba il tuo cookie persistente, che gli darà solo i privilegi di livello 1. No biggie, giusto?
2. Il tuo browser ha una copia esatta di questo cookie.
3. Ad un certo punto, accedi ad Amazon, decidi di completare un acquisto e accedi.
4. Il cookie ora ha i privilegi di livello 2.
5. L'hacker ha colpito occasionalmente il server Amazon con questo cookie per vedere se è stato effettuato l'accesso. Una volta che hai raggiunto il livello 2, puoi fare tutto ciò che puoi, incluso spedire un oggetto o cambiare la tua password.

Se l'identificativo di sessione è cambiato nel passaggio 3, questo attacco verrebbe contrastato.