cookie vs session

[markzzz]

salve. stò realizzando un applicazione web che tiene traccia degli utenti loggati quanto essi fanno il login e impostano un determinato parametro (cliccano per esempio sulla checkbox "autologin").

si crea la sessione e si crea il cookie (tempo di vita 1 anno, e ci salvo dentro username + password criptata in md5).
quando la sessione scade, ho impostato un modo che, se il cookie è settato, controlli se quei due parametri esistano/coincidano nel database, e in questo caso crea una nuova sessione (se scaduta in precedenza ovviamente, non ogni volta) e rinnova il cookie.

credo che questa sia la logica di base associata ai cookie (molti magari salvano il session id per poi rigenerarlo. io preferisco username e password).

ora, quello che mi vien da chiedere è : questa tecnica è davvero insicura...

se uno sniffa i pacchetti in entrata e uscita, legge i dati, costruisce un cookie, lo invia e il gioco è fatto. questa è la stessa cosa quando ci si logga e si crea un nuovo session id : che io mandi le password in chiaro o criptate, se uno legge i dati e li invia lui stesso accede senza problemi.

direte voi : bravo, hai scoperto l'acqua calda. quello che mi lascia perplesso è : non esiste un modo (tranne usare https) per eliminare questo fastidioso problema? ci sarà ben un sistema/tecnica... mi sembra davvero strano (vedo centinaia di siti senza https, e che utilizzano cookie e session : avranno dei sistemi anti-intercettamento ).

qual'è la vostra idea su tutto questo?

p.s. tra l'altro : la sessione a lato server come viene riconosciuta? tramite la connessione (livello tcp/ip) oppure viene inviato l'id della sessione tramite il browser? perchè ad esempio firefox mi crea un file chiamato phpsessid...
se invia l'id, anche questo potrebbe provocare un accesso da parte di un malintenzionato previo sniffer dei pacchetti!

cordiali saluti

[max161]

Originariamente inviato da markzzz
se uno sniffa i pacchetti in entrata e uscita, legge i dati, costruisce un cookie, lo invia e il gioco è fatto. questa è la stessa cosa quando ci si logga e si crea un nuovo session id : che io mandi le password in chiaro o criptate, se uno legge i dati e li invia lui stesso accede senza problemi.

questa è la metodologia, se i rischi esistono non si possono evitare, sta al programmatore adottare "varie" misure di difesa tra cui la crittazione.
forse, per sfruttare 'https' come dici tu, al fine di accedere alla lettura del cookie contenente le password dell'utente in totale sicurezza(se così si può dire), potresti utilizzare le socket....

p.s. tra l'altro : la sessione a lato server come viene riconosciuta? tramite la connessione (livello tcp/ip) oppure viene inviato l'id della sessione tramite il browser? perchè ad esempio firefox mi crea un file chiamato phpsessid...
se invia l'id, anche questo potrebbe provocare un accesso da parte di un malintenzionato previo sniffer dei pacchetti!

viene inviato l'id della sessione tramite il browser

[strae]

Originariamente inviato da markzzz
salve. stò realizzando un applicazione web che tiene traccia degli utenti loggati quanto essi fanno il login e impostano un determinato parametro (cliccano per esempio sulla checkbox "autologin").

si crea la sessione e si crea il cookie (tempo di vita 1 anno, e ci salvo dentro username + password criptata in md5).
quando la sessione scade, ho impostato un modo che, se il cookie è settato, controlli se quei due parametri esistano/coincidano nel database, e in questo caso crea una nuova sessione (se scaduta in precedenza ovviamente, non ogni volta) e rinnova il cookie.

credo che questa sia la logica di base associata ai cookie (molti magari salvano il session id per poi rigenerarlo. io preferisco username e password).

ora, quello che mi vien da chiedere è : questa tecnica è davvero insicura...

se uno sniffa i pacchetti in entrata e uscita, legge i dati, costruisce un cookie, lo invia e il gioco è fatto. questa è la stessa cosa quando ci si logga e si crea un nuovo session id : che io mandi le password in chiaro o criptate, se uno legge i dati e li invia lui stesso accede senza problemi.

direte voi : bravo, hai scoperto l'acqua calda. quello che mi lascia perplesso è : non esiste un modo (tranne usare https) per eliminare questo fastidioso problema? ci sarà ben un sistema/tecnica... mi sembra davvero strano (vedo centinaia di siti senza https, e che utilizzano cookie e session : avranno dei sistemi anti-intercettamento ).

qual'è la vostra idea su tutto questo?

p.s. tra l'altro : la sessione a lato server come viene riconosciuta? tramite la connessione (livello tcp/ip) oppure viene inviato l'id della sessione tramite il browser? perchè ad esempio firefox mi crea un file chiamato phpsessid...
se invia l'id, anche questo potrebbe provocare un accesso da parte di un malintenzionato previo sniffer dei pacchetti!

cordiali saluti

nel cookie, insieme all'user e alla password in md5, salva anche un secret, cioè ad esempio, crei una stringa del tipo

$secret = md5($user . 'parolachetiinventitu' . $password); 

e quando fai il controllo, ricalcoli il secret nello stesso modo e vedi se combacia con quello presente nel cookie.

[telegio]

