La protezione CSRF incorporata di Django è sufficiente?

Django utilizza un Double-Submit Cookie ed è accettato come un metodo sicuro di prevenzione CSRF. Perché? Perché è impossibile per un utente malintenzionato controllare il cookie archiviato in un attacco CSRF . Un attacco CSRF si basa sul fatto che il browser gestisce i cookie e includerà i cookie associati a un dominio di destinazione alla richiesta HTTP falsificata. È possibile leggere e modificare i cookie non HTTPOnly tramite XSS, tuttavia, quasi tutte le misure Anti-CSRF possono essere compromesse da XSS.

Per rispondere alla tua domanda:
Sì, il sistema di protezione CSRF di Django impedirà il successo di un attacco CSRF, a condizione che l'applicazione non sia vulnerabile a XSS.

La protezione CSRF di Django non è rotta di per sé; è generalmente considerato sufficiente per molte applicazioni.

Tuttavia, il modello del "doppio invio dei cookie" significa che la protezione CSRF fallirà nel caso in cui un utente malintenzionato possa installare un cookie sul browser di un utente: l'utente malintenzionato potrebbe impostare il cookie e quindi inviare immediatamente un modulo con lo stesso valore in il suo campo token. Ciò significa che esiste una potenziale via di escalation dalla forzatura dei cookie a CSRF, e questo può essere inaccettabile per ulteriori applicazioni critiche per la sicurezza.

Forzare i cookie non è generalmente un semplice attacco in sé. La politica della stessa origine dovrebbe in genere impedire al sito di un utente malintenzionato di impostare un cookie su un altro sito. Se il sito di destinazione ha un difetto XSS, ovviamente puoi impostare / ottenere i cookie, ma se hai XSS hai già perso così male, non c'è motivo di preoccuparsi di CSRF.

Dove questo può cadere, si trovano fattori di hosting che potrebbero essere fuori controllo come autore di applicazioni:

1. Quando il tuo sito è su HTTPS e l'utente malintenzionato ha un vero e proprio man-in-the-middle contro un utente. Sebbene non possano spoofare il tuo sito Web HTTPS, possono indirizzare l'utente a un indirizzo HTTP sullo stesso hostname e da lì scrivere un cookie che verrà inviato dal browser al tuo sito HTTPS in un secondo momento. (Questo può essere un po 'attenuato usando l'intestazione Strict-Transport-Security .)

2. Se il tuo sito è su a.example.com e c'è un'altra applicazione in b.example.com che è vulnerabile a XSS, quella applicazione potrebbe essere sfruttata per impostare un cookie su tutto example.com , che sarebbe quindi inviato dal browser alla tua app a a.example.com .

È una debolezza progettuale dei cookie che un'applicazione non è in grado di stabilire se i cookie erano originariamente impostati con le proprietà domain e secure corrispondenti e che se due cookie con lo stesso nome sono impostati con% diversodomain / secure i risultati sono essenzialmente indefiniti.

Gli approcci "token sincronizzatore" e "token crittografato" (HMAC) includono uno sconosciuto segreto lato server per l'utente malintenzionato che impedisce l'escalation del cookie forzato a CSRF.

Purtroppo Django non si presta a sostituire in modo pulito funzionalità condivise. Migliorare o sostituire il meccanismo CSRF senza rompere tutte le app che si basano su di esso comporta un sacco di brutte patch di scimmia.