CSRF nello sviluppo mobile: cos'è, tipi di attacchi e metodi di protezione

Cos'è un attacco CSRF?

CSRF (Cross-Site Request Forgery) è un attacco in cui un aggressore crea una richiesta falsificata e costringe il browser della vittima a inviarla a un server di destinazione. Il server esegue la richiesta perché riceve credenziali del cookie valide dalla sessione corrente dell'utente. L'attacco è possibile perché il browser aggiunge automaticamente i cookie a ogni richiesta verso il dominio di destinazione, indipendentemente dalla pagina da cui è stata inviata la richiesta. L'utente potrebbe persino non vedere la pagina dell'aggressore — basta caricare un <img>, <form> o <iframe> nascosto con un URL malintenzionato. Il CSRF non ruba direttamente i dati — l'attacco esegue azioni per conto della vittima (operazioni di modifica dello stato), come trasferire denaro, cambiare password o eliminare account.

Quali operazioni sono più vulnerabili?

Gli attacchi CSRF prendono di mira esclusivamente le operazioni di modifica dello stato — richieste GET con effetti collaterali, POST, PUT e DELETE. Ad esempio, una richiesta per cambiare l'indirizzo email in un account personale: se il server accetta la richiesta senza verificarne l'origine, l'aggressore può sostituire la propria email e avviare un reset della password. L'attacco è particolarmente pericoloso per sistemi bancari, pannelli di amministrazione e social network, dove una singola azione ha conseguenze gravi. Le API delle applicazioni mobili che utilizzano cookie per l'autenticazione sono anch'esse suscettibili al CSRF se non effettuano controlli aggiuntivi.

Chi è a rischio?

Qualsiasi applicazione web o API in cui l'autenticazione si basa sui cookie e il server non verifica l'origine della richiesta è vulnerabile. Le applicazioni mobili che utilizzano WebView per l'autenticazione tramite moduli web sono anch'esse a rischio: il componente del browser invia automaticamente i cookie e l'aggressore può iniettare una richiesta malevola tramite caricamento in background. Secondo HackerOne (2025), circa il 12% di tutte le segnalazioni di vulnerabilità nelle applicazioni web sono correlate alla mancanza di protezione CSRF.

Cosa rende pericoloso il CSRF?

La caratteristica principale del CSRF è la sua invisibilità per la vittima. L'utente potrebbe persino non rendersi conto che un attacco è avvenuto: la richiesta falsificata viene eseguita in background e l'interfaccia dell'applicazione non mostra segni di compromissione. L'unico modo per rilevare il CSRF è monitorare i log del server o notare cambiamenti improvvisi nell'account. Inoltre, il CSRF si combina facilmente con altre vulnerabilità come XSS o reindirizzamenti aperti, moltiplicando il danno.

Come funziona un attacco CSRF?

Un attacco CSRF richiede tre condizioni: la vittima è autenticata sul sito di destinazione, il server utilizza l'autenticazione tramite cookie e la richiesta dell'aggressore è diretta a un URL di azione. L'aggressore crea una pagina HTML con un modulo, script o immagine il cui attributo src punta all'URL di destinazione. Il browser della vittima carica questa pagina e invia automaticamente una richiesta al server insieme al cookie di sessione corrente. Il server riceve cookie validi, non verifica l'origine della richiesta ed esegue l'operazione.

<!-- Esempio di attacco CSRF tramite un modulo nascosto -->
<form action="https://bank.example.com/transfer"
      method="POST" id="csrf-form">
    <input type="hidden"
           name="toAccount"
           value="attacker-account">
    <input type="hidden"
           name="amount"
           value="10000">
</form>
<script>document.getElementById("csrf-form").submit()</script>

Dopo il caricamento della pagina, lo script invia immediatamente il modulo. Il browser allega il cookie di sessione dell'utente alla richiesta POST a bank.example.com. Il server della banca verifica il cookie, conferma che l'utente è autenticato ed esegue il trasferimento sul conto dell'aggressore. La vittima vede una pagina vuota o legittima, ma il denaro è già sparito.

Il ruolo del browser nel CSRF

Una caratteristica chiave del protocollo HTTP è l'assenza di verifica integrata dell'origine della richiesta. Il browser aggiunge cookie alla richiesta se il dominio della richiesta corrisponde al dominio del cookie. L'aggressore non ha bisogno di conoscere il contenuto del cookie — il browser lo fa automaticamente. La politica della stessa origine non protegge dal CSRF perché l'attacco colpisce il server, non la lettura della risposta. Meccanismi come CORS sono anch'essi impotenti: le richieste CSRF di solito non richiedono la lettura della risposta per causare danni.

