Perché il controllo dei referer è necessario per Django per prevenire CSRF

Prima di tutto, grazie per la domanda interessante. Non conoscevo i dettagli di CSRF prima e ho dovuto cercare la risposta alla tua domanda, ma penso di conoscere la spiegazione corretta del comportamento di Django ora.

Gli sviluppatori di Django stanno trattando HTTP e HTTPS si riferisce in modo diverso perché gli utenti si aspettano cose diverse da servizi web sicuri e insicuri. Più specificamente, se una pagina web utilizza la sicurezza del livello di trasporto, gli utenti si aspettano di essere protetti dagli attacchi man-in-the-middle, nel senso che si fidano del principio che anche se qualcuno si sedesse direttamente tra loro e il server remoto e intercettasse ogni singolo messaggio, non potevano fare alcun uso di tali informazioni. Nota che questo non è previsto per connessioni HTTP semplici.

Considera ora il seguente scenario, citato dal post di un Django qui :

• user browses to http://example.com/
• a MITM modifies the page that is returned, so that is has a POST form which targets https://example.com/detonate-bomb/ . The MITM has to include a CSRF token, but that's not a problem because he can invent one and send a CSRF cookie to match.
• the POST form is submitted by javascript from the user's browser and so includes the CSRF cookie, a matching CSRF token and the user's session cookie, and so will be accepted.

Non ho capito subito questo attacco da solo, quindi cercherò di spiegare i dettagli. Nota innanzitutto che stiamo esaminando una pagina che visualizza moduli su connessioni semplici ma invia dati tramite SSL / TLS. Parte del problema, a quanto ho capito, è che il cookie e il valore del modulo nascosto (ovvero "il token CSRF") vengono confrontati solo l'uno contro l'altro, non contro qualsiasi valore memorizzato sul lato server. Questo rende facile per l'attaccante fornire alla vittima una combinazione di token-cookie che sarà accettata dal server - ricorda, la pagina che mostra il modulo non è protetta, quindi% head_int% intestazioni e il contenuto del modulo stesso può essere falsificato Una volta inviato il modulo manipolato (tramite JS iniettato, ad esempio), il server vede una richiesta perfettamente valida.

L'aggiunta di rigoroso controllo Set-Cookie è la risposta a questo esatto problema. Controllando queste intestazioni, solo le richieste provenienti da Referer saranno accettate a un altro endpoint di https://example.com . Le pagine non sicure dello stesso dominio verranno considerate completamente non attendibili e giustamente.

Ora per tornare alla domanda sul perché le semplici richieste HTTP siano trattate in modo diverso, dobbiamo solo immaginare un sito che non usa affatto la crittografia. In tal caso, un uomo nel mezzo potrebbe anche spoofare le intestazioni https://example.com inviate con i dati del modulo effettivi, quindi controllare quelli non fornisce alcuna sicurezza aggiuntiva. In altre parole: non c'è protezione contro gli attacchi CSRF da parte di un uomo nel mezzo - ma, come ho detto prima, gli utenti non si aspettano questo tipo di sicurezza da semplici siti HTTP.

Per quanto riguarda la tua domanda su come altri framework web gestiscono questo vettore di attacco, devo dire onestamente che non lo so.

Riassumo brevemente ciò che ho trovato da quando ho posto questa domanda.

Non è possibile garantire che la prima richiesta dell'utente sul sito Web sia https (dal lato server). Un utente malintenzionato potrebbe utilizzare questa richiesta per impostare un cookie CSRF specifico. Può quindi utilizzarlo per fare una richiesta cross-site per conto dell'utente da un dominio http fuori dal tuo controllo. Questo è ciò che impedisce il controllo dei referenti.

Una soluzione che potrebbe venire in mente è ripristinare il token CSRF quando si avvia una sessione autenticata. L'hacker potrebbe quindi solo falsificare le richieste ai servizi anonimi, il che ha un piccolo vantaggio (potrebbe semplicemente farlo direttamente da solo, dopo tutto è anonimo).

Il problema è che anche il modulo di accesso è vulnerabile a CSRF, nonostante abbia bisogno di una password. L'autore dell'attacco, in quel caso , non subentra la sessione dell'utente, ma registra l'utente nella sessione dell'utente malintenzionato. L'autore dell'attacco potrebbe quindi essere in grado di vedere le cose che l'utente ha fatto o inserito.

Alcuni rari casi in cui penso che potrebbe essere disattivato, tutti supponendo che l'HSTS sia attivo e tu modifichi il token CSRF all'accesso:

• Hai una procedura di accesso che fa uno di:

  • Coinvolgi due pagine, con il token CSRF modificato dopo il primo, in modo che non possa essere automatizzato (imposta anche X-Frame-Options ). Per esempio. richiesta autenticazione a due fattori, o solo una seconda pagina con un pulsante okay manuale.
  • La pagina di accesso ha un CAPTCHA che protegge da richieste false.
  • L'utente non sarà indotto a utilizzare l'account sbagliato per il nostro particolare servizio (ad esempio, è altamente personalizzato in un modo ovvio per l'utente ma che l'utente malintenzionato non è in grado di rilevare).

• Sai che la prima richiesta sarà attraverso https, ad es. si suppone che la pagina sia accessibile tramite l'app o il software, piuttosto che i normali browser.

• I browser implementano un modo per vedere se un cookie era https-only / è stato impostato su una connessione https (quindi gli autori di attacchi non potevano impostare un cookie utilizzabile su http). Ma è impossibile al momento e al di fuori del nostro controllo.

(Rendere i token CSRF essere dipendenti dalla sessione in modo segreto ed essere archiviati sul lato server, non aggiusta questo. L'utente malintenzionato non può sovrascrivere o generare il token CSRF, ma può semplicemente chiedere al server di farlo aprendo un modulo usando la sessione che ha scelto).