Credenziali di sessione associate al dispositivo (DBSC)

Le credenziali di sessione associate al dispositivo (DBSC) rafforzano l'autenticazione aggiungendo la sicurezza della sessione supportata dall'hardware.

Daniel Rubery
Daniel Rubery
José Luis Zapata

Introduzione

Molti siti web si basano su cookie di lunga durata per l'autenticazione degli utenti, ma questi sono suscettibili di attacchi di sessione. Le credenziali di sessione vincolate al dispositivo (DBSC) aggiungono un livello di sicurezza basato su hardware per mitigare questo rischio, garantendo che le sessioni siano vincolate a dispositivi specifici.

Questa guida è rivolta agli sviluppatori che gestiscono i flussi di autenticazione nelle applicazioni web. Spiega come funziona DBSC e come integrarlo nel tuo sito.

Come funziona DBSC

A livello generale, DBSC introduce una coppia di chiavi crittografiche associata al dispositivo dell'utente. Chrome genera questa coppia di chiavi durante l'accesso e archivia la chiave privata in hardware sicuro, ad esempio un Trusted Platform Module (TPM), se disponibile. Le sessioni utilizzano cookie di breve durata. Quando uno di questi cookie scade, Chrome dimostra il possesso della chiave privata prima di aggiornarli. Questo processo collega la continuità della sessione al dispositivo originale.

Se il dispositivo di un utente non supporta l'archiviazione sicura delle chiavi, le credenziali di sessione associate al dispositivo tornano al comportamento standard senza interrompere il flusso di autenticazione.

Panoramica dell'implementazione

Per integrare DBSC nella tua applicazione, devi apportare le seguenti modifiche:

  • Modifica il flusso di accesso per includere un'intestazione Secure-Session-Registration.
  • Aggiungi un endpoint di registrazione della sessione che:
    • Associa una chiave pubblica alla sessione dell'utente.
    • Fornisce la configurazione della sessione.
    • Transizioni ai cookie di breve durata.
  • Aggiungi un endpoint di aggiornamento per gestire il rinnovo dei cookie e la convalida del possesso delle chiavi.

La maggior parte degli endpoint esistenti non richiede modifiche. DBSC è progettato per essere additivo e non di disturbo.

Quando un cookie temporaneo obbligatorio non è presente o è scaduto, Chrome mette in pausa la richiesta e tenta di aggiornare il cookie. In questo modo, la tua app può continuare a utilizzare i normali controlli dei cookie di sessione per confermare l'accesso dell'utente. Poiché corrisponde ai flussi di autenticazione tipici, DBSC funziona con modifiche minime alla logica di accesso.

Procedura di implementazione

Questa sezione descrive le modifiche necessarie al sistema di autenticazione, inclusi come modificare il flusso di accesso, gestire la registrazione delle sessioni e gestire i aggiornamenti dei cookie di breve durata. Ogni passaggio è progettato per integrarsi facilmente con l'infrastruttura esistente.

I passaggi di implementazione seguono il flusso comune che un utente con accesso eseguito sperimenterebbe quando DBSC è attivo: registrazione all'accesso, seguita da aggiornamenti regolari dei cookie di breve durata. Puoi testare e implementare ogni passaggio in modo indipendente, a seconda del livello di sensibilità della sessione della tua app.

Diagramma che mostra il flusso DBSC

1. Modifica del flusso di accesso

Dopo che l'utente ha eseguito l'accesso, rispondi con un cookie di lunga durata e un'intestazione Secure-Session-Registration. Ad esempio:

Dopo la registrazione della sessione, viene restituita la seguente intestazione della risposta HTTP:

HTTP/1.1 200 OK
Secure-Session-Registration: (ES256 RS256); path="/StartSession"
Set-Cookie: auth_cookie=session_id; max-age=2592000; Domain=example.com; Secure; SameSite=Lax

Se il dispositivo supporta l'archiviazione sicura delle chiavi, Chrome contatta l'endpoint /StartSession con una chiave pubblica in un token web JSON (JWT).

auth_cookie in questo esempio rappresenta il token di sessione. Puoi assegnare a questo cookie il nome che preferisci, purché corrisponda al campo name nella configurazione della sessione e venga utilizzato in modo coerente in tutta l'applicazione.

