Dipende dal server web utilizzato. Se prendiamo PHP su Unix come esempio, può memorizzare la sessione sul filesystem nella cartella / tmp. Crea qui un file con il nome dell'ID di sessione degli utenti preceduto da sess_ (Esempio: /tmp/sess_9gk8f055hd61qll6a8pjpje2n2).Il contenuto della sessione può essere facoltativamente crittografato prima di essere inserito nel browser. Per le sessioni Apache (non necessariamente PHP) puoi usare il modulo mod_session_crypto ( Leggi di più qui ).
Il proprietario della sessione non può modificare le variabili di sessione come si sente a meno che l'applicazione non gli consenta di farlo. La logica dell'applicazione deve fornire i mezzi per cambiare la sessione in modo che l'utente possa modificare le variabili.
L'oggetto di sessione non viene mai trasmesso al client e solo un riferimento alla sessione (ad esempio PHPSESSID) viene passato al client. L'ID di sessione dovrebbe avere un'alta entropia e minimo 16 byte di lunghezza per essere molto difficile da indovinare. Vedi OWASP Top 10 - Autenticazione e gestione delle sessioni interrotte per ulteriori informazioni a riguardo. Consulta anche questo foglio Cheat OWASP per informazioni specifiche su come proteggere le sessioni.
Attacchi contro l'archiviazione delle sessioni:
Se esiste un difetto come ad esempio LFI (Local File Inclusion), è possibile che un utente malintenzionato legga il proprio e altri oggetti di sessione degli utenti includendo il file sul file system. Ad esempio, se il seguente esempio ha funzionato, potrei leggere i miei dati di sessione:
http://<victim>/?page=../../../../../../../../tmp/sess_<my sessionid>
