[PHP] Sessioni e sicurezza

[Fayble]

Se l'utente ha i cookies disabilitati, è necessario passare l'ID di sessione tramite URL, implicitamente se "session.use_trans_sid" è abilitato, altrimenti esplicitamente. In entrambi i casi, se non ho capito male, l'ID viene "rivelato".

Ma rendere "visibile" l'ID di sessione, quali problemi di sicurezza può dare? Il php.ini raccomanda cautela...

[geko]

In questo modo rendi ancora più vulnerabile un punto debole di PHP, quello di poter impostare "manualmente" l'id di sessione. mettiamo il caso in cui tu acceda ad un'area riservata; se io riuscissi a sniffare il tuo SESSION_ID potrei utilizzarlo per impersonare te sul sito semplicemente chiamando una pagina "riservata", accodando all'url PHP_SESSION=xxxxxxx. C'era un interessante articolo su questo meccanismo, che purtroppo non riesco più a trovare.
Cmq come dicevo all'inizio questa è già una debolezza di PHP, che sussiste anche utilizzando le sessioni normalmente...

[Fabio Heller]

I veri pericoli sono che tu mandi un link ad un amico con l'id di sessione e che tale link venga usato prima che la sessione scada, o che qualcuno presente fisicamente sbirci l'id mentre sei al pc.

Il pericolo dello sniffing sussite anche con i cookie e non è una debolezza di PHP, è una debolezza del protocollo HTTP. Quindi di qualsiasi linguaggio server side

La soluzione, nei casi in cui la sicurezza è davvero fondamentale, è usare ssl, ovvero il classico url https://

[geko]

La debolezza di PHP è il fatto di accettare che io richieda una pagina in questo modo:
http://www.mioserver.com/pagina.php?PHP_SESSION=123456
(non mi ricordo se è PHP_SESSION o SESSION_ID o simile..) e da questo momento impostare l'id di sessione a '123456'. In pratica l'id di sessione non è una proprietà READONLY!!!!
Con ASP su IIS ad esempio ciò non è possibile. Onestamente non so se la debolezza sia di Apache o di PHP, cmq non è una questione di HTTP, il fatto che i dati viaggino in chiaro è palese...
Il problema che sottolineavo è il seguente:
io conosco il tuo id di sessione --> io sono te

[Gianni_T]

@geko

prima di contraddire Fabio Heller normalmente mi leggo tutto il manuale PHP, le specifiche dell'HTML, gli RFC del TCP/IP e anche tutta l'Enciclopedia Britannica. Alla fine scopro sempre che Fabio ha ragione.

Questo è uno di quei casi...

[geko]

Infatti la sua affermazione è corretta, però spendi anche un minuto per leggere quello che ho scritto e forse capirai che stavo parlando di un'altra cosa....

[Fayble]

Ok, grazie mille. Avrei altre due curiosità:

1. Abilitare "session.use_trans_sid", che pericoli può nascondere?

2. E' più sicura la gestione delle sessioni usando il metodo descritto dal seguente articolo?
http://freephp.html.it/articoli/view...olo.asp?id=132

[Gianni_T]

con "session.use_trans_sid" fai si che il session id si propaghi attraverso gli URL, e questa non è la scelta ottimale dato che rende questo ID particolarmente visibile e quindi più esposto a rischi, anche se così le sessioni funzionano anche sui browser che hanno i cookie disabilitati (esistono ancora?)

la gestione con DB delle sessioni non migliora la sicurezza dell'invio e della ricezione del session id, poiché dipende dai medesimi meccanismi offerti dall'HTML. Migliora invece la sicurezza delle variabili di sessione poiché, invece di risiedere in un file di testo "potenzialmente accessibile anche da altri utenti (ma è una remota possibilità), vengono memorizzate in un DB. Le sessioni su DB comunque offrono altri vantaggi non legati direttamente alla sicurezza.

[Fabio Heller]

Originariamente inviato da geko
La debolezza di PHP è il fatto di accettare che io richieda una pagina in questo modo:
http://www.mioserver.com/pagina.php?PHP_SESSION=123456
(non mi ricordo se è PHP_SESSION o SESSION_ID o simile..) e da questo momento impostare l'id di sessione a '123456'. In pratica l'id di sessione non è una proprietà READONLY!!!!
Con ASP su IIS ad esempio ciò non è possibile.

Con l'id nell'url l'id di sessione non viene impostato da te, se esiste e lo indovini puoi infiltrarti nella sessione altrui..... altrimenti no.
Per poterlo "rubare" deve esserti inviato via link o devi poterlo vedere essendo fisicamente presente davanti al terminale.
Oppure devi sinnfare il traffico di rete,ma questo è possibile anche con l'id nei cookie.
Ad ogni modo l'id nell'url è una comodità che PHP ti dà in più, nel caso tu ti debba servire delle sessioni per usi diversi da un'area riservata.
Comunque anche se l'utente passa l'id nell'url puoi sempre far sì che il sistema delle sessioni lo ignori, mettendo session.use_only_cookies = 1 nel php.ini .

In ASP il problema non c'è perchè ASP (salvo plugin di IIS poco usati) utilizza soltanto i cookie

Onestamente non so se la debolezza sia di Apache o di PHP, cmq non è una questione di HTTP, il fatto che i dati viaggino in chiaro è palese...
Il problema che sottolineavo è il seguente:
io conosco il tuo id di sessione --> io sono te

La "debolezza" è di HTTP, perchè senza SSL anche le sessioni ASP (o di qualunque linguaggio server side) sono sniffabili, infatti anche i cookie sono visibili nel traffico di rete



P.s.
grazie Gianni per la fiducia (ovviamente eccessiva) :-)

[shishii]

Ciò che è stato detto è tutto vero. Io per ovviare (in genere uso questo sistema con Perl, ma vale con qualunque altro linguaggio) faccio in modo che il server compari l'ID di sessione con l'indirizzo IP con il quale è stato generato e che rifiuti l'accesso in caso di discordanza, in questo modo il pericolo dello sniffing è superato, infatti ammesso che l'attacker conosca l'ID dovrebbe anche spooffare il suo IP, ma in questo modo le risposte non perverrebbero a lui. In una LAN sarebbe ipotizzabile un attacco di man in the middle, ma ritengo che esistano metodi di attacco più comodi, su internet neanche questo sarebbe concretamente possibile.

Ciò non evita comunque che qualcuno possa sniffare i dati in transito, ma questo è un altro discorso.