Questo articolo analizza un attacco CSRF, come avviene e le misure da adottare per prepararsi ad affrontarlo.<\/p>\n
Guarda la nostra video-guida per scoprire tutto sugli attacchi CSRF<\/a><\/strong><\/p>\n Un attacco Cross-Site Request Forgery, noto anche come attacco CSRF, inganna un utente autenticato e lo costringe a eseguire azioni non volute inviando richieste dannose senza che se ne renda conto.<\/p>\n In genere, un attacco CSRF comporta richieste che cambiano stato perch\u00e9 chi attacca non riceve risposta. Esempi di richieste di questo tipo sono la cancellazione di un record, la modifica di una password<\/a>, l’acquisto di un prodotto o l’invio di un messaggio. Tutte queste operazioni possono avvenire all’insaputa dell’utente.<\/p>\n L’aggressore malintenzionato di solito utilizza tecniche di social engineering per inviare a un utente ignaro un link tramite chat o e-mail.<\/p>\n Quando l’utente clicca sul link, esegue i comandi impostati dall’aggressore.<\/p>\n Ad esempio, cliccando su un link si possono trasferire fondi dal conto dell’utente. Oppure, si pu\u00f2 cambiare l’indirizzo e-mail di un utente impedendogli di riottenere l’accesso all’account.<\/p>\n Far s\u00ec che l’utente avvii una richiesta di cambio di stato mentre \u00e8 connesso \u00e8 il primo e pi\u00f9 importante passo di un attacco CSRF. Con gli attacchi CSRF, l’aggressore mira a far s\u00ec che un utente autenticato invii inconsapevolmente una richiesta web dannosa a un sito o a un’applicazione web. Queste richieste possono essere costituite da cookie, parametri URL<\/a> e altri tipi di dati che all’utente appaiono normali.<\/p>\n Affinch\u00e9 un attacco CSRF abbia successo, devono verificarsi le seguenti condizioni:<\/p>\n Il metodo pi\u00f9 comune per portare a termine gli attacchi CSRF \u00e8 l’utilizzo dei cookie nelle applicazioni con una policy debole sui cookie SameSite. I browser web includono i cookie automaticamente<\/a> e spesso in modo anonimo e salvano i cookie utilizzati da un dominio in ogni richiesta web che l’utente invia a quel dominio.<\/p>\n La policy sui cookie SameSite definisce il trattamento del cookie da parte del browser in contesti di navigazione cross-site. Se \u00e8 impostata su strict, il cookie non viene condiviso in contesti di navigazione cross-site, prevenendo gli attacchi CSRF. Se \u00e8 impostata su none, il browser attribuisce il cookie in tutti i contesti cross-site. Questo rende l’applicazione vulnerabile agli attacchi CSRF.<\/p>\n Quando un utente invia inconsapevolmente una richiesta dannosa attraverso un browser web, i cookie salvati fanno s\u00ec che la richiesta appaia legittima al server. Il server risponde alla richiesta cambiando l’account dell’utente, modificando lo stato della sessione o restituendo i dati richiesti.<\/p>\n Vediamo due esempi di attacchi CSRF, uno con una richiesta GET e l’altro con una richiesta POST.<\/p>\n In primo luogo, consideriamo una richiesta GET<\/a> utilizzata da un’applicazione web di banking finanziario, in cui l’attacco sfrutta una richiesta GET e la consegna di un collegamento ipertestuale.<\/p>\n Supponiamo che la richiesta GET per il trasferimento di denaro sia simile a questa:<\/p>\n Nella richiesta autentica qui sopra, l’utente chiede di trasferire 1.000 dollari a un conto di Sebbene questa richiesta sia esplicita, semplice e pratica, espone il titolare del conto a un attacco CSRF. Questo perch\u00e9 la richiesta non richiede dettagli che un malintenzionato potrebbe non conoscere. Quindi, per sferrare un attacco, un malintenzionato dovrebbe solo alterare i parametri di questa richiesta (l’importo e il numero di conto) per creare una richiesta falsificata eseguibile.<\/p>\n La richiesta dannosa sarebbe efficace per tutti gli utenti della banca, purch\u00e9 abbiano sessioni gestite da cookie in corso.<\/p>\n Ecco come apparirebbe la richiesta contraffatta di trasferire 500 dollari sul conto di un hacker (qui il numero Una volta completata l’operazione, l’aggressore deve trovare un modo per ingannare l’utente e indurlo a inviare la richiesta mentre \u00e8 connesso alla sua applicazione bancaria online. Uno dei modi per farlo \u00e8 creare un collegamento ipertestuale innocuo che attiri l’attenzione dell’utente. Il link potrebbe avere il seguente aspetto:<\/p>\n Dato che l’aggressore ha trovato gli indirizzi e-mail corretti<\/a> dei suoi obiettivi, pu\u00f2 inviare questo link via e-mail a molti clienti della banca. Coloro che cliccheranno sul link mentre sono connessi attiveranno la richiesta di inviare all’aggressore 500 dollari dal conto registrato.<\/p>\n Vediamo come lo stesso istituto finanziario subirebbe un CSRF se accettasse solo richieste POST<\/a>. In questo caso, il collegamento ipertestuale utilizzato nell’esempio della richiesta GET non funzionerebbe. Pertanto, un attacco CSRF riuscito richiederebbe all’aggressore di creare un modulo HTML. La richiesta autentica di inviare 1.000 dollari per un prodotto acquistato avrebbe il seguente aspetto:<\/p>\n Questa richiesta POST richiede un cookie per determinare l’identit\u00e0 dell’utente, l’importo che desidera inviare e il conto che desidera inviare. Gli aggressori possono alterare questa richiesta per eseguire un attacco CSRF.<\/p>\n Chi attacca deve solo aggiungere un cookie autentico a una richiesta contraffatta per far s\u00ec che il server elabori il trasferimento. Pu\u00f2 farlo creando un collegamento ipertestuale dall’aspetto innocuo che porti l’utente a una pagina web innescata che assomiglia a questa:<\/p>\n Abbiamo gi\u00e0 impostato i parametri dell’importo e del conto nel modulo precedente. Una volta che un utente autenticato visita la pagina, il browser aggiunge il cookie di sessione prima di inoltrare la richiesta al server. Il server inoltra quindi 500 dollari all’account dell’hacker.<\/p>\n Esistono diversi metodi per prevenire e ridurre drasticamente i potenziali attacchi CSRF sul vostro sito o sulla vostra applicazione web, tra cui:<\/p>\n Un sito web sicuro dal punto di vista CSRF assegna a ogni sessione un token unico e lo condivide con il server e il browser<\/a> del client. Ogni volta che un browser invia una richiesta sensibile, il server si aspetta che contenga il token CSRF assegnato. Se la richiesta contiene il token sbagliato, il server la rifiuta. Il token CSRF non viene memorizzato nei cookie di sessione del browser del client per motivi di sicurezza.<\/p>\n Sebbene i token CSRF siano un’eccellente misura di sicurezza, questo metodo non \u00e8 a prova di attacco. Alcune delle vulnerabilit\u00e0 che accompagnano i token CSRF includono:<\/p>\n Un aggressore deve solo rimuovere il token e inviarlo in questo modo per eseguire l’attacco:<\/p>\n Un utente malintenzionato pu\u00f2 accedere a un’applicazione utilizzando il proprio account per ottenere un token, ad esempio:<\/p>\n Inoltre, poich\u00e9 i token sono raggruppati, l’aggressore pu\u00f2 copiare e utilizzare lo stesso token per accedere a un account di un altro utente, che lo utilizzer\u00e0 di nuovo:<\/p>\n Quindi un utente malintenzionato pu\u00f2 accedere a un’applicazione utilizzando il proprio account e aprire il file cookie per vedere quanto segue:<\/p>\n Pu\u00f2 quindi utilizzare queste informazioni per creare un altro cookie e completare l’attacco<\/p>\n Un’altra strategia per prevenire gli attacchi CSRF \u00e8 l’utilizzo dell’intestazione referrer. Nell’HTTP, le intestazioni referrer indicano l’origine delle richieste. In genere vengono utilizzate per eseguire analisi<\/a>, ottimizzazioni e registrazioni.<\/p>\n \u00c8 anche possibile attivare il controllo delle intestazioni referrer sul lato server per prevenire gli attacchi CSRF. Il lato server controlla l’origine della richiesta e determina l’origine di destinazione della richiesta. Se corrispondono, la richiesta \u00e8 consentita. Se c’\u00e8 una mancata corrispondenza, il server elimina la richiesta.<\/p>\n L’uso delle intestazioni del referrer \u00e8 molto pi\u00f9 semplice dell’uso dei token perch\u00e9 non richiede l’identificazione di un singolo utente.<\/p>\n Come i token CSRF, anche le intestazioni referrer presentano alcune vulnerabilit\u00e0 significative.<\/p>\n Innanzitutto, le intestazioni del referrer non sono obbligatorie e alcuni siti inviano richieste senza di esse. Se il CSRF non dispone di una policy per gestire le richieste senza intestazioni, gli aggressori possono utilizzare le richieste senza intestazione per eseguire attacchi con cambio di stato.<\/p>\n Inoltre, questo metodo \u00e8 diventato meno efficace con la recente introduzione del criterio del referrer<\/a>. Questa specifica impedisce la fuga di URL verso altri domini, dando agli utenti un maggiore controllo sulle informazioni contenute nell’intestazione del referrer. Possono scegliere di esporre parte delle informazioni dell’intestazione del referrer o di disabilitarle aggiungendo un tag di metadati alla pagina HTML, come mostrato di seguito:<\/p>\n Il codice sopra riportato rimuove l’intestazione del referrer per tutte le richieste provenienti da questa pagina. In questo modo \u00e8 difficile per le applicazioni che si basano sulle intestazioni del referrer prevenire gli attacchi CSRF da questa pagina.<\/p>\n Oltre all’utilizzo dell’intestazione referrer e dei token CSRF, c’\u00e8 una terza opzione molto pi\u00f9 semplice: scegliere un servizio di hosting sicuro come Kinsta<\/a> per i vostri siti e applicazioni web fornisce una barriera molto pi\u00f9 forte e sicura tra gli aggressori e i vostri utenti.<\/p>\n Oltre a funzioni di sicurezza fondamentali come i backup automatici<\/a>, l’autenticazione a due fattori<\/a> e i protocolli SFTP e SSH<\/a>, l’integrazione di Kinsta con Cloudflare<\/a> offre una protezione di livello enterprise con protezione basata su IP e firewall.<\/p>\n In particolare, Kinsta dispone attualmente di circa 60 regole firewall personalizzate che aiutano a prevenire gli attacchi dannosi e a gestire le gravi vulnerabilit\u00e0 non autenticate nei plugin e nei temi, comprese quelle specifiche che cercano le vulnerabilit\u00e0 CSRF.<\/p>\n Il Cross-Site Request Forgery (CSRF) \u00e8 un attacco che inganna gli utenti autenticati e li induce a iniziare involontariamente richieste che cambiano stato. Le applicazioni prese di mira sono quelle che non sono in grado di distinguere tra le richieste di cambio di stato valide e quelle falsificate.<\/p>\n Il CSRF pu\u00f2 avere successo solo nelle applicazioni che si affidano ai cookie di sessione per identificare gli utenti registrati e che hanno una policy debole sui cookie SameSite. Inoltre, \u00e8 necessario un server che accetti richieste che non contengano parametri sconosciuti come le password. Gli hacker possono inviare attacchi dannosi utilizzando sia GET che POST.<\/p>\n Sebbene l’utilizzo di token CSRF o la verifica dell’intestazione del referrer possano prevenire alcuni attacchi CSRF, entrambe le misure presentano potenziali vulnerabilit\u00e0 che possono rendere inutili le misure preventive se non si sta attenti.<\/p>\nCos’\u00e8 un Attacco CSRF?<\/h2>\n
![\"Un'illustrazione](\"https:\/\/kinsta.com\/wp-content\/uploads\/2022\/11\/CSRF-Attack-Okta.png\")
Come Funziona un Attacco CSRF?<\/h2>\n
\n
CSRF per una Richiesta GET<\/h2>\n
GET https:\/\/xymbank.com\/online\/transfer?amount=1000&accountNumber=547895 HTTP\/1.1<\/code><\/pre>\n547895<\/code> come pagamento per i prodotti acquistati.<\/p>\n654585<\/code>). Si noti che l’esempio che segue \u00e8 una versione molto semplificata dei passaggi necessari per un attacco CSRF.<\/p>\nGET https:\/\/xymbank.com\/online\/transfer?amount=500&accountNumber=654585 HTTP\/1.1<\/code><\/pre>\n<a\nhref=\"https:\/\/xymbank.com\/online\/transfer?amount=500&accountNumber=654585\">Click here to get more information<\/a>.<\/code><\/pre>\nCSRF per una Richiesta POST<\/h2>\n
POST \/online\/transfer HTTP\/1.1\nHost: xymbank.com\nContent-Type: application\/x-www-form-urlencoded\nCookie: session=FRyhityeQkAPzeQ5gHgTvlyxHJYhg\namount=1000\naccount=547895<\/code><\/pre>\n<html>\n<body>\n<form action=\"https:\/\/xymbank.com\/online\/transfer\" method=\"POST\">\n<input type=\"hidden\" name=\"amount\" value=\"500\"\/>\n<input type=\"hidden\" name=\"account\" value=\"654585\" \/>\n<\/form>\n<script>\ndocument.forms[0].submit();\n<\/script>\n<\/body>\n<\/html><\/code><\/pre>\n3 Modi per Ridurre gli Attacchi CSRF<\/h2>\n
\n
Come Prevenire gli Attacchi CSRF Utilizzando i Token CSRF<\/h2>\n
Potenziali Vulnerabilit\u00e0 dei Token CSRF<\/h3>\n
\n
POST \/change_password\nPOST body:\npassword=pass123&csrf_token=93j9d8eckke20d433<\/code><\/pre>\nPOST \/change_password\nPOST body:\npassword=pass123<\/code><\/pre>\n\n
[application_url].com?csrf_token=93j9d8eckke20d433<\/code><\/pre>\n\n
Csrf_token:93j9d8eckke20d433<\/code><\/pre>\n\n
Come Prevenire gli Attacchi CSRF con l’Intestazione Referrer<\/h2>\n
Potenziali Vulnerabilit\u00e0 dell’Intestazione Referrer<\/h3>\n
<meta name=\"referrer\" content=\"no-referrer\"><\/code><\/pre>\nCome Kinsta Protegge dagli Attacchi CSRF<\/h2>\n
Riepilogo<\/h2>\n