Cookie al sicuro con DBSC: Cos’è e come funziona il Device Bound Session Credentials di Google

Pubblicato da

  

Nel panorama della cybersecurity, c'è una minaccia silenziosa che negli ultimi anni ha messo in ginocchio milioni di utenti e aziende: il session hijacking (o furto di cookie). Malware specializzati, chiamati infostealer, sono in grado di penetrare nei computer, copiare i cookie di sessione dai browser e inviarli ad attaccanti remoti. Questi ultimi, clonando i cookie sul proprio PC, possono accedere ai conti bancari, alle e-mail o ai pannelli aziendali della vittima, aggirando completamente le password e persino l'autenticazione a due fitness (MFA).

Per porre fine a questa vulnerabilità strutturale del web, Google ha introdotto una tecnologia rivoluzionaria: il Device Bound Session Credentials (DBSC). Vediamo nel dettaglio cos'è, come funziona dal punto di vista logico e tecnico, e quando potrai utilizzarlo.

🔗 Ti piace Techelopment? Dai un'occhiata al sito per tutti i dettagli!

1. Che cos'è il DBSC?

Il DBSC è un nuovo protocollo di sicurezza (sviluppato in seno al W3C) il cui obiettivo è legare indissolubilmente una sessione web al dispositivo fisico su cui è stata creata.

Invece di affidarsi ai classici cookie che si comportano come "titoli al portatore" (chiunque li possiede può usarli), il DBSC trasforma il cookie in una chiave inutile se spostata al di fuori del computer legittimo. Se un malware copia il cookie di sessione protetto da DBSC e lo invia a un hacker dall'altra parte del mondo, l'hacker non potrà comunque accedere all'account.

Il problema che DBSC risolve: L'inefficacia dell'MFA contro gli Infostealer

Fino ad oggi, la migliore difesa per proteggere un account è stata l'Autenticazione a Due Fattori (MFA o 2FA). Tuttavia, l'MFA interviene esclusivamente durante la fase di login. Una volta che l'utente ha inserito correttamente password e codice OTP, il server web genera un cookie di sessione che viene salvato nel browser. Da quel momento in poi, quel cookie rappresenta il "pass di accesso" definitivo: per tutta la durata della sessione, l'utente non dovrà più reinserire le credenziali.

È qui che entrano in gioco i malware di tipo infostealer (come RedLine o Lumma). Questi programmi malevoli non hanno bisogno di rubare la tua password o intercettare il tuo codice OTP. Si limitano a copiare i cookie di sessione già attivi direttamente dai file del browser salvati sul disco fisso.

Una volta che l'attaccante ottiene questi cookie, li importa nel proprio browser e "clona" l'identità della vittima. Per il server web, l'attaccante è l'utente legittimo, poiché esibisce un pass già autorizzato dall'MFA. Il DBSC risolve alla radice proprio questo problema: rende i cookie completamente inutilizzabili se vengono estratti dall'hardware del computer originario, neutralizzando l'intero modello di business degli infostealer.

Puoi approfondire in questo video come funziona il session hijacking.


2. Come funziona DBSC a livello logico (la metafora del passaporto)

Per capire la logica del DBSC, immaginiamo la differenza tra un biglietto del cinema e un passaporto:

  • Il vecchio sistema (Cookie tradizionale): Funziona come un biglietto del cinema. Se lo compri, lo metti in tasca e qualcuno te lo ruba, il ladro può presentarsi all'ingresso del cinema ed entrare al posto tuo. Il controllore guarda solo se il biglietto è valido, non chi lo possiede.
  • Il nuovo sistema (DBSC): Funziona come un passaporto biometrico abbinato a un controllo doganale continuo. Quando accedi a un sito, il browser non riceve solo un "biglietto" (il cookie), ma genera un legame crittografico unico con l'hardware del tuo computer. Il sito, a intervalli regolari, chiede al browser: "Sei ancora sul computer di prima? Dimostramelo". Solo il tuo PC possiede l'hardware in grado di rispondere correttamente. Il ladro con il cookie rubato fallirà il controllo.