Originariamente inviato da strae

$secret = md5($user . 'parolachetiinventitu' . $password); 

e quando fai il controllo, ricalcoli il secret nello stesso modo e vedi se combacia con quello presente nel cookie.

io ho usato i primi 8 caratteri dell'MD5 della password.. una bomba..

[strae]

Originariamente inviato da telegio
io ho usato i primi 8 caratteri dell'MD5 della password.. una bomba..

si bhè ognuno usa quello che gli pare, l'importante è NON usare cose 'volatili' tipo un timestamp.. che poi non puoi più recuperarlo

[markzzz]

Originariamente inviato da max161
viene inviato l'id della sessione tramite il browser

addirittura O_O quindi non c'è neanche controllo sulla connessione. uno sniffa i pacchetti e non ha neanche bisogno di user e password. gli basta l'id della sessione (scopre la mia, la modifica alla sua e entra nella mia area).

Originariamente inviato da strae
nel cookie, insieme all'user e alla password in md5, salva anche un secret, cioè ad esempio, crei una stringa del tipo

$secret = md5($user . 'parolachetiinventitu' . $password); 

e quando fai il controllo, ricalcoli il secret nello stesso modo e vedi se combacia con quello presente nel cookie.

uhm, ma cosa cambia scusa? uno sniffa i pacchetti, vede la variabile secret nel cookie, la copia, la incolla in un suo cookie, aspetta che la mia sessione finisca, e mi frega l'accesso


l'unica cosa che mi vien da fare è quella descritta in questo articolo : un utente può anche copiare il mio user_agent, ma se quando arriva la sua richiesta l'user agent del suo browser è diverso, non può accedere. ovviamente questo vale per le sessioni, per i cookie non credo funzioni...

[strae]

Originariamente inviato da markzzz
addirittura O_O quindi non c'è neanche controllo sulla connessione. uno sniffa i pacchetti e non ha neanche bisogno di user e password. gli basta l'id della sessione (scopre la mia, la modifica alla sua e entra nella mia area).


uhm, ma cosa cambia scusa? uno sniffa i pacchetti, vede la variabile secret nel cookie, la copia, la incolla in un suo cookie, aspetta che la mia sessione finisca, e mi frega l'accesso


l'unica cosa che mi vien da fare è quella descritta in questo articolo : un utente può anche copiare il mio user_agent, ma se quando arriva la sua richiesta l'user agent del suo browser è diverso, non può accedere. ovviamente questo vale per le sessioni, per i cookie non credo funzioni...

....ma se quando l'user torna sul sito, con il cookie valido, invece di ripristinare la vecchia sessione ne crei una nuova, non fai prima?

[markzzz]

Originariamente inviato da strae
....ma se quando l'user torna sul sito, con il cookie valido, invece di ripristinare la vecchia sessione ne crei una nuova, non fai prima?

sisi, ma il problema del creare o ripristinare la sessione non è un problema, ho capito come và implementato questo problema. resta il fatto che ho discusso sopra : uno che scopre i parametri del cookie (anche se criptati), li inserisce in un suo cookie e si collega al sito, accede alla mia area senza nessun tipo di problema (anche inserendo quella "parola" segreta).

e questo non è il massimo...
quindi capitolando, usando cookie senza protocollo https uno può impadronirsi senza nessun tipo di problema (semplicemente sniffando i pacchetti e modificando il propio cookie).

ne varrà davvero la pena sottoporre un sito a tale rischio per un semplice "ricordami la prossima volta" ???

[strae]

Originariamente inviato da markzzz
sisi, ma il problema del creare o ripristinare la sessione non è un problema, ho capito come và implementato questo problema. resta il fatto che ho discusso sopra : uno che scopre i parametri del cookie (anche se criptati), li inserisce in un suo cookie e si collega al sito, accede alla mia area senza nessun tipo di problema (anche inserendo quella "parola" segreta).

e questo non è il massimo...
quindi capitolando, usando cookie senza protocollo https uno può impadronirsi senza nessun tipo di problema (semplicemente sniffando i pacchetti e modificando il propio cookie).

ne varrà davvero la pena sottoporre un sito a tale rischio per un semplice "ricordami la prossima volta" ???

Si, ma te la fai facile a 'sniffare' il cookie, è più probabile/semplice 'sniffare' direttamente l'user e password che uno inserisce nel form, e a quel punto qualsiasi sessione/cookie non serve più a niente (lavorando fuori https).

Potresti 'potenziare', e includere nel $secret anche l'indirizzo ip, user agent, e altri dettagli, volendo, se uno solo di essi è incoerente, puppa, in controllo a md5 darà errore.

[markzzz]

Originariamente inviato da strae
Si, ma te la fai facile a 'sniffare' il cookie, è più probabile/semplice 'sniffare' direttamente l'user e password che uno inserisce nel form

ma come? tutti i dati che partono dal browser verso il server (username, password (sia in chiaro che md5), cookie, sessionid, ecc ecc) son dentro alla http request. quando invio una singola pagina al server il cookie sarà sempre presente. uno si posiziona tra me e il server con un programma tipo wshark e vede tutto quello che passa...

perchè è piu difficile sniffare il cookie rispetto a un singolo parametro che passo al server (anche un normale POST)?