Attenzione al furto dei cookie: Google risponde con DBSC

Quando accediamo a un sito Web effettuando il login con nome utente e password, è presente la casella Ricordami. Per fare in modo che l’utente non debba autenticarsi ogni volta che apre lo stesso sito Web, i dettagli sull’avvenuto login sono automaticamente memorizzati nel dispositivo locale sotto forma di cookie. Questi piccoli file di testo conservano l’ID di sessione ovvero una particolare informazione che permette di evitare una nuova effettuazione del login. Il fatto è che il furto dei cookie può consentire a un aggressore di rubare l’identità digitale di un altro utente.

In altre parole, senza conoscere nome utente e password corretti, in caso di furto del cookie di sessione, l’attaccante può svolgere operazioni così come se fosse un’altra persona. Non solo. Questo tipo di aggressione permette di superare eventuali meccanismi di autenticazione a due fattori (2FA) o a più fattori (MFA), abilitati in fase di login.

Furto dei cookie di sessione: sono all’ordine del giorno

Un cookie di sessione è un piccolo file di testo memorizzato sul dispositivo dell’utente quando visita un sito Web, effettua il login con successo e ha abilitato la casella Ricordami (o similare). Il file contiene informazioni uniche che permettono al sito di “riconoscere” l’utente, in modo autentico, in occasione delle successive connessioni, senza che questi debba ri-autenticarsi a ogni interazione.

Come funziona il cookie di sessione

Quando un utente si autentica su un sito (ad esempio con nome utente e password; eventualmente superando con successo i controlli legati all’autenticazione a due o più fattori), il server valida le credenziali e avvia una sessione per quell’utente. Per identificare in modo univoco la sessione, il server genera un identificativo di sessione (session ID).

Il session ID è inviato al browser Web dell’utente, che lo salva in locale – nel dispositivo in uso – all’interno di un cookie di sessione. Questo cookie di solito non contiene informazioni personali ma solo il codice identificativo, che funge da “chiave” per il server.

Ogni volta che l’utente interagisce con il sito durante la sessione in corso (e quelle successive, per un certo numero di giorni), il browser invia il cookie di sessione al server. Il server legge il session ID e riconosce l’utente, consentendo l’accesso senza ulteriori richieste di autenticazione.

Il cookie di sessione scade soltanto quando trascorre il numero di giorni impostato dal sito Web. In queste situazioni, l’utente deve effettuare un nuovo accesso. Alcuni siti, tuttavia, usano meccanismi per generare automaticamente un nuovo cookie di sessione quando il precedente sta per scadere, di fatto procastinando a tempo indeterminato la durata del cookie.

Impersonare altri utenti con i cookie di sessione

Il Federal Bureau of Investigation (FBI) ha recentemente invitato gli utenti a porre la massima attenzione sulla gestione dei cookie di sessione, rilevando continue ondate di attacchi che fanno leva proprio sul furto di queste informazioni.

Il furto dei cookie di sessione, tuttavia, non affatto una pratica nuova. In un altro articolo abbiamo spiegato cos’è il cookie o session hijacking descrivendo il caso di un noto YouTuber che si è fatto “sfilare” sotto il naso il suo popolare canale proprio per via del furto dell’ID di sessione.

La tecnica del cookie hijacking (o session hijacking) risulta particolarmente pericolosa per i servizi di webmail come Gmail, Outlook e così via, che contengono una vasta gamma di informazioni personali: dati bancari, cronologie di acquisti e contatti personali. Una volta ottenuto l’accesso a queste informazioni, i criminali possono orchestrare attacchi mirati sfruttando dati rilevanti per la vittima, aumentando così la probabilità di successo.

Come i criminali rubano i cookie di sessione

I criminali informatici si servono di varie tecniche per appropriarsi dei cookie di sessione altrui. Gli attacchi MITM (man-in-the-middle) sono sempre più rari grazie all’utilizzo della crittografia (ad esempio HTTPS) per proteggere i dati in transito. La maggior parte dei furti avviene tramite malware: software malevolo installato sul dispositivo della vittima e progettato specificamente per rubare i cookie di sessione.

D’altra parte provate a eseguire un’applicazione come ChromeCookiesView di Nir Sofer: essa restituisce istantaneamente l’elenco dei cookie gestiti dal browser Chrome. Di fatto un qualunque malware in esecuzione sul sistema potrebbe fare la stessa cosa. Una volta che i cookie sono stati rubati, “continuano a funzionare” anche dopo che l’utente procedesse alla rimozione del componente dannoso.

Inoltre, i fornitori di browser Web hanno risolto in passato (e, verosimilmente, continueranno a risolvere…) vulnerabilità che possono consentire l’accesso non autorizzato ai cookie di altri siti da parte di pagine malevole.

I cookie possono essere protetti con l’attributo SameSite, che limita l’accesso solo alle richieste provenienti dallo stesso dominio. Tuttavia, vulnerabilità nei browser possono consentire il bypassing di questa protezione, esponendo i cookie a potenziali attacchi.

