Gestioni session sicure

[Vash SD]

Salve, ho trovato, dopo aver letto la guida sulla sicurezza in PHP, in rete questo script per inizializzare una session sicura. Solo che non riesco a capire il significato di alcuni passaggi.

function sec_session_start() {
        $session_name = 'sec_session_id'; // Imposta un nome di sessione. Ma di quale? Di una nuova che voglio creare o cambia il nome della SID?
        $secure = false; // Questo serve se hai una SSL. Utilizzato dopo.
        $httponly = true; // Impedisce ad un JS di avere il mio SID, credo. Utilizzato dopo.
       ini_set('session.use_only_cookies', 1); // Per evitare di impostare SSID tramite GET PHPSESSID
       $cookieParams = session_get_cookie_params(VOID); // PHP.net: "restituisce un con le informazioni sul cookie di sessione corrente". Ma di quale session? Se io ne avessi più di una? O Cerca nel php.ini le impostazioni dei cookie?
       session_set_cookie_params(
        $cookieParams["lifetime"],
        $cookieParams["path"],
        $cookieParams["domain"],
        $secure,
        $httponly
       ); // Imposta queste opzioni alla sessione (che è un cookie) che sto creando
       session_name($session_name); // Imposta il nome     
       session_start(); // Avvia la sessione php.
        session_regenerate_id(); // Rigenera la sessione e cancella quella creata in precedenza.
} 

Ho espresso accanto i miei dubbi. Se ho capito bene, questa funzione serve solo per inizializzare una session ID più sicura, poi il resto delle sessioni le inizializzi allo stesso modo nelle altre pagine con

session_start();
$_SESSION['prova'] = "prova"; 

Giusto? Quindi basterebbe richiamare questa funzione giusto nel login quando si è certi di aver autenticato l'utente e tutte le sessioni successive saranno più sicure?
Grazie mille!
Grazie a tutti.

[.Kurt]

"Sessioni sicure", cosa vorrebbe significare? Come al solito non esistono funzioni pronte all'uso che forniscono un livello di sicurezza in più solo per il fatto che sono lì. Accontentiamoci di sapere il come e il perché di quello che inseriamo nelle nostre pagine, la sicurezza viene dopo.

Quindi per rispondere alla vera domanda, "cosa fa sec_session_start()?": si limita a modificare i parametri http://php.net/session.configuration con valori più opportuni, per far fronte a configurazioni strane nel tuo php.ini. Lo fa anche male. (Ad esempio session_name dovrebbe essere chiamato prima di session_set_cookie_params) La domanda più pertinente ora è "questa nuova configurazione è per me vantaggiosa?". No, non direi. Quei pochi parametri che vengono cambiati runtime corrispondono ai valori di default che trovi nel php.ini. Cambiare il nome di sessione è una misura di sicurezza in più? Proprio no. L'unica buona idea è quella di settare il cookie di sessione usando l'attributo httponly. E' cosa buona, ma non necessaria. Cosa che puoi fare modificando il relativo parametro, http://php.net/manual/it/session.con...ookie-httponly .

L'unica parte di quella funzione che ha realmente a che fare con la sicurezza è session_regenerate_id(), ma a cosa serve e come dovrei usarla? Per quello ti rimando alla documentazione. Sicuramente non la userei ogni volta che avvio la sessione.

[Vash SD]

Ciao Kurt, grazie per le risposte. Il mio obiettivo era proprio capire, dopo aver letto la guida sicurezza su php postata su HTML.it, perchè utilizzava quelle impostazioni e cosa realmente facessero (la documentazioni di php.net mi rimane sempre un po' indigesta, poco comprensibile e ostica, ma capisco che è per colpa di una mia non completa conoscenza in questo campo. Il tuo link sulla configurazione della session runtime è stato davvero utile. Ho giusto una domanda:
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?
Se cambio il nome a session.name che di default è PHPSESSID può risultare un ostacolo in più ad un eventuale cracker che volesse (ammesso che use_only_cookies sia 0) impostare un determinato SID ad un utente per un furto di identità. Giusto? Certo, un ostacolo quasi inutile, dato che deve comunque loggarsi anche il cracker per far sovrascrivere il proprio file sessione sul server da un altro utente. E quindi sarebbe in grado di leggere il nome del session.name del cookie dal browser, riinserendo la GET corretta. Quindi totalmente inutile direi...

[.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à.

[.Kurt]

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:

La strada della verifica dell'useragent e dell'ip come ulteriore misura di controllo per verificare l'appartenenza più o meno leggittima dell'utente alla propria sessione è una strada già battuta. Te la sconsiglio principalmente per due motivi:
- L'useragent non è un dato affidabile: se in qualche modo riesco ad ottenere il token della sessione, sicuramente riesco ad ottenere anche l'useragent. E anche se non riesco ad ottenerlo, posso sempre indovinarlo.
- Il controllo dell'ip è problematico, evitalo se possibile. Se un utente loggato legittimamente è connesso attraverso un proxy server (come succede in molte università e in molti uffici) allora otterrai un falso positivo dalla tua applicazione, che considererà la sessione illegittima anche se non lo era.

La soluzione per una autenticazione sicura è banale: metti tutto dietro https.

[zacca94]

ovvio che non ho inventano nulla di nuovo e che l'user agent generalmente venga grabbato insieme a tutto il resto, come è ovvio che bisogni almeno provare a lavorare l'ip, comunque se hai valide soluzioni alternative sono molto propenso a prenderle come spunto...

[Vash SD]

Grazie mille, avevo letto già della verifica parallela sull'user-agent e dell'IP. Il problema dell'IP come avete già elencato è quello di una rete comune, segnandomi l'utente come falso positivo. Ti ringrazio per il token per get e post che mi sembra veramente efficiente ! Ancora grazie, questo argomento è davvero interessante

Edit: oltretutto presumo che in determinati casi il controllo dell http_referer e host siano un altro livello do sicurezza in più