Cos'è CSRF e come lo previeni?

Question

Accepted Answer

**CSRF (Cross-Site Request Forgery)** inganna il browser di un utente autenticato a fare **richieste indesiderate** a un sito dove è autenticato — eseguendo azioni (trasferimenti, modifiche) senza il suo consenso, sfruttando l'invio automatico delle credenziali/cookie del browser. ## Come funziona CSRF ```text The attack exploits that browsers AUTO-SEND cookies (incl. session cookies) with requests: 1. a user is LOGGED IN to a site (has a session cookie) 2. the user visits a MALICIOUS page (or clicks a crafted link) 3. that page makes a request to the target site (e.g. a hidden form auto-submitting) 4. the browser AUTOMATICALLY includes the user's session cookie → the site thinks it's a legitimate request from the user → performs the action (transfer money, change email) → the user unknowingly performs an action they didn't intend. ``` ```html ``` ## Prevenzione ```text ✓ CSRF TOKENS → a unique, unpredictable token per session/form that the server verifies; the attacker's site can't know it → the forged request fails (the primary defense) ✓ SameSite COOKIES → SameSite=Lax/Strict → cookies NOT sent on cross-site requests → blocks CSRF (now a strong, default-ish browser defense) ✓ Check Origin/Referer headers; require re-authentication for sensitive actions ✓ Don't use GET for state-changing actions (use POST/PUT/DELETE properly) → Frameworks often provide CSRF protection built in — enable/use it. ``` ## Perché è importante Comprendere CSRF e come prevenirlo è prezioso perché è una **vulnerabilità web comune** che sfrutta il funzionamento dei browser, permettendo agli attaccanti di eseguire azioni come utenti autenticati, quindi è una conoscenza di sicurezza importante per gli sviluppatori web. Comprendere **come funziona CSRF** — sfruttando il fatto che i browser **inviano automaticamente i cookie** (inclusi i cookie di sessione) con le richieste, quindi una pagina dannosa può attivare una richiesta a un sito dove l'utente è autenticato, e il browser include il cookie di sessione, facendo sì che il sito tratti la richiesta falsificata come legittima ed esegua l'azione (trasferimenti, modifiche dell'account) senza il consenso dell'utente — è necessario per comprendere questo attacco subdolo ma pericoloso. CSRF è pericoloso perché può eseguire azioni sensibili come la vittima senza la sua conoscenza, ed è una vulnerabilità web comune. Comprendere la **prevenzione** è essenziale: **token CSRF** (un token unico e imprevedibile per sessione/modulo che il server verifica — il sito dell'attaccante non può conoscerlo, quindi le richieste falsificate falliscono; la difesa tradizionale principale), **cookie SameSite** (impostando SameSite=Lax/Strict in modo che i cookie non vengono inviati su richieste cross-site, ora una forte difesa a livello di browser che è sempre più predefinita), verifica degli header Origin/Referer, richiesta di re-autenticazione per azioni sensibili, e non usare GET per operazioni che cambiano lo stato. Comprendere che **i framework spesso forniscono protezione CSRF integrata** (che dovrebbe essere abilitata e utilizzata) è praticamente importante. La combinazione di token CSRF e cookie SameSite fornisce una protezione robusta. Poiché CSRF è una vulnerabilità web comune che sfrutta il comportamento del browser per eseguire azioni indesiderate come utenti autenticati, e poiché comprendere come funziona e come prevenirla (token CSRF, cookie SameSite, protezioni del framework) è importante per gli sviluppatori web, comprendere CSRF e la sua prevenzione è una conoscenza di sicurezza preziosa e praticamente rilevante — una classe di attacco notevole da comprendere e difendere, dove le difese (token CSRF e cookie SameSite) sono conoscenze fondamentali per proteggere gli utenti dall'essere ingannati a compiere azioni indesiderate, una classe di attacco notevole per qualsiasi applicazione web con operazioni che cambiano lo stato autenticato.