CSFR: L’attacco meno conosciuto spiegato terra terra

di | 15 Settembre 2019

Chi magari legge i magazine di sicurezza informatica conosce cos’è un XSS o un SQL injection. Se non lo sai, leggi pure questo mio articolo. Ma c’è un terzo attacco, diffuso ma poco noto, il Cross Site Request Forgery. In sostanza si tratta di falsificare una richiesta al sito web.

Esempio

Poniamo caso che abbiate appena creato il sistema di pagamento di una valuta complementare. Dopo aver fatto il login ci sono varie funzioni, tra cui quella per inviare questa valuta complementare.

In pseudocodice il tutto è

SE userlogin = VERO
FAI
invia_denaro($POST_destinatario,$POST_cifra,mittente)
ALTRIMENTI

Il mittente è ovviamente il proprietario dell’account, mentre destinatario e cifra sono passati con un metodo post. Il problema? Manca una verifica dell’origine.

L’attacco

Poniamo che qualcuno sviluppi un codice scritto in tal modo, in simil-html:

<form action="banca_complementare.com/invia_danaro.php">
<input type="text" hidden name="destinatario" value="12345">
<input type="text" hidden name="cifra" value="500"> 
<button type="submit"> Clicca qui per vedere le partite a scrocco </button>
</form>

Il codice della valuta si troverà con una richiesta: Da parte sua sarà perfettamente legittima, l’utente è loggato, la richiesta è sensata e quindi viene eseguita. Ma è una richiesta truffaldina e falsa, visto che i due campi erano nascosti e l’utente ha solo cliccato per vedere le partite a scrocco, non per spedire 500 unità di conto valutario al conto del criminale.

Cosa ancora peggiore si può fare questo attacco senza alcuna interazione con l’utente!

Contromisure

Esistono due contromisure:

La prima è quella migliore teoricamente: Usare i referer, ossia dei campi che il protocollo HTTP compila automaticamente dicendo il sito d’origine della richiesta. Però molti programmi di privacy eliminano tali dati per non far conoscere al sito l’origine della richiesta, quindi chi usa tali programmi non potrebbe adoperare il servizio.

Si usano quindi dei token. In sostanza, quando si chiede la pagina di invio denaro si ottiene un lungo numero casuale valido per un tot (qualche minuto) che viene caricato in modo nascosto nel form. Solo se riceve un token valido e legato all’utente viene effettuata la transazione.

Un sito malevolo non ha alcuna possibilità di conoscere questo token e la sua lunghezza e breve durata rende quasi impossibile un attacco a forza bruta. Ergo, l’attacco CSRF diventa impossibile.

Se intendi sviluppare, però, ti consiglio di leggere bene il manuale del tuo linguaggio, perché esistono alcune imperizie di programmazione che, pur essendo solitamente veniali, consentirebbero al sito malevolo di ottenere un token valido.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *