Google ha attivato una nuova protezione contro il furto di cookie di sessione in Chrome 146 su Windows. Si chiama Device Bound Session Credentials (DBSC) ed è una funzionalità annunciata già nel 2024 che ora entra ufficialmente in produzione, con il supporto a macOS previsto in un aggiornamento futuro non ancora datato.

Per capire l’importanza di questa novità, bisogna partire da come funziona l’autenticazione web moderna. Quando si accede a un servizio online, il server genera un cookie di sessione (sostanzialmente un token di autenticazione) che viene salvato nel browser e presentato a ogni richiesta successiva. Questo meccanismo evita di dover reinserire le credenziali continuamente, ma introduce una vulnerabilità strutturale, visto che chiunque riesca a sottrarre quel cookie può accedere all’account della vittima senza conoscerne username e password.

È esattamente qui che operano i cosiddetti infostealer, famiglie di malware specializzate nella raccolta di dati sensibili dai dispositivi compromessi. Google cita esplicitamente LummaC2 come esempio di come questi strumenti siano diventati sempre più sofisticati nell’intercettare cookie dai file locali e dalla memoria del browser. Il problema, sottolinea Google, è fondamentalmente irrisolvibile con il solo software, visto che una volta che un malware ha accesso al sistema, può leggere qualsiasi dato memorizzato localmente, indipendentemente dal sistema operativo.

DBSC affronta il problema spostando la radice di fiducia fuori dalla portata del software malevolo, ancorando crittograficamente ogni sessione all’hardware specifico del dispositivo. Su Windows viene utilizzato il Trusted Platform Module, su macOS il Secure Enclave, entrambi chip di sicurezza dedicati che generano coppie di chiavi pubbliche e private direttamente al loro interno. La proprietà fondamentale di questi chip è che le chiavi private non possono mai essere esportate dalla macchina (esistono solo lì e lì rimangono).

Ma esattamente come funziona DBSC? Chrome dimostra al server di possedere la chiave privata associata alla sessione corrente e solo in base a questa prova il server emette cookie di sessione con durata breve. Anche se un attaccante riesce a sottrarre un cookie, si trova in mano un dato già scaduto e inutilizzabile, perché senza la chiave privata hardware non può rinnovare la sessione. Ecco perché l’esfiltrazione del cookie diventa, di fatto, un esercizio inutile.

Chrome 146

Crediti: Shutterstock

Privacy e compatibilità: due priorità dichiarate

Google ha progettato DBSC con attenzione esplicita alla privacy. Ogni sessione è supportata da una chiave distinta, il che impedisce ai siti web di correlare l’attività dell’utente attraverso sessioni diverse o su domini differenti. Lo scambio di informazioni tra browser e server è inoltre ridotto al minimo indispensabile (solo la chiave pubblica necessaria a certificare il possesso della chiave privata), senza che vengano trasmessi identificatori del dispositivo.

Per quanto riguarda l’adozione da parte degli sviluppatori web, i siti possono abilitare le sessioni hardware-bound aggiungendo endpoint dedicati per la registrazione e il refresh, senza dover modificare il frontend esistente. La compatibilità con i flussi di autenticazione tradizionali viene quindi preservata, abbassando la barriera tecnica all’implementazione.

Prima del rilascio generale con Chrome 146, Google ha condotto un anno di testing in partnership con diverse piattaforme web, tra cui Okta. I risultati hanno mostrato un calo significativo degli eventi di session theft, confermando che il meccanismo funziona nelle condizioni reali di utilizzo e non solo in laboratorio. Si tratta di un dato importante, perché molte soluzioni di sicurezza mostrano efficacia teorica, ma spesso si scontrano con le complessità dell’ecosistema web in produzione.

Con Chrome che detiene una quota dominante del mercato browser, l’adozione di DBSC potrebbe quindi ridurre sensibilmente la superficie d’attacco degli infostealer su scala globale a patto che i siti web decidano di implementare il protocollo lato server, passaggio su cui Google dovrà probabilmente fare un lavoro significativo di evangelizzazione nei prossimi mesi.