it-swarm.dev

Cookie di sessione sicuri

Durante la ricerca di metodi per la creazione di cookie di sessione sicuri mi sono imbattuto in questa pubblicazione: A Secure Cookie Protocol . Propone la seguente formula per un cookie di sessione:

cookie = user | expiration | data_k | mac

dove

  • | Indica la concatenazione.
  • user è il nome utente del client.
  • expiration è il tempo di scadenza del cookie.
  • data_k Sono i dati crittografati associati al client (come un ID sessione o informazioni sul carrello) crittografati utilizzando la chiave k.
    • k deriva da una chiave del server privato sk; k = HMAC(user | expiration, sk).
    • data_k Potrebbe essere crittografato usando AES usando la chiave k.
  • mac è un HMAC del cookie per verificare l'autenticità del cookie; mac = HMAC(user | expiration | data | session-key, k).
    • data sono i dati non crittografati associati al client.
    • session-key È la chiave di sessione SSL.
  • HMAC è HMAC-MD5 o HMAC-SHA1.

Secondo il documento, fornisce la riservatezza dei cookie e previene la riproduzione e gli attacchi di volume. Per me (essere un dilettante in sicurezza/crittografia) questo sembra abbastanza buono. Quanto è buono questo metodo per i cookie di sessione o i cookie in generale?

35
user369450

Sì, sembra un ottimo schema per proteggere i cookie.

Un altro schema più recente in quest'area è SCS: Secure Cookie Sessions for HTTP , che è uno schema solido, molto ben pensato. Consiglio di leggere la discussione sulla sicurezza di quel documento per avere un'idea di quali potrebbero essere le minacce alla sicurezza.

Per aiutare a comprendere lo scopo e il ruolo dello schema dei cookie che menzioni, fammi fare un backup e fornisci un contesto. È comune che le applicazioni Web debbano mantenere lo stato della sessione: ad esempio, alcuni stati la cui durata è limitata alla sessione corrente e che sono associati alla sessione corrente. Esistono due modi per mantenere lo stato della sessione:

  1. Memorizza lo stato della sessione sul server. Il web server fornisce al browser un cookie di sessione: un cookie il cui unico scopo è contenere una stringa di bit grande, non indicabile che funge da identificatore di sessione. Il server mantiene una tabella di ricerca, con una voce per sessione aperta, che esegue il mapping dall'identificatore di sessione a tutto lo stato della sessione associato a questa sessione. Ciò semplifica il recupero e l'aggiornamento del codice dell'applicazione Web da parte di una specifica richiesta HTTP/HTTPS. La maggior parte dei framework di applicazioni Web fornisce supporto integrato per la memorizzazione dello stato della sessione sul lato server.

    Questo è il modo più sicuro per memorizzare lo stato della sessione. Poiché lo stato della sessione è archiviato sul server, il client non ha accesso diretto ad esso. Pertanto, non è possibile per gli aggressori leggere o manomettere lo stato della sessione (o riprodurre vecchi valori). Richiede un po 'di lavoro extra per mantenere sincronizzato lo stato della sessione su tutti i server, se l'applicazione Web è distribuita su più nodi di calcolo back-end.

  2. Memorizza lo stato della sessione sul client. L'altro approccio consiste nel mettere lo stato della sessione in un cookie e inviare il cookie al browser. Ora ogni successiva richiesta dal browser includerà lo stato della sessione. Se l'applicazione Web desidera modificare lo stato della sessione, può inviare un cookie aggiornato al browser.

    Se fatto in modo ingenuo, questo è un enorme buco nella sicurezza, perché consente a un client malintenzionato di visualizzare e modificare lo stato della sessione. Il primo è un problema se ci sono dati confidenziali inclusi nello stato della sessione. Quest'ultimo è un problema se il server si fida o si affida allo stato della sessione in alcun modo (ad esempio, considerare se lo stato della sessione include il nome utente dell'utente che ha effettuato l'accesso e un po 'che indica se quell'utente è un amministratore o meno; quindi un client dannoso potrebbe bypassare il meccanismo di autenticazione dell'applicazione Web).

    La proposta che lei menziona e lo schema SCS hanno lo scopo di difendersi da questi rischi nel miglior modo possibile. Possono farlo in un modo che ha principalmente successo. Tuttavia, non possono impedire a un client malintenzionato di eliminare il cookie (e quindi cancellare lo stato della sessione). Inoltre, non possono impedire a un client malintenzionato di riprodurre un valore precedente del cookie (e quindi reimpostare lo stato della sessione su un valore precedente), se la versione precedente proveniva dalla stessa sessione. Pertanto, lo sviluppatore dell'applicazione Web deve essere consapevole di questi rischi e fare attenzione a quali valori sono memorizzati nello stato della sessione.

