On martedì 10 marzo 2009, Amedeo Viscido wrote: > 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?).
Le sessioni in PHP sono implementate con starage lato server (di default in file di sessione con nome contenente il session ID e la cui path può essere impostata a piacimento, è comunque possibile implementare session storage custom su DB, shm o quant'altro...), i dati di sessione sono quindi salvati in qualche parte sul server (inteso appunto come "lato server" che non significa che poi siano *fisicamente sul server web* perché come detto possono essere su filesystem (magari di rete), su DB (magari remoto), etc il link tra l'utente ed i suoi dati è fontamentalmente costituito dal SID (il Session ID) che non è altro che una stringa che identifica univocamente (!?) la sesione appunto ... tale SID viene comunicato al client all'atto della creazione della sessione ed il client deve utilizzarla in ogni comunicazione col server (http è stateless!) se vuole beneficiare delle info in sessione ... ci sono due modi per farlo i cookie (preferito) o la request (get o post che sia) ... in entrambi i casi non si fa altro che inviare al server una "variabile" SID il cui contenuto è appunto il valore del Session ID in uso. Ci sono state in passato alcune falle di sicurezza legate, per lo più indirettamente, alle sessioni ... il pericolo era n una vecchia e deprecatissima impostazione del php.ini che metteva automaticamente nello scope globale le variabili provenienti da get, post, cookies e quant'altro .. Impostando register_globals a off ed usando versioni non preistoriche di php la questione non dovrebbe + porsi... Premettendo che va comunque fatto un minimo di hardening delle impostazione del php.ini per evitare che comodità presunte non si rivelino buchi immensi, i veri attacchi alle sessioni ( e non solo di PHP) sono di ben altra natura. A riguardo c'è un bestiario che va da Session Hijacking, al Session Fixation ad altri dai nomi che non ricordo mai che che fondamentalmente ruotano tutti attorno al concetto che il SID è tutto. Le cose che si prova a fare per "rubare una sessione" sono per esempio tentare di indurre un utente a usare una sessione da noi già aperta, tentare di evitare che il server crei un nuovo SID al login fornendogliene uno da "riciclare", etc Tempo fa passò in lista uno studio di un giovane ragazzo che aveva affrontato un problema simile tentando di fornire una lib php che protegesse da uno di questi attacchi, seride si chiama se non erro... può essere spunto per capire uno degli attacchi possibili, anche se al moka guardando i sorgenti mi parve che tale lib (che però era uno studio appunto) proteggese si dall'attacco da cui doveva immunizzare, ma esponesse ad altri attacchi (session fixaion se la memoria non mi inganna) ;) la risposta IMHO è quindi ni... lo strumento è sicuro, l'implementazione che se ne fa spesso non lo è -- <?php echo ' Emiliano Gabrielli (aka AlberT) ',"\n", ' socio fondatore del GrUSP ',"\n", ' AlberT_at_SuperAlberT_it - www.SuperAlberT.it ',"\n", ' IRC: #php,#AES azzurra.com ',"\n",'ICQ: 158591185'; ?>
________________________________________________________ http://www.sikurezza.org - Italian Security Mailing List
