Le credenziali di sessione associate al dispositivo (DBSC) rafforzano l'autenticazione aggiungendo la sicurezza della sessione basata sull'hardware.
Introduzione
Molti siti web si basano su cookie a lungo termine per l'autenticazione degli utenti, ma questi sono vulnerabili al furto di sessione. Le credenziali di sessione associate al dispositivo (DBSC) aggiungono un livello di sicurezza basata sull'hardware per ridurre questo rischio, garantendo che le sessioni siano associate a dispositivi specifici.
Questa guida è rivolta agli sviluppatori che gestiscono i flussi di autenticazione nelle applicazioni web. Spiega come funziona il DBSC e come integrarlo nel tuo sito.
Come funzionano le credenziali di sessione associate al dispositivo
A un livello generale, DBSC introduce una coppia di chiavi crittografiche associata al dispositivo dell'utente. Chrome genera questa coppia di chiavi durante l'accesso e memorizza 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 di possedere la chiave privata prima di aggiornarli. Questa procedura collega la continuità della sessione al dispositivo originale.
Se il dispositivo di un utente non supporta la memorizzazione sicura delle chiavi, DBSC passa gradualmente 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 in modo da includere un'intestazione
Sec-Session-Registration. - Aggiungi un endpoint di registrazione della sessione che:
- Associa una chiave pubblica alla sessione dell'utente.
- Gestisce la configurazione della sessione.
- Transizioni a cookie di breve durata.
- Aggiungi un endpoint di aggiornamento per gestire il rinnovo dei cookie e la convalida del possesso della chiave.
La maggior parte degli endpoint esistenti non richiede modifiche. DBSC è progettato per essere aggiuntivo 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 continuerà a utilizzare i consueti controlli dei cookie di sessione per confermare che l'utente ha eseguito l'accesso. Poiché corrisponde ai flussi di autenticazione tipici, DBSC funziona con modifiche minime alla logica di accesso.
Procedura di implementazione
Questa sezione illustra le modifiche necessarie al sistema di autenticazione, incluso come modificare il flusso di accesso, gestire la registrazione della sessione e gestire gli aggiornamenti dei cookie di breve durata. Ogni passaggio è progettato per integrarsi perfettamente con la tua infrastruttura esistente.
I passaggi di implementazione seguono il flusso comune che un utente che ha eseguito l'accesso deve seguire quando la funzionalità DBSC è attiva: registrazione al momento dell'accesso, seguita da regolari aggiornamenti 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.
1. Modificare il flusso di accesso
Dopo che l'utente ha eseguito l'accesso, rispondi con un cookie a lunga durata e un Sec-Session-Registration header. Ad esempio:
La seguente intestazione di risposta HTTP viene restituita dopo la registrazione della sessione:
HTTP/1.1 200 OK
Sec-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 la memorizzazione sicura delle chiavi, Chrome contatta l'endpoint /StartSession con una chiave pubblica in un token web JSON (JWT).
Il token 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
A /StartSession, il server dovrebbe:
- Associa la chiave pubblica ricevuta alla sessione dell'utente.
- Rispondi con una configurazione della sessione.
- Sostituisci il cookie a lungo termine con uno a breve termine.
Nell'esempio seguente, il cookie di breve durata è configurato per scadere dopo 10 minuti:
HTTP/1.1 200 OK
Set-Cookie: auth_cookie=short_lived_grant; Max-Age=600; # Expires after 10 minutes Set-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 di possedere la chiave privata. Questa procedura prevede azioni coordinate sia da parte di Chrome sia del tuo server:
Chrome rimanda la richiesta dell'utente alla tua applicazione e invia una richiesta di aggiornamento a
/RefreshEndpoint:POST /RefreshEndpoint HTTP/1.1 Sec-Session-Id: session_idIl server risponde con una verifica:
HTTP/1.1 401 Unauthorized Sec-Session-Challenge: "challenge_value"Chrome firma la verifica utilizzando la chiave privata memorizzata e riprova a effettuare la richiesta:
POST /RefreshEndpoint HTTP/1.1 Sec-Session-Id: session_id Sec-Session-Response: <JWT proof>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=LaxChrome riceve il cookie aggiornato e riprende la richiesta differita originale.
Modello di integrazione alternativo
Per migliorare la resilienza, i siti possono aggiungere un secondo cookie non DBSC insieme al cookie di breve durata. Questo cookie a lungo termine viene utilizzato solo per emettere nuovi token a breve termine e consente di distinguere le richieste non autenticate da quelle autentiche e gli errori temporanei del DBSC.
- Il cookie a lungo termine persiste anche se la funzionalità DBSC non va a buon fine.
- Il cookie di breve durata viene aggiornato utilizzando DBSC ed è obbligatorio per le operazioni sensibili.
Questo pattern offre ai siti un maggiore controllo su come gestire i casi limite.
Limitazioni e comportamento di riserva
Chrome potrebbe saltare le operazioni di 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, gli 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 a lungo termine, se è ancora presente. Questo valore alternativo funziona solo se l'implementazione include sia un cookie a lungo termine sia uno a breve termine. 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 alla tua applicazione. Offrono protezioni più efficaci contro il furto di sessioni collegando le sessioni a dispositivi specifici. La maggior parte degli utenti ne trae vantaggio senza subire alcuna interruzione e DBSC esegue il passaggio a un hardware non supportato in modo corretto.
Per ulteriori informazioni, consulta la specifica DBSC.