Impatto
Cross-Site Request Forgery (CSRF) consente a un utente malintenzionato di ingannare il browser di una vittima inducendolo a eseguire azioni indesiderate su un sito Web diverso in cui la vittima è attualmente autenticata. Poiché i browser includono automaticamente credenziali ambientali come i cookie nelle richieste, un utente malintenzionato può falsificare operazioni di modifica dello stato, come la modifica delle password, l'eliminazione di dati o l'avvio di transazioni, all'insaputa dell'utente.
Causa principale
La causa fondamentale del CSRF è il comportamento predefinito del browser web di inviare cookie associati a un dominio ogni volta che viene effettuata una richiesta a quel dominio, indipendentemente dall'origine della richiesta [S1]. Senza una convalida specifica che una richiesta sia stata attivata intenzionalmente dall'interfaccia utente dell'applicazione, il server non è in grado di distinguere tra un'azione legittima dell'utente e una contraffatta.
Meccanismi di protezione CSRF di Django
Django fornisce un sistema di difesa integrato per mitigare questi rischi attraverso l'integrazione del middleware e dei modelli [S2].
Attivazione del middleware
django.middleware.csrf.CsrfViewMiddleware è responsabile della protezione CSRF ed è in genere abilitato per impostazione predefinita [S2]. Deve essere posizionato prima di qualsiasi middleware di visualizzazione che presuppone che gli attacchi CSRF siano già stati gestiti [S2].
Implementazione del modello
Per eventuali moduli POST interni, gli sviluppatori devono includere il tag {% csrf_token %} all'interno dell'elemento <form> [S2]. Ciò garantisce che nella richiesta sia incluso un token univoco e segreto, che il server poi convalida rispetto alla sessione dell'utente.
Rischi di perdita di token
Un dettaglio di implementazione fondamentale è che {% csrf_token %} non dovrebbe mai essere incluso nei moduli destinati a URL esterni [S2]. Ciò potrebbe far trapelare il token CSRF segreto a terze parti, compromettendo potenzialmente la sicurezza della sessione dell'utente [S2].
Difesa a livello di browser: cookie dello stesso sito
I browser moderni hanno introdotto l'attributo SameSite per l'intestazione Set-Cookie per fornire un livello di difesa approfondita [S1].
- Rigido: il cookie viene inviato solo in un contesto di prima parte, ovvero il sito nella barra dell'URL corrisponde al dominio del cookie [S1].
- Lax: il cookie non viene inviato su richieste secondarie tra siti (come immagini o frame) ma viene inviato quando un utente naviga al sito di origine, ad esempio seguendo un collegamento standard [S1].
Come lo esegue il test FixVibe
FixVibe ora include la protezione CSRF come controllo attivo recintato. Dopo la verifica del dominio, active.csrf-protection ispeziona i moduli di modifica dello stato rilevati, controlla gli input a forma di token CSRF e i segnali dei cookie SameSite, quindi tenta un invio di origini contraffatte a basso impatto e segnala solo quando il server lo accetta. I controlli dei cookie segnalano anche attributi deboli di SameSite che riducono la difesa CSRF in profondità.