Per questo motivo, la memorizzazione dello stato della sessione nei cookie è un po 'più rischiosa rispetto alla memorizzazione sul server, anche se si utilizza uno di questi schemi crittografici per proteggere i cookie. (Tuttavia, se stai per memorizzare lo stato della sessione nei cookie, ti consiglio vivamente di utilizzare uno di questi due schemi per proteggere i valori nei cookie. )

Perché qualcuno dovrebbe archiviare lo stato della sessione nei cookie, dato che può essere facilmente memorizzato sul lato server? Il più delle volte, non c'è motivo di farlo. Tuttavia, in alcuni casi eccezionali - come un server HTTP estremamente limitato nella quantità di spazio di archiviazione di cui dispone o in applicazioni Web con bilanciamento del carico che sono distribuite su più macchine senza un buon supporto per lo stato della sessione sincronizzato - potrebbero esserci motivi giustificabili per considerare la memorizzazione dello stato della sessione nei cookie e quindi l'utilizzo di uno di questi schemi è una buona idea.

Post scriptum Un argomento correlato: se si utilizza ASP.NET View State , assicurarsi di configurarlo per essere crittografato e autenticato: ovvero, configurare ViewStateEncryptionMode su Always e EnableViewStateMac a true; se si utilizzano più nodi server, generare una chiave crittografica avanzata e configurare machineKey di ciascun server per utilizzare quella chiave . Infine, assicurati di avere una versione aggiornata del framework ASP.NET; versioni precedenti presentava un grave difetto di sicurezzanella crittografia ViewState .

30
D.W.

Che problema stai cercando di risolvere?

Ci sono due cose a cui posso pensare:

  1. Vuoi impostare sessioni utente sicure. In questo caso, molto probabilmente non hai nemmeno bisogno di generare i tuoi cookie di sessione: possono essere generati su una sessione SSL con il tuo server e sono generalmente sicuro per qualsiasi esigenza del sito web. Assicurati solo che il sito implementi correttamente SSL e usi un metodo di generazione di sessioni ben noto come quello che puoi trovare in linguaggi comuni come PHP o ASP.
  2. Si desidera memorizzare dati sicuri nei cookie per il recupero in un secondo momento. È molto più difficile rendere sicuri, a causa di molti problemi con i cookie. Meglio archiviare invece sul lato server e associare i dati all'utente utilizzando un altro metodo. Se devi farlo, il metodo che descrivi nel complesso sembra piuttosto buono, anche se non sono chiaro in che modo impedisce gli attacchi replay o altri attacchi come man nel mezzo come SSL.

Sentiti libero di contattarmi direttamente se vuoi discutere di più.

4
Charlie B

Parte del metodo che propongono è l'uso della chiave di sessione SSL come parte del payload crittografato, ma questo dura solo fino alla sessione SSL, ovvero non è possibile utilizzare questo metodo per i cookie destinati a estendersi su più di una sessione del browser. Inoltre non è esattamente banale; per ottenere la chiave di sessione SSL, in particolare la terminazione SSL è altrove che sul server http.

In pratica è molto più semplice utilizzare un valore casuale per il cookie come handle per i dati archiviati sul lato server. Questo può essere legato a cose come un hash dell'agente utente del browser e il netname (non indirizzo IP) del client. E/o, se necessario, la chiave di sessione SSL sul server. Non è necessario crittografare tutti questi dati e inviarli al client.

2
symcbean

Questa è un'implementazione ragionevole in quanto risolve i problemi di:

  • Non ripudio (la verifica del valore non è stata modificata)
  • Riservatezza (che il contenuto crittografato non può essere letto)

Tuttavia, le informazioni dell'utente sono un po 'deboli e se non incorporate all'interno delle informazioni crittografate per un successivo confronto potrebbero essere compromesse.

Il problema maggiore con i cookie o qualsiasi dato accessibile al client è che il client (hacker) può modificarlo o copiarlo. Il dirottamento della sessione è facilmente realizzabile nonostante SSL (come precedentemente commentato come sufficiente - cosa che non lo è). Varie forme di malware, man-in-the-middle, man-in-the-browser e altri attacchi possono catturare il cookie di sessione, copiarlo su un altro computer e ora possono "possedere" quella sessione. Per un sistema di carte su file come Amazon questo può essere problematico.

Per chiudere il ciclo su questa proposta, l'identificazione del client deve essere ragionevolmente univoca e quindi legata ai dati nella sezione crittografata per impedire a un altro computer di rubare il cookie di sessione. Oltre a ciò, i componenti della proposta sembrano sani.

0
Darrell Teague