Php salva i dati relativi alle sessioni tramite la serializzazione, ovvero l’array $_SESSION viene linearizzato e salvato in un supporto come un file o un record di un database.
Il comportamento di questa caratteristica di php può essere controllato da due variabili di configurazione di php:
Session.save_handler: indica a php come viene salvata la sessione e in quale supporto, il valore di default è file (quindi php out of the box scrive i dati di sessione su un file) mentre gli altri valori possibili son user, mm e sqlite.
Session.save_path: indica la directory in cui le sessioni saranno salvate e mantenute. Il valore di default è /tmp (la mia installazione di xampp ad esempio salva in C:\xampp\tmp).
Al giorno d’oggi la maggior parte dei servizi di hosting forniscono un servizio di hosting condiviso, molto gettonato perchè abbassa di molto i costi sia per la gestione che per l’utente finale. Un setup del genere però, in cui diverse web application girano sullo stesso server in cui tutte le sessioni vengono salvate nella stessa directory porta degli enormi problemi di sicurezza, vediamo un esempio:
Un cliente del servizio di hosting ha due applicazioni web che girano sullo stesso server. Entrambe fanno uso di sessioni ma sono destinate ad utilizzi diversi; entrambe fanno uso di form per inserire dati nel sito ma la prima delle due applicazioni salva nella sessione anche l’input utente non filtrato, mentre la seconda mantiene in sessione soltanto dati filtrati.
Poiché le due applicazioni condividono lo spazio in cui vengono salvate le sessioni un possibile attacco consiste nel:
- Popolare la sessione della prima applicazione (che non filtra l’input) con dati creati ad hoc
- Modificare il cookie della sessione relativa all’applicazione 2 inserendo il session id dell’applicazione 1 (questa sessione contiene dati non filtrati)
- L’attaccante utilizza i dati non filtrati dell’applicazione 1 per danneggiare l’applicazione 2.
Altro scenario ancora più pericoloso riguarda la condivisione di spazio di salvataggio delle sessioni e dell’implementazione dell’applicazione: capita spesso che i servizi di hosting php mettano a disposizione alcuni CMS per facilitare l’avvio di un sito web, ecco quali sono i rischi:
- L’attaccante è un utente dell’applicazione 1 con certi privilegi, magari è un editor o un moderatore. In particolare l’applicazione 1 si apoggia su un CMS.
- L’applicazione 2 condivide la directory di salvataggio delle sessioni (sempre lo stesso servizio di web hosting un pò farlocco) ma in più si appoggia allo stesso CMS dell’applicazione 1.
- L’attaccante logga nella applicazione 2 come utente senza privilegi, copia il session id dell’applicazione 1 nel cookie dell’applicazione 2 e si ritrova loggato con gli stessi privilegi che aveva nell’applicazione 1 (perchè le due applicazioni fanno uso dello stesso sistema di gestione dei ruoli).
Vediamo quindi che potenzialmente, se un servzio di hosting, ospitante un sito non protetto, non si occupasse di dividere le directory dedicate alle sessioni, i problemi di sicurezza del sito non protetto potrebbero ripercuotersi anche sugli altri.
Ne consegue che la precauzione necessaria al fine di evitare queste falle di sicurezza è la divisione delle directory di salvataggio delle sessioni in applicazioni, così che ogni applicazione avrà la propria directory, ad esempio:
/tmp/applicazione1
/tmp/applicazione2 ecc..
Se il servizio di hosting in cui ci appoggiamo non ha già pensato a modificare la variabile del php.ini possiamo provare ad aggiungere la seguente riga di codice nella nostra applicazione:
ini_set(‘session.save_path‘, ‘/tmp/nostra_app‘);
Incrociando le dita e sperando che la funzione ini_set non sia inibita dal servizio di hosting.
Un’altra soluzione è quella di aggiungere una variabile all’interno della nostra sessione che identifichi univocamente la nostra applicazione, ad esempio:
session_start();
if (!isset($_SESSION['application']) || ((string)$_SESSION['application'] !== ‘application_1′)) {
session_regenerate_id();
$_SESSION = array(‘application’ => ‘application_1′);
}
In questo modo il cookie modificato dall’attaccante sarà diverso dai cookie della nostra applicazione e l’id di sessione viene rigenerato.
Un metodo forse ancora più efficiente per gestire il mantenimento delle sessioni nel web server consiste nell’implementazione manuale delle funzioni di session storaging tramite la funzione set_session_save_handler(): essa permette di definire quali funzioni si occupano delle diverse operazioni di gestione delle sessioni.
La settimana scorsa è spuntato un 
