Persistenza dei dati nella sessione e loro sicurezza

[Marcolino's]

Salve ragazzi,
ho una questione da discutere se vi va, come da titolo ho un problema da risolvere con la sicurezza dei dati in sessione.
So che probabilmente è un ergomento già discusso ma alcune questioni non mi sono comunque chiare, vi spiego l'antefatto: sto costruendo un'applicazione Web che fa uso di database, al momento del login almeno un dato viene messo in sessione per riconoscere l'utente connesso.
Il problema che mi sono creato al momento è quale dato metto nella sessione?
La semplice tabella di login è così fatta:

id intero autoincrementante
nickname
password
attivo (sì|no|bannato)

Una cosa semplice come si vede, ovviamente ulteriori dati sono in altre tabelle, questa serve solo al login; il campo id è un normale campo autoincrementante, nick e pass sono ovvi, attivo serve a vedere se il soggetto deve essere autenticato o meno.
Una volta effettuatato il login per riconoscere l'utente tra le pagine del sito uso la sessione, sì ma quale dato inserisco in sessione?

• ID? Un numero che se scoperto mi basterebbe cambiare per navigare le pagine del sito come se fossi un altro utente.
• nickname forse è un dato più sicuro, una volta effettutato l'hash del nome potrei stare abbastanza sicuro che pochissimi riescano a carpirne il vero nome.
• come sopra ma mi pare fuori luogo, anche se ho visto molti forum blasonati addirittura metterli nei cookie e non parlo di quelli di sessione ;-)

Voi che usereste per identificare la sessione e comunque per limitare il numero delle query al database, preferireste estrarre fuori tutti i dati ed affidarvi alla sessione per trasportare le informazioni relative all'utente tra una pagina e l'altra? O come?

[Santino83_02]

le Sessioni vivono nel server, non nel client. Quindi, a meno che tu non le carichi attraverso cookie (che invece vivono nel client), in Session ci puoi mettere quello che ti pare (Sempre che non ti buchino il server ovviamente).

detto ciò, in session ci puoi mettere benissimo solo l'id o l'id e il nickname, la password è inutile, "attivo" non ho idea di cosa sia ma ci puoi mettere pure quello.

[Marcolino's]

Originariamente inviato da Santino83_02
le Sessioni vivono nel server, non nel client. Quindi, a meno che tu non le carichi attraverso cookie (che invece vivono nel client), in Session ci puoi mettere quello che ti pare (Sempre che non ti buchino il server ovviamente).

Questo lo so bene ma il furto di sessione pure non è difficile e la modifica della stessa non è certo pratica così complessa da realizzare.
[/quote]
detto ciò, in session ci puoi mettere benissimo solo l'id o l'id e il nickname, la password è inutile, "attivo" non ho idea di cosa sia ma ci puoi mettere pure quello. [/QUOTE]
Be la password è pur sempre un dato univoco come il nickname o l'id quindi andrebbe bene comunque, è solo "strano" farlo, per esempio questo forum mi pare di capire sa cokkie lo fa.

[pacochan]

Per quanto riguarda la sicurezza delle sessioni e dei cookie, ti suggerisgo di leggerti il capitolo

TESTING FOR SESSION MANAGEMENT SCHEMA (OWASP-SM-001)

della guida OWASP (Open Web Application Security Project) reperibile gratuitamente su owasp.org. In particolare, leggiti la pagina riassuntiva (pag. 156).

Spero possa esserti utile! Seguire le linee guida OWASP è sicuramente il modo migliore per rendere sicuro il tuo sito.

Ciao

[Santino83_02]

veramente la password non è univoca per niente, di univoco tendenzialmente c'è solo la username. Poi non credo che il forum questo metta la password nel cookie, o se lo fa ci mette l'md5 quindi la cripta, non in chiaro. Ma un conto è il cookie, un conto è la session.

[*pragma]

$_SERVER[\'REMOTE_ADDR\']
questo dovrebbe essere univoco.

[NonCeLaFaccio+]

Originariamente inviato da *pragma
$_SERVER[\'REMOTE_ADDR\']
questo dovrebbe essere univoco.

Non vorrei dire una castroneria ma il REMOTE_ADDR non è affatto univoco, fastweb ad esempio, per quanto ne so, crea delle subnet a livello di caseggiato o condominio e tutti coloro che si collegano da quella subnet hanno lo stesso ip (fastweb poi tiene traccia in proprio delle connessioni interne alla subnet per permettere eventuali accertamenti di polizia) e lo stesso succede quando ci si collega da un ufficio dotato di lan collegata ad internet attraverso un proxy (nell'ufficio in cui mi trovo ora, per esempio, siamo circa 1000 e tutti usciamo con lo stesso ip, quello del proxy).

Riguardo al contenuto del cookie scritto da un sito, ho scoperto che esiste un modo semplicissimo per leggerlo, senza impazzire fra cartelle di file temporanei, basta scrivere nell'url: "javascript:document.cookie" (chiaramente senza il trattino).

E infine per dare il mio contributo alla domanda originaria vorrei far notare che se il cookie di sessione lo si fa gestire automaticamente dal php con la session_start() esso conterrà un semplice identificativo di sessione che permette al server di riconoscere il client collegato e non i dati dell'array $_SESSION.

Questo identificativo non va comunque sottovalutato in quanto a pericolosità perché permette a qualcuno che ne venga in possesso di collegarsi al server spacciandosi per qualcun altro (mentre quel qualcun altro è collegato).

Ad esempio un mio amico che si occupa di penetration testing, è riuscito, caricando uno script nel proprio profilo e richiedendo l'amicizia ad un altro utente a far sì che questo script girasse sulla macchina dell'altro utente e ne leggesse il cookie di sessione con cui era collegato e a quel punto il mio amico si è potuto collegare "come se fosse l'altro", accedendo ai suoi documenti ecc...

Mi ha spiegato (e ha spiegato al cliente che gli ha commissionato il test) che questo si sarebbe potuto risolvere facendo in modo che il cookie fosse "sicuro" (mi ha anche spiegato come ma non lo ricordo) però, voglio dire, questi sono problemi intrinseci di internet e degli attacchi XSS e non specifici delle sessioni perché i dati che metti in sessione devi dare per scontato che sono e restano sul server e non è possibile accedervi dall'esterno (sempre che il server sia configurato correttamente).

Quindi mettici il dato che ti è più comodo, per esempio l'id così da averlo sempre disponibile senza accedere ogni volta al db.

Piuttosto, se i dati del tuo sito sono veramente delicati concentrati sulla scelta del maintainer (non prendere uno di quelli da trenta euro l'anno) e usa https, in questo modo fai già due bei passi avanti.

Ciao