Ho parlato a lungo ed abbastanza dettagliatamente del cross site scripting, ora invece vi presento una tecnica dal nome simile ma dall’efficacia maggiore per portare a termine certi tipi di attacchi: i famigerati CSRF attacks (o XSRF).
Il nome della tecnica è eloquente: si tratta di creare delle richieste ad hoc da inviare ad una applicazione sfruttando le autorizzazioni di un utente ‘trusted’, ovvero sfruttando la sua identità!!
Notiamo subito una differenza sostanziale tra XSS e CSRF: con i primi, ad essere sfruttata è la fiducia che l’applicazione ripone nell’utente attivo, che invece di svolgere le sue normali operazioni sfrutta le falle dell’applicazione stessa; Nel caso del CSRF invece, ad essere sfruttata è la fiducia che l’utente ripone in un certo applicativo, che invece lo sfrutta (non è esattamente l’applicativo che sfrutta l’utente, ma il programmatore che lo ha sviluppato!! altrimenti l’applicazione sarebbe una specie di Agente Smith di Matrix XD).
Ma come inviare delle richieste ad un server?? ci sono zilioni di modi 
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 potrebbe portare a termine un attacco del genere!!
Vediamo ora un semplice esempio pratico:
L’azienda Pancom, mette a disposizione dei suoi utenti un certo numero di inviti, da inviare ai propri amici per permettere ad essi di unirsi alla comunity di bloggers altrimenti riservata.
Ogni utente ha nella propria dashboard, un form composto da una textbox in cui va inserito l’indirizzo email del proprio amico a cui si vuole donare l’accesso a Pancom, e chiaramente un pulsante di submit.
Come poter sfruttare gli inviti dell’utente Mattia che non sta attento alle sessioni e naviga su internet con moltissime tab aperte senza curarsi della sua sessione in Pancom.com??
Se i programmatori Pancom non sono stati attenti, no cè niente di più semplice!!
Dopo aver analizzato il form di invio degli inviti (pensate a quello di Gmail), il cui codice possiamo immaginare essere simile al seguente:
<form name="invita” method=”GET” action =”invita.php”>
<input type=”text” name=”email”>
<input type=”submit” value=”Invita!”>
</form>
Ne risulta che la richiesta da inviare al server sarà una del tipo:
http://utenteLoggato.pancom.com/invita.php?email=indirizzo@maligno.com
Per fare in modo che l’utente loggato invii al posto nostro una richiesta del genere sarà sufficiente che visiti una pagina web creata ad hoc dall’attaccante. e contenente un tag come un link ad uno stylesheet, una immagine o una tag META:
<img src=”http://utenteLoggato.pancom.com/invita.php?email=indirizzo#maligno.com”>
<link rel=”http://utenteLoggato.pancom.com/invita.php?email=indirizzo#maligno.com”>
Anche una banale immagine di sfondo che viene caricata con il corpo della pagina html innesca il meccanismo sopra citato!!
Capirete dunque che un attacco del genere (filtraggio degli url,utilizzo di token sicuri, controllo del referrer… mmm ok ne parlerò più avanti ), può essere portato a termine in pochissimo tempo e senza delle conoscenze specifiche di SQL, PHP, Javascript o qualsiasi altra code injection esistente :S
).
