Sì, è possibile.
Se i token sono generati dal server creando una sequenza casuale protetta da crittografia memorizzata sull'account, questo token potrebbe essere aggiornato e riemesso in un determinato intervallo, invalidando quello precedente.
Il token verrà aggiornato solo in caso di utilizzo attivo, pertanto non invaliderà quello vecchio quando il computer client è spento. Questo approccio garantisce che un cookie copiato abbia solo un tempo limitato per essere riutilizzato, limitando l'esposizione dell'attacco. Nel caso in cui l'attaccante utilizzi il cookie in tempo, la sessione originale sarebbe scaduta e l'utente reale verrebbe disconnesso (a seconda di come è impostato l'intervallo). Potrebbe essere visualizzato un messaggio che l'account viene utilizzato altrove, avvisando l'utente dell'attacco.
Se l'attaccante ha comunque accesso permanente e può prendere qualsiasi nuovo identificatore, ha già vinto. Quanto sopra protegge solo contro un singolo furto del gettone. Ad esempio se l'utente ha lasciato lo schermo sbloccato e l'autore dell'attacco ha avuto accesso fisico e solo il tempo necessario per rubare il valore del cookie, o se il valore è stato rubato tramite un attacco XSS riflesso, che è l'esecuzione del codice nel browser e l'attacco non può essere ripetuto facilmente.
Un utente malintenzionato con accesso root potrebbe tuttavia non essere in grado di accedere a un normale cookie dell'utente. Chrome crittografa i cookie quando vengono salvati su disco, consentendo solo all'utente corrente di decrittografarli poiché la chiave deriva dalla loro password. Pertanto un attacco ai token nei cookie sarebbe più difficile.
