Rubare un cookie di sessione potrebbe presto diventare un esercizio quasi inutile, almeno per chi naviga con Chrome. Google ha avviato la distribuzione su larga scala di una protezione pensata per colpire una delle tecniche più sfruttate dai gruppi criminali che lavorano con gli infostealer: il furto dei token che tengono in piedi le sessioni autenticate. Al centro c’è la tecnologia Device Bound Session Credentials, abbreviata in DBSC, già anticipata in passato e progettata con un’idea semplice quanto efficace, impedire che un token sottratto da un malware possa essere riutilizzato su un dispositivo diverso da quello originale.
La mossa arriva dopo anni in cui i cookie rubati sono diventati una merce parecchio redditizia nel sottobosco criminale. In molti casi gli attaccanti non hanno nemmeno bisogno di conoscere password o codici 2FA: gli basta mettere le mani sulla sessione già aperta per entrare in servizi cloud, piattaforme aziendali, account Google, Microsoft 365 e applicazioni SaaS di ogni tipo. Diverse campagne legate a malware come Lumma, Vidar, StealC e altre famiglie hanno mostrato quanto il fenomeno si sia esteso, fino a diventare praticamente un’industria.
Perché i cookie di sessione fanno tanto gola
Quando qualcuno accede a un servizio web, il server crea normalmente un cookie che rappresenta la sessione autenticata. Finché quel token resta valido, una sorta di lasciapassare alfanumerico nascosto dentro il cookie, il browser continua a dialogare con il servizio senza chiedere di nuovo username, password o autenticazione a più fattori.
Molti malware vanno proprio a caccia di questi cookie attivi sui dispositivi delle vittime. Una volta trovati, li spediscono verso server controllati dagli attaccanti. Da lì il gioco è fatto: il criminale importa il cookie nel proprio browser e si presenta come la vittima, mettendo in pratica quello che viene chiamato session hijacking. Attacchi di questo tipo hanno colpito parecchie realtà, anche di primissimo piano. La tecnica è diventata popolare proprio perché scavalca molte difese tradizionali: anche un account protetto da 2FA può cadere se il cookie viene riutilizzato nel modo giusto.
Come lavora Device Bound Session Credentials dentro Chrome
Google aveva tirato fuori il progetto nel 2024, all’inizio come esperimento riservato agli sviluppatori. Dopo una fase di test con partner del settore identity e autenticazione, la funzione è entrata nelle versioni recenti di Chrome per Windows e adesso sta arrivando, poco alla volta, a tutti gli utenti. L’obiettivo è tagliare le gambe alla tecnica del cosiddetto pass the cookie, quella che permette di ereditare una sessione senza sapere nulla delle credenziali originali.
Il meccanismo cambia il modo classico di trattare i cookie di autenticazione. Invece di vedere il token come qualcosa di facilmente trasferibile, Chrome lo lega crittograficamente al dispositivo da cui è partito il login. In concreto il browser genera una coppia di chiavi di cifratura sfruttando i componenti hardware di sicurezza del sistema operativo. Su Windows entra in gioco il chip TPM: la chiave privata resta chiusa dentro il modulo hardware e non si può esportare in alcun modo.
Quando il server deve controllare se la sessione è ancora valida, Chrome dimostra di possedere la chiave giusta. Se un malware ruba solo il cookie ma non riesce a mettere le mani sulla chiave privata, il token perde quasi tutto il suo valore. Il sistema è stato pensato perché i siti possano adottare DBSC senza stravolgere la logica già esistente: i server continuano a gestire le sessioni, il browser si occupa della prova crittografica del possesso della chiave.
Dove la protezione mostra ancora qualche crepa
L’arrivo di DBSC per tutti è stato accolto bene, ma non sono mancate osservazioni sui limiti pratici. Se un malware mantiene il controllo diretto del computer, può continuare a lavorare in locale usando la sessione autentica presente sulla macchina. In quel caso il problema non è più spostare il cookie altrove, ma il fatto stesso che l’attaccante sia dentro il dispositivo.
C’è poi un altro aspetto. Gli infostealer moderni non si limitano ai cookie: nei bottini finiscono spesso password salvate, indirizzi email, dati personali, chiavi SSH, configurazioni VPN, token cloud e tanto altro materiale sensibile. Va considerata anche la compatibilità: l’adozione piena di DBSC richiede che i servizi web e i fornitori di identità la supportino. Google ha collaborato con realtà come Okta durante i test, ma ci vorrà tempo prima che l’intero settore si adegui.
Per capire se la propria copia di Chrome supporta già la funzione conviene distinguere tra supporto del browser e adozione da parte del sito. Dato per presente il chip TPM, digitando chrome://flags e cercando DBSC dovrebbe comparire l’impostazione per forzare l’attivazione della protezione dei cookie. Nelle versioni più recenti questo flag potrebbe sparire, perché la funzione viene integrata di default. DBSC non aggiunge cookie speciali facili da riconoscere con gli strumenti standard, dato che tutto ruota attorno a uno scambio crittografico tra browser e server. Il metodo più affidabile resta usare gli Strumenti per sviluppatori premendo F12, aprire la sezione Network e ricaricare la pagina di login: lì si possono cercare richieste con intestazioni come Sec-Session-Google o riferimenti a Session-Binding. In alternativa c’è chrome://net-export, che registra il traffico in locale, poi analizzabile con Netlog Viewer cercando termini come devicebound, dbsc o bound_session. Tutto resta sul computer, niente viene caricato altrove, e se il sito sfrutta DBSC compaiono eventi legati alla creazione o all’uso delle credenziali vincolate al dispositivo.