[sicurezza] fino a che punto sono sicure le sessioni?

[nik600]

mysql_query="select id from utenti where md5(id) ='$SESSION_[id_utente]'"; 

[Mackey]

... MA NON è SICURO!

anche un bambino ci arriva:

1) mi faccio questo script in locale:

<?php
	for($i=0; $i++<10;) {
		print md5($i)."
";
	}
?>

2) lo mando in esecuzione
3) vado su C:\windows\cookies
4) prendo il cookie del sito e lo modifico provando di volta in volta uno di quelle stringhe che ho stampato prima
5) sono sicuramente entrato con qualche ID!

se poi non uso i cookies... e SO MODIFICARE LA SESSIONE... anche peggio!

[nik600]

1 io non ho mai parlato di autenticazione su cookies
2 tu mi hai chiesto come fare la query e io ti ho risposto
3

se poi non uso i cookies... e SO MODIFICARE LA SESSIONE... anche peggio!

è troppo comoda dire cosi ... è come dire è sicuro usare un tipo di serratura se ci sono in giro ladri che la sanno forzare?

bisogna trovare un compromesso tra l'affidabilità del sistema e la soluzione adottata x renderlo sicuro, in relazione a quello che fa

4 per me un bambino non ci arriva!

[Mackey]

[supersaibal]Originariamente inviato da Mackey
lo stesso discorso vale per i cookie... infatti utilizzo lo stesso metodo per memorizzare il login... e in effetti, forse è meglio memorizzare username e password... con i COOKIE a maggior ragione! [/supersaibal]

lo avevo detto...

comunque il motivo di questo 3D è:

esiste un modo per modificare la sessione o eredirarne i valori?

[daniele_dll]

[supersaibal]Originariamente inviato da Mackey
lo avevo detto...

comunque il motivo di questo 3D è:

esiste un modo per modificare la sessione o eredirarne i valori? [/supersaibal]

azzeccando l'id di sessione ... ma le combinazioni arrivano fino a ... tanto tanto ... tenete conto che se fossero 4 byte, ma sono 16, sarebberò 4 miliardi di combinazioni ...

---

[supersaibal]Originariamente inviato da Gianni_T
un altro problema delle sessioni è il furto del session id a cui si può ovviare attraverso SSL [/supersaibal]

non c'azzecca niente non facciamo confusione ... le ssl servono a cifrare la comunicazione ... ovvero a impedire (quasi) che se uno ha bucato uno dei nop della rete dal quale passa la tua comunicazione e sta salvando TUTTO il traffico, possa carpire, non crittati, i tuoi dati ... a questo servono le SSL tanto che x usarle basta installare un certificato apposito e impostare apache per usarlo con un dato virtual host, fine ... l'unica cosa che ti rende + difficile fare è quello di sopra ... fine

[Mackey]

grazie daniele... troppo gentile.

quindi posso stare sicuro...

[C232]

studiati PEAR::Crypt_HMAC

[daniele_dll]

Crypt_HMAC ... gli conviene tirarlo fuori dal pear xo ... ovvero si modifica il codice x farlo andare senza pear

pochi hoster forniscono il pear insieme al resto

oppure tira fuori os-commerce che ha un'implementazione di md5-hmac

[Gianni_T]

Il principio delle sessioni è lasciare tutti i dati sul server e "palleggiare" con il client solo un codice identificativo (session ID) che permetta di associare univocamente questi dati al legittimo client proprietario.

I dati, risiedendo sul server, sono ovviamente più al sicuro rispetto ad altre soluzioni, ad esempio quella di inviarli via cookie. E' impossibile quindi che il client li modifichi forzosamente. Rimane comunque il problema della sicurezza del server. Nella maggior parte dei casi, se il responsabile del server fa bene il suo lavoro, si può stare tranquilli anche nel caso di uso delle sessioni tradizionali con salvataggio di dati su file. La sicurezza aumenta se i dati di sessione vengono salvati su DB. Quindi nei dati di sessione si può memorizzare qualsiasi cosa, anche dati veramente importanti come le password o i codici di carte di credito, sempre che ce ne sia la reale necessità e che il server sia sicuro.

Il session ID viene generato da PHP in maniera pseudocasuale e, come è stato già detto, non può essere indovinato, se mai, visto che è l'unico elemento della sessione che va avanti e indietro durante la navigazione, può essere "rubato". Anche questa evenienza è comunque abbastanza remota. Il furto di sessione può essere effettuato in vari modi. In generale conviene affidarsi ai cookie per la propagazione del session ID, così da non generare pagine con i links pieni di session id nella query string. Se comunque qualcuno riesce ad intercettare la comunicazione tra client e server (cosa comunque remota) allora vedrà passare il session id e potrà così "rubarlo". Ecco perché ho proposto l'uso di SSL, in modo da scongiurare questa evenienza.
Per proteggere il session ID ulteriormente si può pensare di fare un controllo incrociato con l'IP del client o con il suo referrer ma questo potrebbe portare ad altri problemi.

L'uso di PEAR::Crypt_HMAC non è indicato per questo genere di situazioni. PEAR::Crypt_HMAC serve per creare un hash con chiave dei dati passati attraverso la query string o i cookie in modo da scongiurarne la manomissione da parte dell'utente. Avrebbe senso usarlo se si inviassero informazioni al client ma con le sessioni i dati rimangono sul server e quindi non c'è nulla da proteggere.

[Mackey]

Ragazzi, siete su una lunghezza d'onda ben superiore alla mia...

comunque che problemi ci sono a salvare la password criptata con MD5 su un cookie? si potrebbe decifrarla?