Cookie rubati: perché la MFA non chiude una sessione già aperta

Il login è passato. E adesso?

Hai una password lunga, hai attivato il secondo fattore e il telefono non mostra richieste strane. Poi trovi una regola nella casella di posta che non hai creato tu. Com'è possibile?

Una delle spiegazioni è il furto di sessione, o session hijacking: qualcuno utilizza un accesso già autenticato. Non è una diagnosi automatica per ogni account compromesso, ma è il motivo per cui il controllo del login racconta soltanto una parte della storia.

Il caso non è teorico. Nel luglio 2022 Microsoft descrisse una campagna AiTM in cui gli attaccanti intercettavano password e cookie, accedevano alla posta e preparavano frodi nelle conversazioni commerciali. La vittima poteva avere la MFA attiva.

Il cookie che vale un accesso

Il browser non ti chiede la password ogni volta che apri una pagina. Dopo l'autenticazione, il servizio gli consegna un segreto che permette di riconoscere la sessione. Spesso viaggia in un cookie, ma non tutti i cookie servono ad autenticarsi.

Se quel segreto funziona come un bearer token, il possesso può bastare per usarlo. Contano però anche scadenza, revoca, controlli del servizio ed eventuale legame crittografico con il dispositivo. Dire “basta un cookie per entrare ovunque” sarebbe sbagliato.

Il NIST distingue la gestione della sessione dall'autenticazione iniziale. È una distinzione utile anche quando il login avviene tramite un identity provider: la sessione del provider e quella dell'applicazione possono avere vite separate.

Due strade verso la stessa sessione

Phishing con intermediario. In uno scenario adversary-in-the-middle, la vittima raggiunge un dominio controllato dall'attaccante che fa da tramite con il servizio reale. I codici OTP possono essere inoltrati mentre sono validi. Il risultato interessante per il criminale è la sessione ottenuta al termine del flusso.

Dispositivo compromesso. Un malware può puntare ai dati o al funzionamento del browser già autenticato. La riuscita dipende da privilegi e protezioni locali; non ogni estensione o programma può leggere qualunque cookie. Qui il problema esiste anche se il login originario era avvenuto correttamente.

Per distinguerlo da un'altra trappola, nel device-code phishing puoi invece trovarti sul dominio autentico e autorizzare il dispositivo sbagliato. Sono meccanismi diversi: l'etichetta “MFA bypass” da sola spiega pochissimo.

Le passkey cambiano il login

Le passkey si basano sull'autenticazione FIDO, legata al servizio: non consegnano a una pagina imitatrice una password o un OTP da inoltrare. Questo ostacola il classico phishing tramite proxy su un dominio diverso.

Il dispositivo e la sessione restano altre parti del sistema da proteggere. Se un malware agisce nel browser dopo l'accesso, la passkey non trasforma ogni richiesta successiva in una nuova verifica dell'utente. E recupero account e assistenza possono introdurre percorsi alternativi.

Tre attributi utili, tre limiti precisi

Un'intestazione didattica può apparire così:

Set-Cookie: __Host-session=<valore-casuale>; Path=/; Secure; HttpOnly; SameSite=Lax

<valore-casuale> è un segnaposto, non un identificatore da utilizzare. MDN documenta questi attributi:

Il prefisso __Host-, nei browser che lo supportano, richiede anche assenza di Domain e percorso /. La scelta di SameSite deve rispettare i flussi dell'applicazione: cambiare un attributo alla cieca può rompere un'integrazione senza risolvere il problema delle sessioni.

Sul banco: la revoca funziona davvero?

Questa prova riguarda una tua applicazione di sviluppo o un ambiente per cui sei autorizzato, con account e dati fittizi. Servono due profili separati del browser, chiamati A e B. Non occorre esportare cookie né copiarli in strumenti esterni.

1. Accedi allo stesso account di test in A e B. Da B apri una risorsa riservata, per esempio la pagina delle preferenze.
2. In A usa la funzione che dovrebbe revocare le altre sessioni. Annota orario, comando usato e comportamento previsto dal prodotto.
3. In B richiedi nuovamente la risorsa al server. Osserva la richiesta nella scheda Network: una vecchia schermata rimasta nella cache non dimostra accesso ancora valido.
4. Accedi nuovamente in A e B, poi ripeti la prova cambiando la password in A. Confronta l'esito con la specifica: le due operazioni revocano davvero gli stessi accessi?
5. Se c'è un login federato, controlla anche l'applicazione collegata. Il logout dal provider non dimostra, da solo, la chiusura di tutte le sessioni applicative.

Il risultato utile è una piccola tabella: azione, sessione coinvolta, tempo osservato, richiesta accettata o rifiutata. Se il requisito è revoca immediata, una nuova richiesta autenticata accettata dopo la revoca merita indagine. Se il prodotto dichiara una finestra, misura quella finestra: non inventare una garanzia che l'architettura non offre.

Quando serve reagire

La documentazione Microsoft sulla revoca spiega perché access token, refresh token e sessioni delle applicazioni possono rispondere in tempi diversi. Il pulsante “disconnetti tutti” va compreso nel suo contesto.

Su un account sospetto, usa un dispositivo affidabile e la procedura del servizio per interrompere gli accessi, proteggere le credenziali e verificare applicazioni autorizzate e metodi di recupero. In azienda coinvolgi chi gestisce identità e risposta agli incidenti: una macchina ancora compromessa può esporre anche le nuove credenziali.

Per chi sviluppa, OWASP raccomanda invalidazione lato server, rotazione dell'identificatore dopo l'autenticazione e timeout. La sola scadenza del cookie nel browser non è una revoca del segreto sul server. Le operazioni delicate devono poter richiedere una verifica fresca.

Infine, attenzione ai falsi allarmi: un IP diverso può dipendere da rete mobile o VPN. La guida OWASP sul furto di cookie invita a combinare segnali e riautenticazione. Anche restare nello stesso paese non dimostra che sia tutto regolare.

Il test più interessante, alla fine, è semplice da formulare: dopo aver tolto un accesso, quel browser può ancora fare qualcosa? È lì che una promessa di sicurezza diventa un comportamento verificabile.