On Tuesday 10 March 2009 19:11:53 Amedeo Viscido wrote: > 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?).
Viene inviato al client il 'session id', un identificativo che il browser (o chi per esso) deve mandare indietro al server ad ogni richiesta, in modo tale da identificarsi come appartenente a tale sessione. Il nome della variabile il browser non la conosce, conosce solo il session id. Se conoscesse il nome della variabile e se il RegisterGlobal fosse settato, allora potrebbe fare qualcosa. Io starei più attento ad eventuali XSS, con i quali un attacker potrebbe veicolare un session hijacking. > 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). Un accesso ssh non è possibile? > Faccio questo tramite uno script (quello nascosto che cerca la variabile > $_SESSION['pippo']) installato su un dominio con SSL. Ma ci scrivi qualcosa dentro a $_SESSION['pippo'], oppure la abiliti e basta? > 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? Mmmm, diciamo che stai usando un metodo 'ibrido'. La Sicurezza con la S maiuscola dovrebbe far si che l'attacker, pur conoscendo il nome della variabile ed il nome della pagina, non riesca a visualizzare i log. E questo lo ottieni usando la password. Ma, come dicevo, occhio a XSS e passaggio di credenziali in chiaro. E occhio alle password facilmente bruteforzabili. > 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. Il tuo unico metodo di sicurezza valido è la password, il resto è un qualcosa che ti da un falso senso di sicurezza. Poi c'è da capire anche il target di quei log, chi li vuole rubare e perchè. Io sono dell'idea che la sicurezza deve trovare un compromesso con l'usabilità, in relazione al grado di importanza/segretezza del dato da proteggere, che poi determina la quantità di risorse spendibili in un ipotetico attacco. -- g4b0, linux user n. 369000 http://gabo.homelinux.com ________________________________________________________ http://www.sikurezza.org - Italian Security Mailing List
