Google Chrome 146 protegge dal furto dei cookie di sessione: DBSC li rende inutilizzabili senza TPM (aggiornato: 10 aprile 2026, ore 00:25)

Per anni il furto di cookie di sessione è stata una tecnica particolarmente efficace per rubare gli account degli utenti. Il motivo è semplice e brutale: un cookie di sessione già autenticato scavalca qualsiasi protezione a più fattori, perché rappresenta una sessione già validata. L'attaccante non ha bisogno di password né di codici temporanei. Ha bisogno solo di quel piccolo file di testo. Con Chrome 146, Google prova a chiudere questa scappatoia introducendo Device Bound Session Credentials (DBSC), un meccanismo che lega crittograficamente le credenziali di sessione al dispositivo fisico dell'utente. Un cookie rubato e trasferito su un'altra macchina diventa, in teoria, completamente inutilizzabile

Come siamo arrivati fin qui

I cookie HTTP non sono mai stati progettati pensando alla sicurezza. Nati come semplice strumento di gestione dello stato nelle connessioni, si sono trasformati nel meccanismo universale per il mantenimento delle sessioni - e quindi nel bersaglio più ambito. Nel corso degli anni la comunità ha aggiunto strati di difesa: il flag Secure, il flag HttpOnly, i prefissi di nome, l'attributo SameSite. Nessuno ha risolto il problema alla radice.

Nel 2010, un'estensione per Firefox chiamata Firesheep rese il dirottamento di sessione un gioco da ragazzi sulle reti locali non cifrate. La diffusione capillare di HTTPS neutralizzò quell'approccio, ma gli attaccanti si adattarono in fretta, spostando l'attenzione verso il malware specializzato nel furto di cookie direttamente dal disco o dalla memoria del dispositivo.

La diffusione dell'autenticazione a più fattori (MFA) ha reso meno redditizio il furto diretto di credenziali. Ma il cookie di sessione aggira completamente l'MFA. Ecco perché gli infostealer hanno fatto del furto di cookie la loro principale fonte di reddito: gli accessi rubati vengono rivenduti o usati per prendere il controllo di account aziendali, caselle di posta, pannelli di amministrazione. Un'economia criminale matura e ben oliata.

Il problema di DPAPI su Windows

Su Windows, Chrome ha storicamente protetto i cookie a riposo tramite la Data Protection API (DPAPI) del sistema operativo. DPAPI cifra i dati legandoli all'utente del sistema: un altro utente sulla stessa macchina, o un attacco a freddo sul disco, non accede ai cookie in chiaro. Sulla carta sembra robusto. In pratica, il modello crolla di fronte a qualsiasi applicazione malevola che esegue codice nel contesto dello stesso utente - esattamente ciò che fa un infostealer. Se il malware gira con i privilegi della vittima, DPAPI gli apre la porta senza fare domande.

Su macOS, Chrome utilizza i Keychain Services, su Linux i portachiavi di sistema come kwallet o gnome-libsecret. Ma il grosso del problema si concentra su Windows, dove la quota di mercato di Chrome è più alta e dove gli infostealer proliferano con maggiore intensità.

Il primo tentativo: App-Bound Encryption

Google non è arrivata alle DBSC dal nulla. Nel luglio 2024, con Chrome 127, ha introdotto su Windows la App-Bound Encryption: un miglioramento di DPAPI che lega i dati cifrati all'identità dell'applicazione, non solo all'utente del sistema. Il concetto ricorda quanto fa il Keychain di macOS: solo Chrome, verificato tramite un servizio privilegiato, può decifrare i propri cookie. Un infostealer che gira come utente corrente ma non è Chrome si trova davanti a dati illeggibili.

Il primo lancio ha coperto i cookie, con l'intenzione dichiarata di estendere la protezione anche a password, dati di pagamento e altri token di autenticazione persistenti. Un passo avanti rispetto allo status quo, ma non abbastanza: la protezione resta locale. Un cookie esfiltrato da una macchina priva di App-Bound Encryption, o da una versione vulnerabile, rimane perfettamente utilizzabile altrove.

