In un precedente articolo, ho introdotto il concetto di CSRF, questa volta ci occuperemo di ovvero fornire i concetti di base della protezione contro questo tipo di attacchi. 
Ci tengo a precisare che anche questo articolo conterrà metodi di base per la protezione delle proprie applicazioni, in quanto la scienza dietro gli attacchi è davvero molto sviluppata al momento.Abbiamo visto che un attacco di tipo CSRF consiste nel fare in modo che la vittima invii delle richieste inconsapevolmente, sfruttando le sue credenziali. Riportiamo brevemente un esempio per riprendere le fila del discorso: Mentre visitiamo la pagina “posta in arrivo” del nostro account email non protetto, apriamo un altra scheda del browser, capitando in un sito malevolo creato ad hoc per attaccare la pagina del nostro email service provider. Cliccando su un semplice link del tipo:
<a href=”happy_page.php” onClick=”document.send_mail_form.submit()”>Click</a>
e magari avendo semplicemente (ci sono modi di gran lunga migliori per inviare richieste POST) predisposto il seguente form nascosto:
<form name=”send_mail_form” method=”POST” action=”www.unsafe-email-service.com”>
<input type=”hidden” name=”receiver” value=”randomReceiver1”>
<input type=”hidden” name=”receiver” value=”randomReceiver2”>
<input type=”hidden” name=”receiver” value=”randomReceiver3”>
..
<input type=”hidden” name=”receiver” value=”randomReceiverN”>
<input type=”hidden” name=”object” value=”Object”>
<input type=”hidden” name=”text” value=”randomText”>
</form>
comporterebbe l’immediato e totalmente involontario invio delle email con il nostro account di posta elettronica.
Come possiamo mitigare il rischio CSRF ,quantomeno, rendere gli attacchi meno scontati e facilmente implementabili? Un metodo largamente usato, in quanto offre un buon rapporto sicurezza/facilità di implementazione è quello dei Token.
Un token è una stringa di testo che funge da validazione per le richieste che inviamo alla nostra applicazione e deve essere correlata alla sessione dell’utente.
Potremmo sintetizzare il concetto nei seguenti passi: Creo il token, lo salvo nella sessione e lo richiedo per validare ogni input utente. Se il sistema rileva una richiesta POST non accompagnata dal corretto token ci permetterà di riconoscere un probabile tentativo di attacco e di interrompere l’esecuzione.
Parte 1: creiamo il token.
Presupponendo che la sessione sia già stata inizializzata
<?php
$token = sha1(uniqid(rand(),TRUE));
$_SESSION['token'] = $token;
?>
Parte 2: generiamo il form
<form name=”myForm” method=”POST” action=”myPage.php”>
<input type=”hidden” name=”token” value =” <?php echo $_SESSION['token']; ?> “ />
<input type=”text” name=”myText” />
<input type=”submit” value=”invia”>
Parte 3: controlliamo la validità della richiesta
<?php
if (!isset ($_POST['token'] OR !isset ($_SESSION['token'] OR $_POST['token'] != $_SESSION['token'] OR)
{
//errore! Interrompere l’esecuzione
} else {
//Il token è validato, possiamo procedere
}
?>
n questo modo costringiamo l’attaccante a scoprire il token assegnato alla sessione della vittima, inoltre questo fa si che l’attacco colpisca soltanto quell’utente, o comunque costringe l’attaccante a replicare il token di ogni vittima, affinchè le richieste artificiali da lui create bypassino il sistema di controllo.
Come migliorare questo approccio?
Come ho già detto, questo metodo non garantisce la sicurezza assoluta, quindi se state cercando di mettere al sicuro i form di un sito di e-commerce, non vi consiglierei mai di fermarvi a questo livello di validazione; possiamo però migliorare il nostro codice di controllo in diversi modi. Vediamone alcuni.
Generiamo un token per ogni form della pagina che l’utente visualizza, così da aumentare la complessità del problema, potremmo dire che creare un token per ogni richiesta dell’applicazione sarebbe un’ottima cosa.
Associamo un tempo di validità del token dopo il quale non verrebbe più considerato valido:
<?php
$token = sha1(uniqid(rand(),TRUE));
$_SESSION['token'] = $token;
$_SESSION['token_time'] = time();
?>
e successivamente controlliamo che non sia passato troppo tempo dalla creazione del token, altrimenti lo consideriamo scaduto :
<?php
if (!isset ($_POST['token'] OR !isset ($_SESSION['token'] OR $_POST['token'] != $_SESSION['token'] OR)
{
//errore! Interrompere l’esecuzione
} else {
$token_time = time() – $_SESSION['token_time'];
//Facciamo in modo che la durata massima del token sia di 10 minuti
if ($token_time < 600)
{
//interrompiamo l’interruzione informando che la pagina è scaduta
}
//Il token è validato, possiamo procedere
}
?>
Concludo proponendovi una riflessione: anche la miglior difesa contro attacchi di tipo CSRF può essere superata se non vi affianchiamo una ottima difesa per gli attacchi di tipo XSS, in quanto questi ultimi potrebbero essere utilizzati come “apripista” verso le nostre difese.
la maggior parte dei quali realizzabili da chiunque e questo non fa altro che aumentare i problemi di sicurezza nelle grandi applicazioni web: anche il più impreparato degli script kiddies 
).
