Perché il valore del cookie dovrebbe essere crittografato?

Bene, immagino che se l'informazione è segreta potrebbe essere per proteggere i dati "a riposo". Ciò potrebbe essere contro utenti legittimi del PC o contro le persone che ottengono una copia del PC.

Generalmente i cookie dovrebbero essere protetti dal cambiamento (integrità), piuttosto che offrire riservatezza. Questo può tuttavia essere eseguito posizionando un valore MAC sul cookie anziché crittografarlo.

A volte le persone stanno crittografando un valore magico (presepe) invece di posizionare un MAC, quindi potrebbe essere un caso di eseguire la crittografia fai-da-te.

Per rispondere in modo specifico alla tua domanda, la crittografia dei dati casuali non ha valore a meno che tu non stia utilizzando entrambi i crittografati e i dati non crittografati. Ad esempio, uno può essere memorizzato nel database del server , mentre l'altro viene pubblicato nel cookie . Tuttavia, un approccio migliore consiste nell'utilizzare un hash unidirezionale anziché crittografato. Descriverò questo di seguito.

Ecco alcune linee guida per la gestione sicura dei cookie dei token di sessione:

Innanzitutto, assicurati che il cookie sia contrassegnato come Secure e HttpOnly e che abbia almeno 72 bit di entropia da un PSRNG crittograficamente sicuro .

Quindi, poiché la connessione è protetta con HTTPS, l'unico modo in cui il cookie verrebbe rubato è un attacco sul lato server (SQLi, ecc.) o un attacco sul lato client (ad esempio un virus sul PC). In entrambi i casi è probabilmente già un serio problema . Ma a volte con questi attacchi, l'autore dell'attacco riceverà solo una quantità limitata di dati. Il solo dirottamento di un token di sessione potrebbe essere un vero risparmio di tempo per l'attaccante, anche se sono possibili anche altri attacchi. Quindi, in alcuni casi uno schema di gestione dei cookie token di sessione ben protetto può fare una grande differenza.

Se il token di sessione è rubato dal client , non puoi fare molto . Mi piace bloccare ogni sessione su un singolo indirizzo IP ma non è accettabile per gli utenti mobili.

Tuttavia, supponendo che i token di sessione siano stati rubati dal server (ad esempio un attacco SQLi di sola lettura), puoi contribuire a mitigarlo in base alla progettazione. Nel database del server, memorizza solo un hash SHA-2 del token. In questo modo l'utente malintenzionato non può riconvertirlo in un valore del cookie utilizzabile. Ovviamente tali attacchi sono ancora gravi problemi per altri motivi, almeno ti sei assicurato con successo contro questo tipo di dirottamento di sessione.

Nel complesso, l'applicazione deve essere protetta contro XSS e SQLi, naturalmente.

Dipende se il cookie contiene informazioni importanti che consentirebbero all'utente di ottenere informazioni a cui non dovrebbe avere accesso.

Supponiamo di avere un sito quando all'accesso imposta un cookie admin con un valore vero / falso che descrive se l'utente è un amministratore e quando accede a pagine riservate il valore di questo cookie determina se l'utente ha accesso.

Crittografia e autenticazione (MAC) il cookie impedirebbe all'utente di alterarlo con successo.

Allo stesso modo la maggior parte dei framework web consente di memorizzare l'intero dato di sessione in un cookie, in tal caso non si desidera che l'utente sia in grado di modificare i dati in modo tale che sia necessario autenticarlo e poiché la sessione potrebbe contenere dati all'utente non dovrebbe essere in grado di vederti criptare anche.

Oh d'altra parte se i cookie sono usati solo per cose che appartengono all'utente in primo luogo (cookie di sessione, ecc.) o se sono usati dal lato client solo allora non ha senso crittografarlo / autenticarlo.