Di cosa si tratta è l'archiviazione lato client.
La prima premessa è che tutto questo avvenga in una sessione SSL, quindi questo non verrà intercettato da terze parti. L'attaccante rimanente, se presente, è l'utente stesso. In particolare, solo l'utente effettivo può restituire il valore del cookie al server.
Quindi il server vuole gestire sessioni , cioè considerare le richieste successive dallo stesso client come parte di un'intera "storia". Ciò implica che il server deve ricordare informazioni sulla sessione da una richiesta alla successiva.
La memoria lato server implica due problemi principali:
-
La quantità di spazio di archiviazione sul server può aumentare notevolmente. In effetti, le richieste successive da un determinato client possono verificarsi con un ritardo piuttosto ampio nel mezzo (minuti, anche ore o più). Inoltre, un determinato client può interrompere completamente l'invio di richieste e il server non verrà avvisato. Quindi, su un server occupato, stiamo parlando di salvare decine di migliaia o più di oggetti "informazioni di sessione". Questo può tradursi in un numero non trascurabile di megabyte di RAM.
-
Se il server è multi-front-end, le informazioni sulla sessione utente devono essere condivise tra i frontend, il che implica alcune comunicazioni extra, spesso con un database condiviso, che a sua volta può implicare problemi di prestazioni (un database non è veloce come RAM locale pura).
Quindi sarebbe bello se le informazioni sulla sessione utente potessero essere memorizzate sul client stesso. Questo è ciò di cui tratta lo schema cookie + encryption + MAC. Il server racchiude ciò che vuole ricordare su una sessione utente in un blob che viene inviato al client; è quindi compito del cliente rispedirlo con la richiesta successiva. Il server non memorizza nulla sul suo lato. Questo si adatta bene a milioni di utenti e dozzine di frontend, dal momento che il server non deve ricordare nulla. Implica, tuttavia, le proprie sfide:
- Poiché i dati sono archiviati sul client, il client può ispezionarli, il che non è necessariamente una buona cosa. La crittografia risolve il problema.
- Poiché i dati sono memorizzati sul client, il client può modificarlo, il che non è necessariamente una buona cosa. MAC risolve quello.
- Poiché il server non ricorda nulla, non può impedire attacchi di replay dove il client invia nuovamente un vecchio valore del cookie. Includendo una data (sotto la protezione del MAC) attenua questo problema.
- Le dimensioni dei cookie sono tradizionalmente limitate a circa 4 kilobyte, quindi il server non sarà in grado di fare in modo che il client memorizzi molti più dati (beh, il server potrebbe inviare diversi cookie, ma riassemblare diventa difficile, specialmente se vuoi farlo in sicurezza).
Il nome utente, l'identificativo di sessione SSL o l'indirizzo IP, è solo un identificatore non segreto che ha lo scopo di impedire a diversi utenti di scambiare i loro cookie, volontariamente o meno. Per questo, l'indirizzo IP non è un buon identificatore, perché molti utenti potrebbero condividere lo stesso IP (in caso di NAT o l'uso di un proxy Web) e l'indirizzo IP di un dato utente potrebbero cambiare (IP dinamico non è raro).
Ora lo schema specifico spiegato nella risposta SO può essere discutibile; per esempio. applica il MAC sui dati in chiaro, non sui dati crittografati, che è noto per ha potenziali problemi : questo è noto come" encrypt-and-MAC ". I potenziali problemi possono essere evitati, ma ciò richiede un po 'di attenzione nell'implementazione, quindi "encrypt-then-MAC" dovrebbe essere preferito. Anche il riutilizzo della stessa chiave per la crittografia e il MAC è, in senso generico, una brutta mossa; anche se sembra abbastanza sicuro quando il MAC è HMAC e la crittografia usa un codice a blocchi, lo preferiamo davvero quando le due chiavi sono in qualche modo isolate l'una dall'altra. Un modo moderno e più ovviamente sicuro per fare crittografia e MAC sarebbe utilizzare una delle modalità di crittografia che sono state progettate per fare esattamente questo, ad es. GCM o EAX .
L'idea è ancora valida (a condizione che tutto ciò avvenga sotto la protezione di SSL). Il principale problema rimasto riguarda gli attacchi di replay, che, a seconda dell'applicazione, possono o non possono essere seri; l'inclusione della data nei dati dei cookie consente al server di applicare una strategia di scadenza esplicita per controllare questo problema.