--- id: CP-053 slug: csrf-richiesta-contraffatta-tra-siti lang: it title: "Il CSRF: l'azione forzata a sua insaputa" description: Un sito trappola o un messaggio può far agire il suo browser al posto suo su un servizio in cui è connesso. Ecco il meccanismo e le difese. canonical_url: https://startbrain.io/cyberpedia/it/articles/csrf-richiesta-contraffatta-tra-siti/ markdown_url: https://startbrain.io/cyberpedia/it/articles/csrf-richiesta-contraffatta-tra-siti.md publisher: Brain (https://startbrain.io) license: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) cite_as: "Brain, «Il CSRF: l'azione forzata a sua insaputa», Cyberpedia, 2026. https://startbrain.io/cyberpedia/it/articles/csrf-richiesta-contraffatta-tra-siti/ (CC BY 4.0)" wing: 1 theme: understand_hacking reflex: cr-018 schema: G3 updated: "2026-11-03" translations: it: https://startbrain.io/cyberpedia/it/articles/csrf-richiesta-contraffatta-tra-siti/ fr: https://startbrain.io/cyberpedia/fr/articles/csrf-requete-forcee-inter-sites/ en: https://startbrain.io/cyberpedia/en/articles/csrf-cross-site-request-forgery/ de: https://startbrain.io/cyberpedia/de/articles/csrf-websiteuebergreifende-anfragefaelschung/ es: https://startbrain.io/cyberpedia/es/articles/csrf-falsificacion-peticiones-entre-sitios/ nl: https://startbrain.io/cyberpedia/nl/articles/csrf-afgedwongen-verzoek-tussen-sites/ sources: - "n": 1 title: Cross Site Request Forgery (CSRF) | OWASP Foundation publisher: OWASP url: https://community.owasp.org/attacks/csrf accessed: "2026-11-03" - "n": 2 title: Prevent Cross-Site Request Forgery (XSRF/CSRF) attacks in ASP.NET Core publisher: Microsoft url: https://learn.microsoft.com/en-us/aspnet/core/security/anti-request-forgery?view=aspnetcore-10.0 accessed: "2026-11-03" - "n": 3 title: Cross-Site Request Forgery Prevention - OWASP Cheat Sheet Series publisher: OWASP url: https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html accessed: "2026-11-03" - "n": 4 title: SameSite | OWASP Foundation publisher: OWASP url: https://community.owasp.org/SameSite accessed: "2026-11-03" - "n": 5 title: "CWE - CWE-352: Cross-Site Request Forgery (5.0)" publisher: MITRE url: https://cwe.mitre.org/data/definitions/352.html accessed: "2026-11-03" --- # Il CSRF: l'azione forzata a sua insaputa Il CSRF (Cross-Site Request Forgery) è un attacco che costringe un utente a eseguire azioni indesiderate su un'applicazione web in cui è già autenticato [1]. L'attaccante non ha bisogno della password della vittima: fa agire il browser di quest'ultima. Per un dipendente, lo scenario tipico è semplice. Una casella di posta o un sito bancario è aperto in una scheda. Un link ricevuto via e-mail o via messaggistica istantanea porta a un'altra pagina, e quella pagina avvia, in background, una richiesta verso il servizio rimasto connesso [1]. ## In 30 secondi - Dove accade: sulla maggior parte dei servizi web privi di protezione anti-CSRF, quando si apre un link o una pagina trappola nello stesso browser [1]. - Cosa vuole l'attaccante: provocare un'azione che modifica qualcosa, come un bonifico o un cambio di password [1]. - Il riflesso: disconnettersi da un servizio quando si è finito di usarlo [2]. - Da dove viene la falla: dall'applicazione, non dall'utente [2]. ## Domande dirette ### Il CSRF ruba la mia password? No, non di per sé. L'attacco usa l'identità e i diritti della vittima per compiere un'azione al suo posto [1]. Prende di mira le azioni che cambiano lo stato del servizio, come modificare l'indirizzo e-mail o la password, oppure acquistare qualcosa. Costringere la vittima a consultare dei dati non giova all'attaccante, perché la risposta arriva alla vittima, non a lui [1]. ### Perché il servizio obbedisce a una richiesta che non ho voluto? Perché non riesce a distinguerla da una richiesta legittima. Per la maggior parte dei siti, le richieste del browser includono automaticamente le credenziali associate al sito, come il cookie di sessione [1]. Se l'utente è autenticato, il sito non ha quindi alcun modo di separare la richiesta contraffatta da quella reale [1]. Il CWE descrive la debolezza così: l'applicazione non verifica, o non può verificare, che una richiesta sia stata fornita volontariamente dall'utente che l'ha inviata [5]. ### Sono protetto se il servizio usa HTTPS? No. Secondo OWASP, HTTPS da solo non protegge dal CSRF, anche se resta un prerequisito perché le altre misure siano affidabili [1]. ### Il problema dipende da me o dall'applicazione? Dall'applicazione. Microsoft lo dice senza giri di parole: le falle CSRF sono fondamentalmente un problema dell'applicazione web, non dell'utente finale [2]. I gesti dell'utente limitano soltanto l'esposizione: disconnettersi quando si ha finito e svuotare regolarmente i cookie del browser [2]. ## Nei panni dell'attaccante L'attaccante comincia individuando una richiesta che modifica qualcosa su un servizio, poi costruisce un indirizzo o uno script che la riproduce con i propri valori. OWASP porta l'esempio di una banca fittizia: la richiesta legittima trasferisce 100 dollari a un beneficiario, e l'attaccante sostituisce il beneficiario con sé stesso aumentando l'importo [1]. Resta da far caricare questa richiesta alla vittima mentre è connessa. Si citano due metodi: un'e-mail non richiesta con contenuto HTML, oppure una trappola collocata su pagine che la vittima è probabile visiti mentre usa il suo servizio online [1]. L'attacco può anche essere memorizzato sul sito vulnerabile stesso, per esempio in un campo che accetta HTML. Diventa allora più probabile: la vittima consulta più volentieri una pagina del sito che una pagina qualunque di Internet, e vi è necessariamente già connessa [1]. ## Cosa si vede sullo schermo Spesso, niente. Il link trappola può essere mascherato da link ordinario, con un testo del tipo «guarda le mie foto». Può anche assumere la forma di una falsa immagine di dimensione zero: se compare in un'e-mail, la vittima non vede nulla, ma il browser invia comunque la richiesta, senza alcun segno visivo che l'operazione sia avvenuta [1]. ```text Illustrazione neutralizzata, non un indirizzo reale. Link mascherato: testo visualizzato «Guarda le mie foto», indirizzo nascosto hxxp://banque[.]exemple[.]invalid/virement?dest=[conto dell'attaccante]&montant=[elevato] Variante: immagine invisibile in un'e-mail, caricata senza clic. ``` Se il servizio si aspetta una richiesta di tipo POST, l'attaccante può ospitare sul proprio sito un modulo con campi nascosti. La vittima crede che faccia altro e clicca, oppure uno script lo invia automaticamente al caricamento della pagina [1]. In entrambi i casi la pagina visualizzata è banale e l'azione si svolge altrove. ## Sotto il cofano Il meccanismo dipende da un comportamento normale dei browser. Essi memorizzano i cookie emessi da un'applicazione, compresi i cookie di sessione degli utenti autenticati, e inviano tutti i cookie di un dominio a ogni richiesta, qualunque sia il modo in cui quella richiesta è nata nel browser [2]. I cookie non sono gli unici coinvolti: anche le autenticazioni di tipo Basic e Digest sono vulnerabili, perché il browser rinvia automaticamente le credenziali fino alla fine della sessione [2]. Secondo OWASP, diverse idee di difesa non funzionano [1]: - un cookie segreto, poiché tutti i cookie vengono inviati con ogni richiesta; - accettare solo richieste POST, poiché basta un modulo nascosto per contraffarne una; - le transazioni in più passaggi, finché l'attaccante può prevedere ogni passaggio; - la sola verifica dell'intestazione Referer, perché può essere falsificata ed è talvolta assente per ragioni di riservatezza. Le protezioni raccomandate, lato applicazione, sono le seguenti. - Verificare prima se il framework offre già una protezione CSRF, e usarla. In mancanza, aggiungere token anti-CSRF a tutte le richieste che modificano lo stato e validarli lato server [3]. Senza token, l'attaccante non può costruire una richiesta valida [3]. - Per i software senza stato, usare un cookie a doppio invio, preferibilmente firmato [3]. - Impostare l'attributo SameSite sui cookie di sessione [3]. Con il valore strict, il browser non invia il cookie nelle richieste tra siti diversi, nemmeno seguendo un link ordinario. Con lax, lo invia per un link seguito da un altro sito ma lo trattiene sui metodi esposti al CSRF come POST [4]. Con none, non è offerta alcuna protezione [4]. - Controllare l'origine con le intestazioni standard, in particolare Sec-Fetch-Site, supportata da tutti i principali browser da marzo 2023 [3]. - Non usare richieste GET per operazioni che modificano lo stato [3]. Queste misure hanno dei limiti. SameSite=Lax lascia passare le richieste GET di navigazione di primo livello: un punto di accesso che modifica lo stato tramite GET resta vulnerabile [2]. I browser meno recenti possono non applicare SameSite [2]. E una falla XSS può aggirare tutte le protezioni anti-CSRF; il worm Samy, per esempio, ha usato una XMLHttpRequest per ottenere il token CSRF e contraffare richieste [1][3]. Il comportamento predefinito di SameSite varia: a dicembre 2024, lax era il valore predefinito di Chrome, Edge e Opera, ma di nessuna versione di Firefox né di Safari, da cui il consiglio di impostarlo esplicitamente [4]. ## Autopsie ### 2008: l'exploit uTorrent OWASP cita, come esempio reale di attacco CSRF contro un'applicazione che funziona tramite richieste GET, un exploit rivolto a uTorrent risalente al 2008. È stato usato su larga scala per scaricare software dannoso [1]. La fonte non dice altro: né il numero delle vittime, né il modo di diffusione. ### Falle catalogate dal CWE (identificativi dal 2004 al 2009) Il CWE-352 fornisce un elenco scelto di esempi osservati, che non è esaustivo [5]. Diversi si basano su un semplice URL in un tag img: CVE-2004-1703 e CVE-2004-1995 permettono di aggiungere account utente, CVE-2004-1842 di ottenere privilegi di amministratore [5]. Altri riguardano la gestione stessa: CVE-2009-3520 permette di modificare la password dell'amministratore, e CVE-2009-3759 di cambiare password o di arrestare una macchina virtuale da un'interfaccia web [5]. ## Fonti 1. OWASP, «Cross Site Request Forgery (CSRF) | OWASP Foundation». https://community.owasp.org/attacks/csrf (consultato il 3 novembre 2026) 2. Microsoft, «Prevent Cross-Site Request Forgery (XSRF/CSRF) attacks in ASP.NET Core». https://learn.microsoft.com/en-us/aspnet/core/security/anti-request-forgery?view=aspnetcore-10.0 (consultato il 3 novembre 2026) 3. OWASP, «Cross-Site Request Forgery Prevention - OWASP Cheat Sheet Series». https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html (consultato il 3 novembre 2026) 4. OWASP, «SameSite | OWASP Foundation». https://community.owasp.org/SameSite (consultato il 3 novembre 2026) 5. MITRE, «CWE - CWE-352: Cross-Site Request Forgery (5.0)». https://cwe.mitre.org/data/definitions/352.html (consultato il 3 novembre 2026) --- Fonte originale: Cyberpedia, l'enciclopedia pubblica di cybersicurezza e IA pubblicata da Brain. Versione canonica: https://startbrain.io/cyberpedia/it/articles/csrf-richiesta-contraffatta-tra-siti/ Puoi riutilizzare liberamente questo testo con licenza CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/), a condizione di citare «Brain, Cyberpedia» con un link all'indirizzo qui sopra.