Si sta utilizzando un ID sessione SSL insieme a una verifica sessione basata su cookie più sicura o meno?

Question

Si sta utilizzando un ID sessione SSL insieme a una verifica sessione basata su cookie più sicura o meno?

#1 da (5 voti)
#2 da (1 voti)

2

Sto usando Django che è un framework web per Python. Mi piace ma la gestione della sessione è basata sui cookie. Ora su SSL sono sicuro che è ragionevolmente "sicuro", ma non penso che ci sia alcun tipo di errore sicuro se quel cookie viene compromesso. Dovrei anche menzionare che sto usando Apache2 con Mod_WSGI. Per ciascuna sessione di Apache2 esiste una variabile di ambiente SSL_SESSION_ID che posso ottenere dal modulo python root. In particolare, la mia domanda è che richiederà che SSL_SESSION_ID da Apache2 per abbinare il cookie Session_Key nel database (e il browser dei client) effettivamente aiuti a prevenire cose come un attacco MITM o il dirottamento di sessione o è uno spreco di sforzi? Da un lato, penso che potrebbe perché il client non ha idea (PENSO) di SSL_SESSION_ID in modo che non possano fingere. D'altra parte, penso che se un utente malintenzionato potrebbe compromettere la crittografia o il browser abbastanza da ottenere il cookie, probabilmente potrebbero comunque ottenere la password e avviare una nuova sessione.

cookies openssl tls man-in-the-middle session-management

posta p1l0t 17.01.2014 - 00:14

fonte

2 risposte

1

Se si parla strettamente di sicurezza, SSL è sufficiente.

SSL preverrà un attacco MITM (a meno che la chiave privata del server non venga compromessa o la chiave negoziata venga divulgata).
Se qualcuno ruba il cookie da un client, il PC client è compromesso e non puoi fare nulla al riguardo. L'attaccante ha il pieno controllo ora e puoi aggiungere quanti token / sicurezza vuoi, ma l'attaccante ha pieno accesso.

In ogni caso, puoi sempre utilizzare un cookie per identificare un utente per qualsiasi motivo, ovvero tenere traccia della sua attività all'interno di connessioni diverse, pubblicità, conteggio di visite uniche, ecc.

risposta data 17.01.2014 - 08:19

fonte

Leggi altre domande sui tag cookies openssl tls man-in-the-middle session-management

Modo appropriato per crittografare password / informazioni finanziarie? Sale casuale - necessario per un singolo utente?

score 5 · Accepted Answer

L'ID sessione SSL è transitorio; designa i "parametri della sessione SSL" che il client ricorda su un precedente handshake SSL, in particolare il valore segreto simmetrico negoziato ottenuto dalla crittografia asimmetrica di quella stretta di mano. È tenuto solo nella RAM; se l'utente si riavvia, o semplicemente chiude tutte le finestre del suo browser, dimentica l'ID della sessione. Se utilizzi l'ID di sessione SSL come parte del meccanismo di autenticazione, gli utenti che chiudono e riapre il browser dovranno autenticarsi nuovamente con la loro password.

Se è quello che vuoi, allora, con tutti i mezzi, usa l'ID di sessione SSL. Conosco le banche che lo fanno per la loro gestione dei conti bancari basata sul Web.

Si noti che se il server si riavvia, anche l'ID di sessione SSL diventerà obsoleto: anche se è stato memorizzato nel database, il server riavviato ha dimenticato la chiave di sessione effettiva (anche il server, lo memorizza solo nella RAM) e quindi negozierà una nuova sessione con una stretta di mano completa alla prossima connessione dal client. Inoltre, la memoria del server delle sessioni precedenti è configurabile ma spesso limitata nel tempo (con Apache, vedere la documentazione , direttive SSLSessionCache e SSLSessionCacheTimeout ). Badate anche che la memoria del client sia basata sul processo : su un PC, la chiusura di tutte le finestre tende a terminare il processo del browser; su smartphone e tablet, a cui piace tenere le cose in esecuzione per un numero eccessivo di tempo, uccidere realmente il processo è un processo più complicato (in genere, il browser "si chiude" solo quando l'utente esaurisce la batteria).

D'altra parte, per i siti meno critici (dal punto di vista dell'utente), gli utenti tendono a preferirlo quando autenticano una volta e vengono "ricordati" anche attraverso i riavvii o persino il browser vicino. Affinché una simile funzionalità funzioni, non c'è modo di evitarlo: deve esserci un segreto specifico dell'utente memorizzato sul lato client. I cookie non sono peggiori di altri meccanismi per questo, e sono l'unico che è prontamente disponibile e compatibile con tutti i browser.

Riepilogo: utilizza l'ID di sessione SSL se desideri sessioni molto transitorie, che scompaiono automaticamente quando il browser viene chiuso (il processo del browser, non solo la finestra pertinente) . Utilizza i cookie per l'autenticazione di lunga durata. Non sono intercambiabili; non operano sulla stessa scala temporale.