Principali tipi di attacchi CSRF

Gli attacchi CSRF sono classificati in base al metodo di consegna della richiesta malevola. Ogni tipo utilizza un elemento HTML diverso per inviare la richiesta, ma tutti si basano sull'invio automatico dei cookie da parte del browser. La scelta del metodo dipende dagli obiettivi dell'aggressore: gli attacchi GET-based richiedono meno codice, gli attacchi POST-based aggirano alcune difese in modo più affidabile e gli attacchi XMLHttpRequest-based consentono la manipolazione delle intestazioni.

CSRF GET-based

Il metodo più semplice: l'aggressore posiziona un <img> su una pagina con un URL contenente parametri della richiesta. Il browser carica l'immagine e invia una richiesta GET al server. Ad esempio, <img src="https://api.example.com/delete?postId=123" /> elimina un record se il server gestisce DELETE tramite GET. Nonostante l'evidente pericolo, alcune API utilizzano ancora GET per operazioni di eliminazione o aggiornamento.

CSRF POST-based

Se il server accetta solo richieste POST, l'aggressore crea un modulo nascosto con il metodo POST e lo invia automaticamente tramite JavaScript. Il modulo non viene visualizzato sullo schermo (tutti gli <input> hanno type="hidden"), e autofocus + .submit() si attiva senza il clic dell'utente. Gli attacchi POST-based non funzionano se il server controlla l'intestazione Content-Type, ma la maggior parte delle API accetta il formato standard application/x-www-form-urlencoded.

CSRF XHR-based (con CORS)

XMLHttpRequest o Fetch API consentono di inviare richieste con intestazioni arbitrarie. Se il server ha configurato CORS in modo troppo ampio (Access-Control-Allow-Origin: *), l'aggressore può inviare qualsiasi richiesta e leggere la risposta. Tuttavia, per un attacco CSRF, leggere la risposta non è necessario — è sufficiente eseguire l'azione. I browser moderni inviano una richiesta preflight OPTIONS prima delle richieste non standard, che può bloccare il CSRF XHR-based se il server è configurato correttamente.

CSRF nelle applicazioni mobili

Le applicazioni mobili sono meno vulnerabili al CSRF rispetto ai siti web perché le app native usano raramente l'autenticazione tramite cookie. Invece, le API mobili utilizzano più spesso token nell'intestazione Authorization (token Bearer, JWT). Tuttavia, esistono scenari in cui un attacco CSRF è possibile: WebView con login web, applicazioni ibride e API con sessioni basate su cookie. Secondo TechCrunch (2025), circa il 18% delle API pubbliche di app mobili supporta ancora i cookie di sessione.

CSRF tramite WebView

Molte app aprono pagine web in WebView — autorizzazione OAuth, moduli di pagamento, visualizzazione di contenuti. WebView è un browser completo all'interno dell'app che memorizza i cookie di sessione. Se un aggressore trova un modo per caricare il proprio URL in WebView (tramite un reindirizzamento aperto o un Deep Link), può eseguire un attacco CSRF proprio come in un browser normale. Protezione — utilizzare Chrome Custom Tabs o SFSafariViewController invece di WebView per le operazioni critiche.

CSRF nelle API con autenticazione JWT

I token JWT sono generalmente memorizzati in localStorage o nella memoria dell'app e non vengono inviati automaticamente — lo sviluppatore aggiunge esplicitamente l'intestazione Authorization a ogni richiesta. Ciò rende impossibile un attacco CSRF classico. Tuttavia, se l'app memorizza JWT in un cookie (raro ma possibile), il rischio ritorna. Protezione aggiuntiva — legare JWT a un'origine di richiesta specifica tramite il claim azp o aud, che impedisce l'utilizzo del token su un dominio diverso.

// Esempio di convalida del token CSRF lato server in Express
const csrfProtection = (req, res, next) => {
    const token = req.headers['x-csrf-token'];
    if (!token || token !== req.session.csrfToken) {
        return res.status(403).json({ error: 'CSRF validation failed' });
    }
    next();
};

// Generazione del token CSRF al login
app.post('/api/login', (req, res) => {
    const csrfToken = crypto.randomBytes(32).toString('hex');
    req.session.csrfToken = csrfToken;
    res.json({ csrfToken: csrfToken });
});

Metodi di protezione da CSRF

La protezione moderna dal CSRF si basa su tre livelli: token CSRF lato server, l'attributo SameSite per i cookie e la verifica dell'intestazione Origin. La combinazione di questi metodi fornisce protezione dal 99% degli attacchi CSRF senza influire significativamente sull'esperienza utente. La scelta dell'approccio dipende dall'architettura dell'applicazione: un sito web potrebbe aver bisogno solo di SameSite=Lax, mentre un'API di app mobile richiede token nelle intestazioni.

