Perché Tornado non ha sessione

I've heard that cookies is less secure than the session.

Devi aver frainteso qualcosa. In realtà le sessioni HTTP vengono solitamente implementate utilizzando i cookie.

I'm thinking that if I could get &^*Y()UIH|>Guho976879, I can still forge the cookie, right?

Sicuro di poter cambiare il cookie, ma sarà accettato dal server come valido? Se prendi una documentazione reale vedrai:

Cookies are not secure and can easily be modified by clients. If you need to set cookies to, e.g., identify the currently logged in user, you need to sign your cookies to prevent forgery. Tornado supports signed cookies with the set_secure_cookie and get_secure_cookie methods. ...
Signed cookies contain the encoded value of the cookie in addition to a timestamp and an HMAC signature. If the cookie is old or if the signature doesn’t match, get_secure_cookie will return None just as if the cookie isn’t set.

Pertanto, se cerchi di manipolare il cookie sicuro, il framework noterà e considererà il cookie non valido, ad esempio il cookie non è mai stato inviato in primo luogo.

Penso che le altre risposte non riescano ad affrontare l'attacco principale che viene protetto da qui, che non è forgiando il cookie, ma manomissione con esso, o > ispezionarlo .

Se si invia un cookie a un browser che dice "current_user = tom", l'utente può restituire un cookie alternativo che dice "current_user = dave". Se non hai nulla per convalidare il cookie, la tua applicazione supporrà che sia loggato come "dave".

Questo potrebbe essere mitigato da firmare il cookie utilizzando una chiave segreta - il cookie manomesso non avrebbe la firma corretta, quindi verrebbe rifiutato.

Tuttavia, potrebbe esserci ancora un problema: se parte dello stato che vuoi memorizzare è secret . Ad esempio, potresti voler memorizzare il prezzo di costo e il markup dei prodotti nel carrello dell'utente; chiaramente un cookie in chiaro che l'utente può leggere non è appropriato qui.

Questo ti lascia con due soluzioni:

• Encrypt il contenuto del cookie, in modo che non possa essere né letto né modificato senza conoscere la chiave privata.
• Archivia i dati effettivi localmente (ad esempio in un disco o in un archivio di memoria) e invia solo un identificatore nel cookie. Questo è generalmente noto come "dati di sessione".

Le sessioni sono relativamente facili da implementare e sono sicure contro questi attacchi particolari. Tuttavia, impongono oneri all'infrastruttura di back-end, perché i server Web / delle applicazioni devono essere in grado di scrivere e leggere i dati; questo può essere complicato in configurazioni di bilanciamento del carico complesse, per esempio. Pertanto, la crittografia di una piccola quantità di dati direttamente nel cookie può essere un'alternativa ragionevole, poiché ora gli unici dati che devono essere condivisi tra i server delle applicazioni è la chiave privata.

Nota che nessuno di questi protegge direttamente contro altri attacchi, come il dirottamento, in cui un utente malintenzionato clona semplicemente i cookie da una sessione autentica. I token di sessione possono anche essere vulnerabili a un attacco correlato chiamato "fissazione di sessione", in cui un utente malintenzionato sceglie l'identificativo prima che un utente reale si colleghi e può quindi creare cookie identici a loro; questo non sarebbe possibile con un cookie crittografato, ma sono sicuro che ci sono altri attacchi esclusivi a sua volta.

La domanda che hai trovato non descrive realmente a cosa (penso) ti riferisci. La differenza che stanno descrivendo è se le informazioni sulla sessione dell'utente (quindi cose come quello che si trova nella loro basked shopping ad esempio) lato server e solo passare un identificatore univoco (aka cookie di sessione) al client, o se memorizzare l'intera cosa sul client.

Tutte le applicazioni web devono avere un meccanismo di mantenimento dello stato. HTTP è stateless per impostazione predefinita, quindi non è possibile che un server corrisponda a una richiesta a un'altra.

Il modo in cui la maggior parte delle applicazioni risolve questo è usare i cookie. I problemi di sicurezza legati all'utilizzo dei cookie sono ben compresi e, se correttamente implementati, non dovrebbero causare problemi di sicurezza significativi.

Le altre opzioni per farlo sono in genere le intestazioni delle autorizzazioni, quindi utilizzando il digest HTTP o l'autenticazione NTLM. che è più comune nelle applicazioni aziendali interne o per generare quelle intestazioni utilizzando JavaScript (che si vedono con alcune moderne applicazioni a pagina singola).

Indipendentemente da ciò, è necessario che alcune informazioni passino da client a server con ciascuna richiesta per identificare l'utente.

Per quanto riguarda i falsi cookie, di solito un token di sessione avrà un ampio grado di casualità quindi non è pratico creare un valore per il cookie.