Meccanismi di cookie tossing e DNS rebinding consentono ai malintenzionati di manipolare il comportamento del browser in modo da rendere accessibili cookie di siti a cui l’utente ha accesso, sfruttando il sistema DNS e scavalcano le restrizioni “same origin” imposte.

Protezione dai furti dei cookie di sessione

Per proteggersi dagli attacchi, i browser moderni integrano diversi livelli di protezione, come la separazione tra siti (Site Isolation), il rafforzamento delle politiche di sicurezza come Content Security Policy (CSP) e SameSite, la distribuzione di aggiornamenti correttivi utili a risolvere vulnerabilità emergenti.

Gli utenti dovrebbero quindi mantenere aggiornato il browser (anzi, tutti i browser installati sul sistema, compresi quelli che non utilizzano, ad esempio Edge), installare con regolarità le patch di sicurezza per il sistema operativo e gli altri software in uso, usare software di sicurezza con protezione antimalware estesa al contenuto delle email, evitare l’apertura di allegati sospetti e tenere sempre la guardia alta.

La sottrazione dei cookie di sessione può avere origine anche con la semplice apertura di un file che si presenta come un documento attendibile.

La risposta di Google: DBSC, device-bound session credentials, si basa su TPM

Per combattere il problema cookie hijacking, Google ha introdotto in Chrome 146 e versioni successive uno strumento chiamato Device Bound Session Credentials (DBSC), che mira a rendere inutili i cookie rubati, migliorando così la sicurezza degli utenti e preservando i loro dati.

Il concetto alla base di DBSC è legato alla correlazione tra le sessioni di autenticazione e il dispositivo utilizzato. Grazie all’API DBSC, un server può avviare una sessione di autenticazione con un browser specifico su un singolo dispositivo, creando una coppia di chiavi pubblica/privata in locale.

Il sistema si appoggia al chip TPM (Trusted Platform Module) per proteggere la chiave privata e garantire che il processo di verifica dell’autenticità della sessione sia sicuro e sempre riproducibile in ambienti diversi.

Con DBSC, ogni sessione è associata a una chiave unica, ma non consente il tracciamento persistente dell’utente tra sessioni differenti, impedendo la correlazione delle chiavi tra sessioni sullo stesso dispositivo. Inoltre, l’utente può cancellare le chiavi in qualsiasi momento attraverso le impostazioni del browser, garantendo che non vi siano tracce a lungo termine.

DBSC è progettato per essere compatibile con i meccanismi di gestione dei cookie già esistenti, integrandosi senza richiedere modifiche radicali ai siti Web. La sua architettura consente di migliorare la sicurezza dei cookie di sessione, riducendo i rischi legati al furto di cookie, senza compromettere l’infrastruttura preesistente o la facilità d’uso per gli utenti finali.

Come funziona la protezione hardware di Chrome

Come visto in precedenza, DBSC crea un legame crittografico tra sessione e dispositivo: quando l’utente effettua il login, il browser genera una coppia di chiavi: pubblica e privata.

La chiave privata è custodita all’interno di un modulo hardware sicuro, come il TPM su Windows o il Secure Enclave su macOS, e non può essere esportata.

Il server, durante la gestione della sessione, richiede al browser una prova crittografica del possesso della chiave. Solo se questa verifica ha successo, vengono emessi o rinnovati cookie a breve durata. Senza accesso alla chiave privata, un attaccante non può utilizzare i cookie rubati, che diventano rapidamente inutilizzabili.

Il sistema introduce anche una rotazione frequente dei token e una durata ridotta delle sessioni, riducendo ulteriormente la finestra temporale sfruttabile da eventuali attacchi.

Implicazioni per la sicurezza e lo sviluppo Web

L’adozione di DBSC richiede tuttavia alcune modifiche lato server: i servizi devono implementare endpoint dedicati per la registrazione e il refresh delle sessioni. Tuttavia, l’integrazione è progettata per mantenere la compatibilità con le interfacce esistenti, limitando l’impatto sul frontend.

Dal punto di vista della sicurezza, il vantaggio è netto: il modello passa da una logica reattiva a una preventiva. Anche in caso di compromissione del dispositivo, il valore dei dati sottratti si riduce drasticamente.

Un altro aspetto rilevante riguarda la privacy. Il sistema utilizza chiavi per ogni singola sessione e non espone identificatori persistenti: ciò evita che la protezione possa essere sfruttata come meccanismo di tracciamento tra siti diversi.

Limiti operativi e scenari reali

La protezione non è universale. Funziona solo su dispositivi dotati di hardware di sicurezza compatibile; in caso contrario, Chrome torna al comportamento tradizionale senza interrompere l’esperienza utente.

Inoltre, DBSC non elimina il malware: riduce l’impatto del furto di sessione, ma non impedisce altre forme di sottrazione dei dati. Gli infostealer continuano a rappresentare una minaccia ampia, in grado di raccogliere credenziali, documenti e informazioni sensibili.

L’iniziativa di Google si conferma comunque un passo significativo: i dati raccolti durante le fasi di test indicano una riduzione concreta degli attacchi riusciti basati su session hijacking, segno che l’approccio hardware-backed introduce una barriera reale per gli attaccanti.

Credit immagine in apertura: iStock.com – Pla2na