Un utente autenticato (si badi bene: autenticato), data un'iniezione di "codice CSRF" in un programma/sito Web, potrebbe esser portato a fare qualsiasi cosa il cracker voglia, una volta visualizzata la pagina violata, e nemmeno se ne accorgerebbe (salvo non riuscire a visualizzare un'immagine: ben poco)!
Ad esempio potrebbe cancellare tutti i suoi messaggi personali:
<img src=" Sito_A?del=y&from_id=1&num=1000">
O potrebbe cancellare qualche altro record importante da database, magari non suo - nel caso l'utente avesse particolari diritti/privilegi.
Questi esempi valgono nel caso in cui si sia riusciti ad introdurre codice direttamente nel sito attaccato. Lo stesso sito - lo ripeto - nel quale l'utente vittima sia autenticato ed abbia dati privilegi.
Ma c'è di più: non necessariamente la pagina violata deve far parte del programma/sito attaccato: è sufficiente che l'utente, autenticato sul Sito_A (sito attaccato), visiti una pagina malevola sul Sito_B (sito controllato dal cracker), la quale pagina rindirizzi al Sito_A con query string (o POST vars) ad hoc. La propagazione della sessione sul sito attaccato avviene infatti ugualmente, dacché il browser invia, come sempre, il cookie contenente il SID al server. Nulla al riguardo è variato: è il browser usato che gestisce i cookies.
I CSRF sono quindi vulnerabilità che sfruttano gli utenti autenticati per far loro compiere (inconsapevolmente) una serie di azioni (generalmente nefaste), semplicemente "visualizzando" un'immagine o simile.
L'attacco può essere eseguito anche visualizzando mail in formato HTML: in questa logica sono particolarmente vulnerabili ai CSRF i programmi che utilizzano sistemi di auto log-in (non eseguono il log-out).
Tramite l'uso di URL rewriting, infine, è possibile che la pagina puntata dal tag <img> sembri effettivamente un'immagine remota, pur essendo uno script. Non approfondirò ulteriormente questo tema, il concetto è già chiaro.
Da ultimo, notiamo come il cracker deve conoscere la struttura del Sito_A, in particolare il nome degli script e la lista dei (di alcuni) parametri da passare, al fine di attaccarlo.
Come non difendersi
Una prima idea per la difesa potrebbe essere di richiedere all'utente conferma tramite requester JavaScript. Beh, l'idea non è intelligente (ho usato un eufemismo), in quanto il cracker bypasserà questa richiesta puntando direttamente allo script PHP puntato dal JavaScript di conferma stesso.
Come difendersi
Posto che non sia possibile iniettare codice in Sito_A, dacché sono state seguite scrupolosamente le direttive già esposte, per difendersi da questa tipologia di attacchi è necessario che Sito_A accetti come valide unicamente le richieste provenienti da esso stesso. Come fare?
Controllo del referer
Si può usare il controllo lato server del referer tramite $_SERVER['HTTP_REFERER']. Il referer è uno header HTTP, impostato dallo stesso browser, che indica l'indirizzo della pagina Web da cui proviene il visitatore. Se questo coincide con una pagina interna al Sito_A, la fonte del link può esser considerata sufficientemente sicura, poiché a tutt'oggi non esiste modo - per lo meno chi scrive non lo conosce - per indurre un browser standard non sotto il proprio controllo diretto a modificare il referer. Un controllo possibile è il seguente:
if (isset($_SERVER['HTTP_REFERER']) && $_SERVER['HTTP_REFERER']!="")
{
if (strpos($_SERVER['HTTP_REFERER'],$_SERVER['HTTP_HOST'])===false)
{
// Qualcosa non quadra: uscire dal programma, creare file di log, etc etc.
}
}
Uso di token
Aggiunta di token (stringhe in GET, ad esempio il SID, o variabili nascoste in POST) e loro verifica in fase di elaborazione. Ad esempio, ogni operazione delicata richiamabile via GET, dovrebbe esser linkata in questo modo:
Sito_A/cancella_tutto.php?SID=y23gygd26g63dgd38d99jsa&id=4
anzichè in quest'altro:
Sito_A/cancella_tutto.php?id=4
naturalmente confrontando SID in GET e SID di sessione. È vero, passare il SID in GET non è mai una bella idea: possiamo quindi spedirlo al server via hidden var di una form di un'ulteriore pagina di controllo, od operare direttamente via form Web.
Per una sicurezza dignitosa, questi metodi dovrebbero essere andare ad affiancare (e non sostituire!) una connessione protetta SSL.