Amedeo Viscido ha scritto: > Ringrazio tutti per le risposte. > Molti dettagli mi sono noti, per evitare risposte dall'ovvio al vago pongo > una domanda un pò più specifica, sul funzionamento delle sessioni stesse. > > Quando in uno script php richiamo la session_start(), vengono inviate > informazioni al client? Ad esempio, viene impostato qualcosa nei cookie? O > le informazioni di sessione vengono mantenute solo sul lato server? Perché > in questo caso il client non saprebbe nulla sulla sessione, di conseguenza > non potrebbe conoscere il nome della variabile per tentare di fare qualcosa > (per inciso, conoscendo il nome della variabile, potrebbe fare qualcosa?). > Quando apri la sessione, normalmente sul client viene memorizzato un cookie con il riferimento alla sessione. Se questo non avviene per i più svariati motivi (il più comune è che l'utente rifiuta di salvare i cookies), il webserver ne tiene traccia via GET/POST, o almeno ci prova. Questo perchè il server per tenere una sessione aperta con un browser, deve sapere chi è chi. > Forse sarete curiosi, quindi vi espongo il mio problema. > Voglio esporre i log di alcuni programmi in esecuzione sulla macchina (log > del web server, email, ecc). > Faccio questo tramite uno script (quello nascosto che cerca la variabile > $_SESSION['pippo']) installato su un dominio con SSL. > > In un'altra pagina, sempre ssl, si deve inserire la password. La sola > conoscenza della password non permette quindi di accedere ai dati, bisogna > pure conoscere il nome della pagina di quel giorno (in particolare è l'MD5 > della data con in coda una certa stringa). > In effetti la mia pratica non è security through obscurity "pura", giusto? > Visto che non conoscere la password non permette di accedere alla pagina > nascosta, poiché se non è presente la variabile di sessione viene > presentato un errore 404. > Sulla pagina applichi security through obscurity. Per la sessione ti affidi ad una variabile SESSION che, in assenza di bugs e di GLOBALS attive dovrebbe essere sicura. Di bugs in PHP se ne trovano spesso ed alcuni di questi permettono lo spoofing/sniffing di una sessione quindi valuta il peso delle informazioni da proteggere e decidi quali/quanti danni si possono fare in caso di hacking della pagina.
Ex. Per proteggere una pagina readonly con info generiche, tale pratica può essere valida. Per una pagina che dà la possibilità di SQL injection o addirittura exec di variabili ( shell su web :-| ) o la lista dei numeri di carte di credito, io mi sposterei in autenticazioni via htaccess con privilegi adeguati sul filesystem. Solo mia esperienza, lascio agli esperti di PHP l'ultima parola. MG
________________________________________________________ http://www.sikurezza.org - Italian Security Mailing List