3. Come funziona DBSC a livello tecnico e informatico

A livello di infrastruttura software e hardware, il DBSC sposta la sicurezza dal livello applicativo (il solo browser) al livello hardware (il chip del computer).

Il processo si articola in tre macro-fasi:

A. La Registrazione (Fase di Login)

  1. L'utente effettua il login inserendo password e MFA su un sito web compatibile.
  2. Il server del sito risponde inviando un header HTTP specifico (Secure-Session-Registration).
  3. Ricevuto l'header, Google Chrome comanda al chip di sicurezza del computer (es. il TPM su Windows) di generare una coppia di chiavi crittografiche (Pubblica/Privata) specifica per quel sito.
  4. Il browser invia la chiave pubblica al server del sito e mantiene la chiave privata blindata all'interno del chip hardware. La chiave privata non può essere esportata né letta da alcun malware.

B. Il Mantenimento (i Cookie a breve scadenza)

Per evitare di appesantire il chip hardware a ogni singolo clic sulla pagina, il sito emette comunque dei cookie di sessione tradizionali, ma con una differenza fondamentale: hanno una durata brevissima.

C. La Sfida (il Refresh)

Quando il cookie a breve scadenza sta per scadere, entra in gioco il DBSC:

  1. Chrome contatta un endpoint di refresh sul server del sito.
  2. Il server invia una "sfida" (un codice univoco chiamato nonce).
  3. Chrome firma digitalmente questa sfida utilizzando la chiave privata custodita nel chip hardware del PC.
  4. Il server riceve la firma, la verifica con la chiave pubblica memorizzata al momento del login e, se valida, emette un nuovo cookie a breve scadenza.
Il blocco del malware: Se un malware installato sul PC copia il cookie a breve scadenza e lo invia all'attaccante, l'attaccante potrà usarlo solo per pochissimi minuti. Non appena il sito chiederà di firmare la "sfida" per rinnovare il cookie, l'attaccante fallirà perché non possiede il chip hardware della vittima contenente la chiave privata.


4. Requisiti e compatibilità: da quali versioni è supportato?

Il rilascio del DBSC sta avvenendo in modo graduale ma deciso, partendo dagli ecosistemi aziendali per poi estendersi a tutti gli utenti globali.

Componente Requisito Minimo / Stato del Supporto Note Tecniche
Google Chrome (Windows) Disponibile (General Availability) a partire da Chrome 145 / 146 Attivo di default per tutti gli utenti (inclusi account Google personali e Workspace).
Google Chrome (macOS) In arrivo Supporto annunciato e in fase di implementazione.
Sistemi Operativi PC Windows 10 / 11 con chip TPM 2.0 attivo. Il DBSC richiede il Trusted Platform Module hardware per blindare le chiavi.
Sistemi Operativi Mac Sistemi macOS dotati di chip Apple Silicon o Intel con Secure Enclave. Sfrutterà l'architettura di sicurezza nativa di Apple.
Altri Browser Sotto valutazione / In sviluppo Trattandosi di una proposta di standard aperto (W3C), anche Microsoft Edge, Mozilla Firefox e Safari stanno valutando l'implementazione nei rispettivi motori.


5. Cosa deve fare l'utente?

Assolutamente nulla. Se utilizzi una versione recente di Windows 11 o Windows 10 con TPM attivo e tieni aggiornato Google Chrome, la tecnologia lavora in background per te. I grandi provider di servizi (come Google Workspace) hanno già iniziato a proteggere le sessioni dei propri utenti in modo del tutto trasparente, garantendo una navigazione incredibilmente più sicura senza sacrificare la comodità d'uso quotidiana.


Riferimenti



Follow me #techelopment

Official site: www.techelopment.it
facebook: Techelopment
instagram: @techelopment
X: techelopment
Bluesky: @techelopment
telegram: @techelopment_channel
whatsapp: Techelopment
youtube: @techelopment