Cerchiamo di capire assieme come funziona questo attacco.
L'attacco consiste nel convincere un utente di un sito o servizio web ad eseguire delle azioni non volute sul sito nel quale è al momento già autenticato.
Si tratta in pratica di trarre in inganno l'utente. Se la vittima dell'attacco è un utente normale senza particolari privilegi sull'applicazione questo può essere indotto a compiere azioni indesiderate, ma se l'utente è un amministratore del sistema, e perciò dotato di privilegi particolari, le cose si complicano per l'intera applicazione.
Proviamo a fare un esempio.
In primo luogo l'hacker crea un sito simile a quello di un servizio web, magari realizzando una copia di un sito di una banca on line. Niente di più semplice, è sufficiente clonare un sito attraverso l'uso di strumenti automatici come per esempio HTTrack o SiteSucker e poi apportare le modifiche che occorrono per il proprio scopo.
A questo punto l'hacker diffonde il link al sito malevolo cercando di invogliare i possibili utenti.
Un utente poco attento, precedentemente autenticatosi sul sito o servizio web legittimo, clicca sul link malevolo creato dall'hacker. In questo istante le credenziali dell'utente, salvate nei cookies del browser, vengono rubate ed utilizzate dall'hacker per fare una richiesta al sito web, richiesta che potrebbe essere per esempio un bonifico sul conto dell'hacker.
L'utente purtroppo non può rendersi conto di cosa sta accadendo. Si accorgerà solo, quando verificherà il suo conto, di aver meno soldi di quanto previsto.
Questo tipo di attacco, come abbiamo visto, presuppone che l'utente sia già connesso al sito o servizio reale, il che limita le possibilità dell'hacker.
L'attacco si basa sul fatto che un sito si fidi delle operazioni compiute da parte di un utente già autenticato, utilizzando i cookies di sessione per l'autenticazione, senza verificare di volta in volta che sia effettivamente l'utente a svolgere l'operazione.
Esistono diversi metodi per mitigare questa vulnerabilità. Vediamone alcuni.
- E' possibile aggiungere ad ogni richiesta HTTP un token unico di sessione, chiamato di CSRF Token, che il server utilizzerà per autenticare l'utente ad ogni richiesta. In questo modo l'hacker non conoscendo il token non può compiere l'attacco;
- E' possibile impostare un particolare attributo dei cookies, chiamato SameSite attribute. Questo attributo può assume due valori, "Strict" e "Lax". Con l'attributo "strict" il browser non includerà i cookie nelle richieste provenienti da altri siti.
- Si può utilizzare il "nonce" (number used once), cioè un valore casuale e univoco, generato dal server per un'operazione specifica e utilizzato solo una volta. Quando l'utente effettua una richiesta include il "nonce" ricevuto, il server lo verifica per confermare l'autenticità della richiesta stessa, se il valore nonce è assente, non valido o già stato utilizzato in precedenza, il server rifiuterà la richiesta e potrebbe invalidare la sessione.
Naturalmente l'utente generico medio non può verificare di volta in
volta l'applicazione di uno dei meccanismi di mitigazione, ne andarsi a
leggere l'header del cookie, queste sono attività che devono essere
svolte in modo automatico da appositi strumenti di sicurezza come per
esempio i Web Application Firewalls che attraverso la costruzione di
apposite regole in fase di configurazione si occupano di questo aspetto
di sicurezza.
Ultima raccomandazione, se state progettando un software e volete che resista a attacchi CSRF non vi affidate ad un solo metodo per mitigare il rischio, usate almeno due tecniche diverse in quanto alcuni attacchi sono capaci di bypassare le comuni tecniche di mitigazione viste sopra.
Per concludere, se vi ho incuriosito, date un'occhiata al sito di OWASP. Vi potrete trovare nel dettaglio e estensivamente una chiara descrizione di come funziona l'attacco, di come testare un sito o servizio web per evitare questo tipo di attacco, delle modalità di revisione del codice e delle possibili misure di prevenzione.
Alessandro Rugolo
Per approfondire:
- https://learn.snyk.io/lesson/csrf-attack/
- https://owasp.org/www-community/attacks/csrf
- https://www.synopsys.com/glossary/what-is-csrf.html
- https://my.f5.com/manage/s/article/K80291425
- https://www.quora.com/What-is-a-CSRF-What-is-it-used-for-How-does-one-go-about-finding-and-exploiting-these-vulnerabilities-How-can-one-prevent-them-in-their-code
- https://portswigger.net/daily-swig/chromium-bug-allowed-samesite-cookie-bypass-on-android-devices
Nessun commento:
Posta un commento