Gestioni session sicure

[.Kurt]

Se php.ini imposta di default true session.use_only_cookies, non si pone più il problema del session hijacking e quindi è superfluo la rigenerazione dell'SID o sbaglio?

No. Il problema del session hijacking non si risolve assicurandosi che session.use_only_cookies sia abilitata. Sicuramente passare il token della sessione attraverso i cookie è una pratica molto più sicura del passarlo attraverso querystring. Ma è qualcosa che non vedo dal 2005, non è un problema non merita attenzione. A patto di una configurazione sconsiderata dei parametri session.* i valori di default vanno bene così come sono.
Ritornando al session hijacking, il problema rimane e va affrontato. Ci sono altri modi per l'attaccante di ottenere il token di sessione della vittima. Il più banale di tutti è: lo sparo a caso e indovino. Per prevenirlo, una delle soluzioni è quella di rigenerare il token. Se ti interessa l'argomento: https://www.google.it/?gws_rd=ssl#q=...+hijacking+php

Per quanto riguarda il nome della sessione: no, nessuno ostacolo in più. Puoi scegliere quello che preferisci o lasciare quello di default. E' un parametro di personalizzazione. Può essere comodo se hai due pagine e vuoi aprire due sessioni differenti. Non ha niente a che fare con la sicurezza.

[zacca94]

Guarda da ex bug hunter spero di risolvere il tuo dilemma.

Ma è qualcosa che non vedo dal 2005, non è un problema non merita attenzione. A patto di una configurazione sconsiderata dei parametri session.* i valori di default vanno bene così come sono.

Parzialmente corretto, in moltissimi software il token passa ancora via get per alcune necessità (quale il log-out, altrimenti uno mette come foto nella firma <img src="http://sito.it/logout.php"> e slogga tutti gli utenti che visualizzano il suo profilo e topics in cui ha scritto commenti, o addirittura come query string nel pannello amministrativo in quanto moltissimi campi action vengono svolti grazie ad istruzioni GET (come l'eliminazione di una categoria).

Il più banale di tutti è: lo sparo a caso e indovino. Per prevenirlo, una delle soluzioni è quella di rigenerare il token. Se ti interessa l'argomento: https://www.google.it/?gws_rd=ssl#q=...+hijacking+php

Corretto, ma comunque sempre parziale perchè previeni, si, la session hijacking, ma rimani comunque con molte altre vulnerabilità.

In mio consiglio personale? Non utilizzare le sessioni di php a meno che non le imposti in maniera particolare con: http://php.net/manual/it/class.sessionhandler.php

Anzi, per completezza ti fornisco i campi e la metodologia che uso io per prevenire il furto della sessione.

DROP TABLE IF EXISTS `#__sessions`;


CREATE TABLE `#__sessions` (
    `sess_id` char(64) NOT NULL DEFAULT '',
    `sess_ip` varchar(50) NOT NULL DEFAULT '',
    `sess_user_agent` tinytext NOT NULL,
    `sess_time` int(10) unsigned NOT NULL DEFAULT '0',
        `sess_get_key` char(10) NOT NULL DEFAULT '',
        `sess_post_key` char(32) NOT NULL DEFAULT '',
    PRIMARY KEY (`sess_id`),
    KEY `sess_ip` (`sess_ip`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

Ovviamente aggiungendo il campo che collega la sessione all'account dell'utente e fare la verifica sui campi sess_ip, sess_user_agent e sess_id:

SELECT s.* FROM sessions s WHERE s.sess_key = %s AND s.sess_ip = %s AND s.sess_agent = %s LIMIT 1

Importante: il sess_id deve essere salvato nei cookie, non passato via get.

In questa maniera anche se qualcuno si impossessa della sessione, essa è inutilizzabile (a meno che l'attaccante non sia connesso anche sulla tua wifi e utilizzi anche il tuo stesso browser compresa la versione, ma in questo caso penso che la sessione del sito è la cosa che meno ti dovrebbe preoccupare).

Utilizzare la verifica del sess_get_key per azioni quali il logout o manipolazione di dati "non importanti", e verificare il sess_post_key per i form post. La motivazione per cui ci sono due chiavi diverse per il get e il post è che anche se disgraziatamente ottiene un link contenente la sessione, al massimo ti può disconnettere una volta dal sito.

La motivazione per la quale il token post è diverso dalla sessione, è perchè altrimenti se te la rubasse potrebbe eseguire attacchi di tipo csrf (vedi google).

Quindi facendo un breve riepilogo:
- Sei vulnerabile ad attacchi hijacking o xss -> ti fotte i cookie con la sessione -> non ci fa nulla perchè il tuo ip e user agent sono differenti dai suoi (e anche se modificasse l'user-agent non potrebbe fare lo stesso con l'ip);
- Gli passi un link che utilizza il token per le azioni get -> pazienza, ti disconnette una volta


L'unico modo per fregarti è che apri il sorgente della pagina e gli passi volontariamente il token con il post key (che si trova sempre in un campo input hidden: impensabile).

Comunque fare ulteriori non controlla mai, quindi come consigliato dal buon .Kurt, rigenera la sessione durante il log-in e cancellala dai cookie e dal database dopo il logut o dop tot tempo di inattività.