Un cookie CSRF deve essere HttpOnly?

Poiché joe dice , non vi è alcun reale vantaggio in termini di sicurezza. È puro teatro di sicurezza. Vorrei evidenziarlo da la documentazione :

If you enable this and need to send the value of the CSRF token with an AJAX request, your JavaScript must pull the value from a hidden CSRF token form input on the page instead of from the cookie.

Lo scopo del flag HttpOnly è di rendere il valore del cookie non disponibile da JavaScript, in modo che non possa essere rubato se esiste una vulnerabilità XSS. Ma il token CSRF deve essere in qualche modo disponibile in modo che possa essere presentato due volte, dopotutto. Quindi Django lo risolve includendo il valore in un campo modulo nascosto. Ciò annulla l'intero vantaggio di HttpOnly, poiché un utente malintenzionato può semplicemente leggere il valore del campo modulo invece del cookie.

È corretto. Questo è un falso positivo e la persona che ti fornisce questo risultato non capisce quello che sta facendo, sfortunatamente. Qualcuno che ha compreso i rischi degli attacchi mitm e csrf non ti avrebbe mai fornito questo.

Sebbene il token CSRF non sia segreto su una pagina con un modulo protetto da CSRF (e potrebbe essere rubato usando XSS), in alcune pagine potrebbe esserci una vulnerabilità XSS senza un modulo. Lì puoi ottenere il token dal cookie ma non da un campo nascosto. In questo caso, la sicurezza viene migliorata utilizzando un cookie HttpOnly.

C'è ancora un modo per ottenere il token richiedendo una pagina che contiene un modulo tramite javascript. Ci possono essere modi per prevenirlo, ma sulla maggior parte dei siti questo attacco sarà possibile.

Designating the CSRF cookie as HttpOnly doesn’t offer any practical protection because CSRF is only to protect against cross-domain attacks.

Questo può essere stipulato in un modo molto più generale e, in un modo più semplice, rimuovere l'aspetto tecnico di "cookie CSRF".

La designazione di un cookie come HttpOnly, per definizione, protegge solo dall'accesso tramite document.cookie o metodi JS equivalenti. Non impedisce alcuna interazione HTTP che potrebbe essere stata causata dal codice JS; qualsiasi interazione che l'utente fa tramite elementi HTML, come l'invio di un modulo, può essere avviata da JS . Non c'è una distinzione significativa di come qualcosa è stato avviato; infatti, puoi chiedere "l'utente l'ha avviato" indicando all'utente che lo ha digitato l'URL della pagina Web corrente o quella di qualche pagina Web collegata alla pagina Web corrente.

Questo è anche il motivo per cui il concetto di "autoplay di video" non è ben definito e non può essere prevenuto in modo affidabile: ciò che costituisce un'azione volontaria dell'utente per avviare un video è un concetto di interfaccia utente, non un DOM (documento Concetto di oggetto). Il browser non sa che la riproduzione automatica da parte dell'utente ha fatto un gesto per riprodurre un video, a meno che il video non inizi prima che l'utente effettui alcuna mossa (come "lo spazio per scorrere verso il basso"). (In alcuni casi, è possibile provare a eseguire la riproduzione automatica di "wack a mole", come si può provare a "infastidire una talpa" (rilevare, black-list) fastidiosi annunci Web o condividere informazioni con domini di terze parti, ma senza garanzia di copertura .)

A meno che JS non sia completamente disattivato su un dominio, qualsiasi azione dell'utente all'interno del frame controllato dal sito Web dovrebbe semplicemente essere considerata eseguibile tramite script del sito web. Uno del moderno Web, che disattiva completamente JS nella maggior parte dei domini? Quasi nessuno.

Quindi l'osservazione generalizzata è:

La designazione di qualsiasi cookie come HttpOnly non offre alcuna protezione pratica contro eventuali attacchi che eseguono azioni che l'utente potrebbe eseguire attraverso l'interfaccia del sito Web.

Si noti che la lettura di tutti i cookie (compresi quelli contrassegnati da HttpOnly) non viene eseguita dall'interfaccia del sito Web, può essere eseguita solo con lo strumento Inspector del browser o il proxy HTTP per i cookie inviati tramite HTTP.