Nell’articolo http://poyblog.wordpress.com/2010/04/14/sicurezza-del-linguaggio-javascript-metodologie-di-attacco/ avevo già accennato ad un tipo di attacco detto CSRF (Cross Site Request Forgery), che consiste nel “forgiare” sessioni di autenticazione attive grazie all’utilizzo di determinate URL cui un ignaro utente si sottopone.
In questo modo un hacker, contraffacendo la sessione di un utente può utilizzare la credenziali del malcapitato per eseguire delle operazioni in un’area privata , come un e-commerce per esempio.
Innanzitutto questa tecnica di attacco colpisce solo gli utenti che sono in un tale momento connessi ed autenticati.
Esiste comunque un metodo per rendere più complicato l’attacco CSRF , ovvero l’utilizzo di un token, generato pseudo-casualmente ed inserito nella variabile di sessione al momento della avvenuta autenticazione.
Tale valore dovrà poi essere presente in ogni pagina “privata” permettendo un confronto ad ogni visualizzazione fra il valore nella variabile sessione ed il valore della pagina corrente.
Quindi ogni pagina privata avrà un campo hidden del tipo:
<input type=’hidden’ name=’token’ value=’<?php echo $token ?>’/>
e a ogni caricamento di una pagina privata, prima di eseguire qualsivoglia operazione verrà eseguito un controllo del tipo:
if (isset ($_SESSION['token']) && isset($_POST['token']) && $_POST['token'] == $_SESSION['token']){
// Eseguo le operazioni della area riservata dato che il token è valido
}
Un altro attacco cui sono sottoposte le sessioni è il “session fixation”. In questo caso un utente potrebbe con l’utilizzo della variabile PHPSESSID forzare la propria sessione con una già esistente e associata ad un altro utente. Per superare questo inconveniente sarebbe innanzitutto conveniente cambiare il valore di default del cookie di sessione (da PHPSESSID a qualcos’altro ) e rigenerare in modo assiduo il valore della sessione con la funzione regenerate_id() soprattutto in fase di autenticazione
Session hijacking è un attacco grazie al quale un attaccante riesce a reperire l’ID di sessione di un malcapitato. In questo caso il controllo è più complicato, ma esistono delle tecniche di protezione che limitano l’efficacia di questo attacco. Per esempio se il server che emette la variabile di sessione controllasse anche l’ HTTP_USER_AGENT del client, nel caso in cui questo cambiasse durante una sessione, allora la sessione dovrebbe chiudersi e richiedere il login all’utente.
Purtroppo se l’attaccante sfrutta il medesimo browser il nostro controllo verrà superato.
