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.
Pingback: CSRF come ti altero info riservate nel sito - betaingegneria.it