Era da tempo che non mi soffermavo a leggere con così tanta attenzione un articolo su PHP.
Sarà stato l'argomento, sarà stato che è in inglese, sarà stato per mille altri motivi, resta il fatto che vi consiglio caldamente di leggere l'articolo
pubblicato su Dev Shed.
Per quanti sono sempre di fretta, per quanti non masticano troppo l'inglese e per quanti non pensano che la sicurezza del proprio programma meriti 20 minuti di attenzione, ecco un riepilogo in breve.
L'articolo affronta il problema di sicurezza legato alle sessioni ed al salvataggio degli identificativi di sessione via Cookie.
Se l'applicativo non è sufficientemente preparato a fronteggiare attacchi di hacker, il rischio di Session Hijacking potrebbe non essere così remoto.
, la più teorica, viene affrontata una breve panoramica sui cookie di sessione e su come PHP gestisce la generazione di un identificativo univoco per ogni sessione.
Nella
si entra nel dettaglio di come avviene, di norma, un tentativo di Session Hijacking.
Si accenna alla possibilità che venga intercettato il traffico del browser ma il focus è soprattutto sui cross-site scripting e sull'esposizione pubblica di dati di sessione.
Compaiono alcuni primi suggerimenti per difendersi dal problema, approfonditi nelle pagine successive.
Nello specifico, l'autore menziona la funzione session_set_save_handler() che consente di scrivere un gestore delle sessioni personalizzato.
Questo consente, ad esempio, di crittare il contenuto dell'ID inviato oppure ricorrere a soluzione radicalmente differenti.
viene mostrato cosa potrebbe succedere nel caso si inizializzino in modo "manuale" delle sessioni. Si dimostra la pericolosità del session fixation attack sottolineando quanto sia importante ricorrere, ad esempio, alla forzatura della rigenerazione di un ID all'avvio di una sessione.
Ecco un esempio di come risulta utile l'uso di session_regenerate_id().
<?php
session_start();
if (!isset($_SESSION['initiated']))
{
session_regenerate_id();
$_SESSION['initiated'] = TRUE;
}
?>
Forzando la rigenerazione della sessionID si previene la possibilità che un malintenzionato causi la generazione di un ID conosciuto ad esempio portando l'utente sul sito grazie ad un link costruito di proposito, come questo www.html.it/mypage.php?PHPSESSID=1234.
L'autore si premura di sottolineare quanto sia fondamentale integrare una rigenerazione dell'ID ogni qual volta si cambino i privilegi dell'utente, per evitare che un malintenzionato possa acquisire maggiori privilegi semplicemente registrandosi al sito e poi tentando di bypassare i controlli sulla sessione.
Ci avviamo verso la
.
In questa pagina si accenna alla consistenza della sessione, alla necessità di aumentare la potenza degli identificativi univoci forniti.
Il primo suggerimento è quello, ad esempio, di basarsi sul comportamento utente ed identificare anomalie.
Molto interessante l'esempio. Avete mai pensato di registrare la user agent del browser utilizzata più frequentemente dall'utente e nel caso l'utente acceda da una user agent differente mostrare nuovamente l'inserimento di password?
La seconda soluzione suggerita è il passaggio di un identificativo univoco e casuale nelle URL del sito.
Personalmente sconsiglio questa pratica se il vostro obiettivo è anche condurre un'attività di Search Engine Optimization sulle pagine dell'applicativo.
Tuttavia, vorrei concludere questa mia panoramica lasciandovi un suggerimento, ovviamente tratto dall'articolo, per generare un token facilmente univoco.
$token = md5(uniqid(rand(), TRUE));
