In questo articolo parleremo di un attacco web che può risultare devastante: rientra nella categoria di attacchi SideJacking e viene conosciuto anche come CSRF o XSRF.
Questa tipo di attacco, permette ad un malintenzionato di effettuare operazioni al posto della vittima. Che ti di operazioni parliamo? Potenzialmente, a seconda del sito vulnerabile (e delle sue funzioni ovviamente) può a nome della vittima:
- Comprare un oggetto
- Aggiungere un utente nel gruppo degli amministratori
- Cancellare articoli/post/immagini/commenti
- Inviare messaggi privati
- Cambiare la password e l’email associata
- Trasferire soldi
- Creare articoli o posts
- Ecc…
Insomma l’attaccante potrà di fatto, preparando a puntino precedentemente del codice ad Hoc, prendere il posto dell’ utente per effettuare una o più azioni in un determinato servizio vulnerabile di CSRF.
Oltre ad essere molto pericolosi (come avrete capito da voi), gli attacci CSRF sono anche difficili da individuare: questo perchè sembrerà che l’utente svolga operazioni di routine, che non desteranno sospetti finchè non sarà troppo tardi.
Come ti attaccano
Vediamo quindi, i modi principali con cui viene sfruttato questo tipo di attacco: ricordate però, che un cracker molto furbo sicuramente cercherà di utilizzare un mix di queste tecniche (o comunque tecniche simili) in modo da aumentare le probabilità di riuscita.
I metodi principali sono:
- Utilizzo della ingegneria sociale, cercando di ingannare la vittima;
- Sfruttando una XSS, tecnica che abbiamo visto in precedenza;
- Sfruttando il tag IMG.
Per quanto riguarda l’ingegneria sociale, ne parleremo meglio in un’ altro articolo dedicato; perciò vediamo come sfruttano le XSS per compiere azioni al posto nostro.
Usando le XSS
Facendo brevemente un’ accenno a questa tecnica, sfruttando una mancanza di controllo di un input è possibile iniettare del codice javascript all’ interno di una pagina.
Premesso questo, un esempio di attacco CSRF sarebbe quello di far cliccare all’amministratore del sito, un link di questo tipo:
“`http://sitobuggato.it/guestbook.php?sign=
<iframe src='javascript:window.location="http://www.vittima.com/amministrazione.php?edituser=informaticalab&addgroup=administrator";' height='0' width='0' style='border:0;' />
“`
In questo esempio, la pagina buggata da XSRF è “amministrazione.php”, e in pratica in questo caso viene aggiunto l’utente ‘informaticalab’ nel gruppo degli amministratori.
Per farlo, viene creato un iframe di dimensioni 0x0 e con bordo 0 (invisibile) che appunto carica la pagina “http://www.vittima.com/amministrazione.php?edituser=informaticalab&addgroup=administrator” ed esegue le azioni.
Nel caso in cui l’ XSRF sia su una richiesta POST, ecco un esempio di come potrebbe essere sfruttata:
pagina.html:
<html>
<body>
<form action="" method="post" id="formid">
<input type="hidden" name="attaco" value="valore" />
</form>
<script>document.getElementById('formid').submit();</script>
</body>
</html>
Basterà salvare la pagina e in un qualsiasi host e sfruttare nuovamente l’ XSS di poco fà, per fare in modo che venga eseguita l’azione preparata precedentemente nella nostra pagina.
Inniezione sfruttando il tag IMG
Un’altro modo per sfruttare questa potente tecnica, è quello di utilizzare il tag IMG di HTML: infatti, non serve per forza un iframe per effettuare il nostro attacco, ma possiamo utilizzare semplicemente il tag html IMG:
<img src="http://www.vittima.com/amministrazione.php?edituser=informaticalab&addgroup=administrator">
Una nota che definiremmo divertente: una bulletin board, più informalmente un forum, programmato male potrebbe permette di utilizzare come avatar o come firma pagine di questo tipo che, come risulta ovvio, non sono immagini. Ti immagini se rispondesse ad un post molto visitato cosa succederebbe a tutti gli utenti di quel forum?
Al riparo da questo attacco
Come difendersi da questo tipo di attacco? Beh, forse un’idea sarebbe quella di impostare tutti i nostri form in modo che effettuino richieste POST: come già visto però, non è un rimedio inoltrepassabile.
Cosa ci inventiamo quindi?
Ecco la furbata: se sbirciate nei form dei siti più “grandi” lo troverete di sicuro, il token.
Il token è in sostanza un codice che viene associato alla sessione dell’ utente: quando viene eseguito un form, viene controllato il token.
Vediamo quindi come implementarlo nel nostro codice:
session_start();
if( !isset( $_SESSION['token'] ) ) //Se non è stato settato nessun Token
{
$token = md5( rand() );
$token = str_split( $token, 10 );
$_SESSION['token'] = $token[0]; //Settiamo il token
}
Quello che dovremo fare poi, è sostanzialmente includere il token quando andiamo a generare la pagina del form.
In parole povere:
<input type='hidden' name='token' value='<?=$_SESSION['token']?>' />
Dovrà essere aggiunto nel form che vogliamo inviare.
Infine, aggiungiamo alla pagina che riceve i dati un controllo sulla presenza del token usando per esempio questo codice:
if( $_POST['token'] == $_SESSION['token'] )
{
/* Token is valid, continue */
}
Questo tipo di tecnica, non difficile da effettuare e da trovare, è stata un tormento anche per CMS come WordPress e Joomla quindi non è da sottovalutare.
