Gestione delle sessioni: controlli su cookie, timeout e logout

Una volta che l'utente ha effettuato l'accesso, l'ID di sessione equivale temporaneamente al metodo di autenticazione più forte utilizzato dall'applicazione, che si tratti di password, codice monouso, certificato client, smartcard o impronta digitale. Se un attaccante riesce a indovinare, intercettare o imporre quell'ID, diventa l'utente, e il modulo di login non entra nemmeno in gioco. Testare le sessioni significa quindi testare l'ID, il cookie che lo trasporta e ciò che il server ne fa al login, dopo un periodo di inattività e al logout.

Questa checklist segue l'OWASP Session Management Cheat Sheet e la RFC 6265, la specifica dei cookie.

L'ID di sessione

Si parte da come viene generato l'ID. Il cheat sheet richiede almeno 64 bit di entropia, prodotti da un generatore di numeri casuali crittograficamente sicuro. A questa dimensione stima circa 585 anni per indovinare un ID valido, ipotizzando 10.000 tentativi al secondo e 100.000 sessioni valide contemporanee. Se genera i propri ID invece di usare quelli del framework, raccomanda almeno 128 bit e un valore univoco per ogni sessione.

Cerchi parti fisse o prevedibili. Un ID esadecimale di 16 caratteri con metà dei caratteri fissi ha solo 32 bit di entropia, che non bastano. Il valore, inoltre, non deve significare nulla per il client: nessun ID utente, ruolo o email al suo interno. Questo stato va tenuto sul server.

Controlli anche il nome. Nomi predefiniti come PHPSESSID, JSESSIONID, CFID/CFTOKEN e ASP.NET_SessionId rivelano a un attaccante quale stack utilizza. Il cheat sheet suggerisce un nome generico come id.

Non accetti mai l'ID in un URL. Gli ID trasportati negli URL trapelano tramite link, log, cronologia del browser, segnalibri, header Referer e motori di ricerca, e rendono più semplice la fixation.

Se l'accesso in lettura al vostro session store rientra nel threat model, i token in chiaro sono un rischio. Il cheat sheet descrive un'architettura divisa: il cookie contiene un identificativo e un verifier segreto, mentre il server memorizza l'identificativo insieme all'hash SHA-256 del verifier, confrontato in tempo costante. L'identificativo da solo non viene mai accettato.

Attributi dei cookie

La RFC 6265 definisce questi attributi per l'header Set-Cookie: Expires, Max-Age, Domain, Path, Secure e HttpOnly.

• Secure indica che il cookie va inviato solo su connessioni sicure. La RFC avverte che non offre alcuna garanzia di integrità contro un attaccante di rete attivo, quindi non lo consideri una protezione contro di esso.
• HttpOnly va impostato su ogni cookie di sessione. Verifichi il flag negli strumenti per sviluppatori del browser.
• Domain e Path definiscono l'ambito. Li mantenga entrambi non più ampi di quanto l'applicazione richieda.
• Expires e Max-Age indicano al browser per quanto tempo conservare il cookie. Non li usi come timeout.

Controlli gli altri header della risposta con il nostro strumento per le security headers.

Login, timeout e logout

Un ID di sessione che il browser possedeva prima del login e conserva dopo è esattamente ciò su cui si basano gli attacchi di fixation. Emetta un nuovo ID quando l'utente si autentica, in modo che il precedente cessi di essere valido.

I timeout richiedono due limiti. Un timeout di inattività chiude le sessioni che nessuno sta usando. Un timeout assoluto chiude le sessioni che restano attive all'infinito, e limita per quanto tempo un ID rubato rimane utile. Metta i valori per iscritto, li renda più brevi per l'amministrazione e i pagamenti e li applichi sul server, controllando il record di sessione memorizzato e non la data di scadenza del cookie.

Il logout deve distruggere la sessione lato server. Cancellare il cookie nel browser non basta, perché l'identificativo è la credenziale: chiunque lo abbia copiato in precedenza può ancora inviarlo. Dopo il logout, il vecchio ID non deve corrispondere a nulla. Il cheat sheet dedica inoltre una sezione al caching dei contenuti web e a Clear-Site-Data, utile da leggere per capire che cosa il browser conserva dopo il logout.

Usi, dove possibile, la gestione delle sessioni integrata nel framework. Il cheat sheet ricorda che queste implementazioni hanno avuto vulnerabilità, quindi utilizzi la versione più recente e riveda i valori predefiniti.

Cosa testare

1. Catturi il cookie prima e dopo il login. La prima richiesta deve effettivamente impostare un cookie di sessione, quindi verifichi che before.txt non sia vuoto. Conservi le credenziali in un file (creds.txt contenente user=test&pass=...) in modo che non finiscano nella cronologia della shell. I due ID devono essere diversi.

curl -i -c before.txt https://app.example/login curl -i -b before.txt -c after.txt -d @creds.txt https://app.example/login

1. Effettui il logout con il cookie autenticato, poi riproponga il vecchio valore, preso dall'ultima colonna di after.txt. Deve essere rifiutato. Se il logout è una POST, aggiunga -d '' al primo comando.

curl -i -b after.txt https://app.example/logout curl -i -b 'id=VALUE_FROM_AFTER_TXT' https://app.example/account

1. Effettui il login, resti inattivo oltre il timeout di inattività, poi invii una richiesta. Deve richiedere di nuovo l'autenticazione.
2. Mantenga attiva una sessione oltre il timeout assoluto. Deve comunque terminare.
3. Ispezioni Set-Cookie nella risposta di login per verificare Secure, HttpOnly e che Domain e Path non siano più ampi del necessario.
4. Raccolga qualche centinaio di ID e li confronti. Segmenti fissi e valori sequenziali sono finding. Confronti il nome del cookie con i valori predefiniti dei framework indicati sopra.
5. Cerchi ID di sessione negli URL, nell'applicazione, nei log e nei link.

Riporti i finding rispetto all'OWASP ASVS indicando la versione: v5.0.0-<chapter>.<section>.<requirement>. L'ASVS 5.0.0 è stato pubblicato il 30 maggio 2025 e i suoi requisiti sono disponibili in formato CSV. Aggiunga al foglio di test una colonna con l'identificativo per ciascun test, così che un test fallito si legga come un finding che cita il proprio requisito.

Da dove iniziare

1. Esegua prima i test 1 e 2 in staging: il confronto degli ID prima e dopo il login, poi il replay dopo il logout.
2. Catturi l'header Set-Cookie del cookie di sessione e corregga gli attributi mancanti o troppo ampi.
3. Verifichi come vengono generati gli ID. Se avete costruito un generatore proprio, passi a quello del framework, oppure confermi che usi una sorgente casuale sicura con almeno 128 bit.
4. Metta per iscritto i timeout di inattività e assoluto, li applichi lato server e aggiunga test che falliscano se qualcuno li rimuove.
5. Faccia in modo che il logout elimini il record di sessione lato server e aggiunga i test di replay alla vostra suite di regressione.