DBSC: la crittografia legata al dispositivo

Il nuovo Device Bound Session Credentials rappresenta un cambio di approccio. L'idea è elementare nella sua logica: invece di proteggere solo la memorizzazione del cookie, si lega la validità stessa della sessione al dispositivo fisico.

Al momento della creazione della sessione, Chrome genera una coppia di chiavi crittografiche. La chiave privata viene conservata in hardware, idealmente nel TPM (Trusted Platform Module) presente sulla maggior parte dei PC Windows moderni, e non lascia mai il dispositivo. Il server associa la sessione a quella chiave pubblica e, periodicamente, invia una sfida crittografica per verificare che la sessione sia ancora attiva sulla stessa macchina. Se il cookie viene copiato altrove, l'attaccante non può superare la verifica: non possiede la chiave privata.

Il cookie, da solo, perde valore. Diventa un riferimento inerte senza la chiave privata che lo accompagna. Per un infostealer che raccoglie cookie questa è una pessima notizia: il "passaporto" rubato viene subito invalidato, e non funziona più.

Solo su Windows, per ora

La copertura resta però limitata. L'implementazione di DBSC in Google Chrome funziona al momento solo su Windows. macOS, Linux, Android e iOS non sono ancora supportati.

Microsoft Edge ha condotto un proprio test, conclusosi nell'ottobre 2025 senza annunciare una data di disponibilità generale. Mozilla sta valutando la tecnologia ma non ha preso impegni concreti. Il team di WebKit ha discusso l'argomento senza annunciare un'implementazione. Per ora è una funzionalità di Chrome su Windows, punto.

Questo è un limite che pesa. La sicurezza di sessione è efficace solo se l'ecosistema la adotta in modo ampio: un server che decide di richiedere la verifica DBSC esclude di fatto tutti gli utenti su browser o piattaforme non supportati. L'incentivo all'adozione lato server cresce solo con la massa critica lato client - e quella massa critica, oggi, non c'è.

Gli infostealer stanno già rispondendo

Sarebbe ingenuo pensare che i criminali informatici stiano a guardare. SpyCloud, azienda specializzata in intelligence sulle minacce legate agli infostealer, ha pubblicato un'analisi secondo la quale gli sviluppatori di infostealer starebbero già lavorando - o avrebbero già sviluppato - tecniche per aggirare DBSC.

I dettagli specifici non sono disponibili nel materiale a disposizione, e su questo punto serve cautela. La dinamica, però, è storicamente prevedibile: ogni nuova difesa innesca una corsa all'adattamento. Il furto di cookie è troppo redditizio perché chi scrive infostealer lo abbandoni senza lottare.

In compenso, se DBSC alza il costo dell'attacco in modo sufficiente, l'economia criminale si sposta verso bersagli più facili: non è necessario rendere il furto impossibile, basta renderlo antieconomico.

Un passo necessario, non una soluzione definitiva

DBSC richiede hardware con TPM, supporto lato server, e un'adozione trasversale tra browser e sistemi operativi che oggi non esiste. Ma il principio sottostante - spostare la fiducia dal cookie come token al portatore verso una prova crittografica legata al dispositivo - colpisce direttamente il modello di business degli infostealer.

Con questa mossa Google ammette implicitamente che decenni di rattoppi sui cookie non hanno funzionato, e che la protezione dei dati a riposo non basta quando il malware opera con gli stessi privilegi dell'utente. Il legame crittografico con l'hardware è un approccio strutturalmente diverso. Se Mozilla, Apple e i grandi fornitori di servizi web adotteranno meccanismi equivalenti, il furto di cookie potrebbe davvero diventare un ricordo. Ma quel "se" rimane grande quanto un TPM è piccolo.

Fonti: bleepingcomputer.com, security.googleblog.com