2. Implementa l'endpoint di registrazione della sessione

In /StartSession, il server deve:

  • Associa la chiave pubblica ricevuta alla sessione dell'utente.
  • Rispondi con una configurazione della sessione.
  • Sostituisci il cookie di lunga durata con uno di breve durata.

Nell'esempio seguente, il cookie di breve durata è configurato per scadere dopo <x0A>10 minuti:

HTTP/1.1 200 OK
Set-Cookie: auth_cookie=short_lived_grant; Max-Age=600; # Expires after 10 minutesSet-Cookie: Domain=example.com; Secure; SameSite=Lax

{
  "session_identifier": "session_id",
  "refresh_url": "/RefreshEndpoint",
  "scope": {
    "origin": "https://example.com",
    "include_site": true,
    "scope_specification": [
      { "type": "exclude", "domain": "*.example.com", "path": "/static" }
    ]
  },
  "credentials": [{
    "type": "cookie",
    "name": "auth_cookie",
    "attributes": "Domain=example.com; Secure; SameSite=Lax"
  }]
}

3. Implementa l'endpoint di aggiornamento

Quando il cookie di breve durata scade, Chrome avvia un flusso di aggiornamento per dimostrare il possesso della chiave privata. Questa procedura prevede azioni coordinate sia da Chrome sia dal tuo server:

  1. Chrome posticipa la richiesta dell'utente alla tua applicazione e invia una richiesta di aggiornamento a /RefreshEndpoint:

    POST /RefreshEndpoint HTTP/1.1
Sec-Secure-Session-Id: session_id

  2. Il server risponde con una richiesta di verifica:

    HTTP/1.1 403 Forbidden
Secure-Session-Challenge: "challenge_value"

  3. Chrome firma la richiesta di verifica utilizzando la chiave privata archiviata e riprova a inviare la richiesta:

    POST /RefreshEndpoint HTTP/1.1
Sec-Secure-Session-Id: session_id
Secure-Session-Response: <JWT proof>

  4. Il server convalida la prova firmata ed emette un cookie di breve durata aggiornato:

    HTTP/1.1 200 OK

Set-Cookie: auth_cookie=short_lived_grant; Max-Age=600; Domain=example.com; Secure; SameSite=Lax

  5. Chrome riceve il cookie aggiornato e riprende la richiesta originale posticipata.

Pattern di integrazione alternativo

Per migliorare la resilienza, i siti possono aggiungere un secondo cookie non DBSC insieme al cookie di breve durata. Questo cookie di lunga durata viene utilizzato solo per emettere nuovi token di breve durata e aiuta a distinguere tra richieste non autenticate e errori temporanei di DBSC.

  • Il cookie di lunga durata persiste anche se DBSC non funziona.
  • Il cookie di breve durata viene aggiornato utilizzando DBSC ed è necessario per le operazioni sensibili.

Questo pattern offre ai siti un maggiore controllo su come gestire i casi limite.

Avvertenze e comportamento di fallback

Chrome potrebbe ignorare le operazioni DBSC e inviare richieste senza il cookie di breve durata gestito da DBSC nei seguenti scenari:

  • L'endpoint di aggiornamento non è raggiungibile a causa di errori di rete o problemi del server.
  • Il TPM è occupato o si verificano errori di firma. Poiché il TPM è condiviso tra i processi di sistema, aggiornamenti eccessivi potrebbero superare i limiti di frequenza.
  • Il cookie di breve durata gestito da DBSC è un cookie di terze parti e l'utente ha bloccato i cookie di terze parti nelle impostazioni del browser.

In queste situazioni, Chrome torna a utilizzare il cookie persistente, se ancora presente. Questo fallback funziona solo se la tua implementazione include sia un cookie persistente sia un cookie temporaneo. In caso contrario, Chrome invia la richiesta senza un cookie.

Riepilogo

Le credenziali di sessione associate al dispositivo migliorano la sicurezza della sessione con modifiche minime all'applicazione. Offrono una protezione più efficace contro la compromissione delle sessioni associando le sessioni a dispositivi specifici. La maggior parte degli utenti trae vantaggio senza riscontrare interruzioni e DBSC esegue il fallback in modo controllato sull'hardware non supportato.

Per saperne di più, consulta le specifiche DBSC.