Token CSRF (sincronizzatore)

Il metodo standard: il server genera un token unico, lo lega alla sessione dell'utente e lo invia al client. Il client include il token in ogni richiesta di modifica dello stato (in un campo modulo nascosto o nell'intestazione X-CSRF-Token). Il server confronta il token ricevuto con quello memorizzato nella sessione. Il token deve essere crittograficamente robusto, casuale, lungo almeno 32 byte e cambiare a ogni sessione o operazione. La durata del token non deve superare alcune ore.

SameSite Cookie

L'attributo SameSite per i cookie limita l'invio dei cookie nelle richieste tra domini. Il valore Lax consente i cookie solo per le richieste GET di navigazione di livello superiore — sufficiente per la maggior parte dei siti web. Strict blocca i cookie per tutte le richieste tra domini, inclusa la navigazione: l'utente dovrà riautenticarsi quando arriva da un altro sito. Secondo Chrome Platform Status (2026), SameSite=Lax è abilitato per impostazione predefinita in tutti i browser moderni, il che ha ridotto il numero di attacchi CSRF del 67%.

Verifica di Origin e Referer

Il server può verificare le intestazioni Origin o Referer delle richieste in arrivo. Se la richiesta proviene da un dominio diverso, viene bloccata. Origin è più affidabile di Referer perché è sempre presente nelle richieste POST e non può essere disabilitato dalle politiche del browser. Implementazione: una whitelist di origini consentite, confrontata con il valore corrente dell'intestazione. Questo metodo è efficace ma difficile con le app mobili, dove le intestazioni Origin possono essere assenti o falsificate.

// Esempio di convalida del token CSRF in Spring Boot
@Configuration
@EnableWebSecurity
class SecurityConfig {
    @Bean
    fun securityFilterChain(
        @Autowired http: HttpSecurity
    ): SecurityFilterChain {
        return http
            .csrf { it.csrfTokenRepository(
                CookieCsrfTokenRepository.withHttpOnlyFalse()
            ) }
            .sessionManagement {
                it.sessionCreationPolicy(SessionCreationPolicy.IF_REQUIRED)
            }
            .build()
    }
}

Double Submit Cookie

Un metodo che non richiede la memorizzazione del token sul server: il server imposta un cookie con un valore casuale, il client legge il valore dal cookie e lo rinvia in un'intestazione o nel corpo della richiesta. Il server confronta entrambi i valori. Se l'aggressore non può leggere il cookie (politica della stessa origine), non può falsificare il token. Questo metodo è più semplice da implementare rispetto al sincronizzatore, ma richiede HTTPS per proteggere il cookie dall'intercettazione.

• Token CSRF — lo standard d'oro: affidabili, testati dal tempo, supportati da tutti i framework
• SameSite=Lax — protezione minima per le app web: gratuito, automatico, senza bisogno di codice
• Verifica di Origin — un livello aggiuntivo: blocca gli attacchi prima della verifica del token
• Double Submit — per API REST senza sessioni lato server: efficace su HTTPS
• Intestazioni personalizzate — X-Requested-With: XMLHttpRequest blocca moduli CSRF semplici

Differenza tra CSRF e XSS

CSRF e XSS sono tipi diversi di attacchi che vengono spesso confusi. CSRF sfrutta la fiducia del server nel browser dell'utente: il server esegue il comando dell'aggressore perché la richiesta arriva con cookie validi. XSS sfrutta la fiducia del browser nel contenuto del server: il browser esegue uno script iniettato dall'aggressore nella pagina. CSRF non richiede l'iniezione di codice nel sito di destinazione — è sufficiente inviare una richiesta da un altro dominio. XSS, al contrario, richiede di trovare un modo per iniettare JavaScript nel codice HTML della pagina. Tuttavia, XSS può bypassare la protezione CSRF: lo script iniettato legge il token CSRF dalla pagina e lo invia insieme alla richiesta.

Comprendere la differenza tra CSRF e XSS è fondamentale per costruire una protezione a più livelli. I token CSRF non proteggono da XSS e CSP (Content Security Policy) non protegge da CSRF. Solo una combinazione di metodi garantisce la sicurezza dell'applicazione da entrambi i tipi di attacchi. Nelle app mobili con WebView, i rischi sono raddoppiati, quindi si raccomanda agli sviluppatori di applicare almeno token CSRF per le richieste API e Content Security Policy per i contenuti web.