Usa l'intestazione invece del cookie per i CSRF double submit cookies?

Il motivo per utilizzare il doppio invio (invece di un token di sincronizzazione) è che non si desidera eseguire una ricerca sul server per ogni richiesta. Quindi, fintanto che il valore del cookie corrisponde a quello del parametro di richiesta, la richiesta verrà passata attraverso.

Funziona perché evil.com non può leggere i cookie da example.com (e quindi inviare un parametro di richiesta corrispondente), né impostarli (e quindi impostare entrambi su alcune costanti arbitrarie).

Hai ragione a sottolineare che questo non riesce per i sottodomini. È possibile per evil.example.com per impostare un coockie che verrà utilizzato per example.com , evitando così il test. Quindi, se non ti fidi dei tuoi sottodomini, non usare questa soluzione per la protezione di CSRF!

Ora, la tua proposta risolve il problema? No. In realtà lo rende peggiore. Poiché non è più necessario leggere o modificare alcun valore del cookie, si riduce la possibilità di modificare le intestazioni delle richieste. Quindi questo è come fare semplicemente affidamento su una singola intestazione con un valore costante, ad es. il comunemente usato:

X-Requested-With: XMLHttpRequest

Hai due problemi qui:

1. Sei ancora vulnerabile a un attacco da evil.example.com poiché un sottodominio può modificare i parametri di richiesta ai suoi genitori usando document.domain .
2. Potresti anche essere vulnerabile agli attacchi da evil.com poiché ci sono stati più exploit di Flash che ti consentono di impostare le intestazioni per le richieste interdominio.

Non è chiaro cosa stai cercando di realizzare, quindi è difficile fornire informazioni specifiche, ma alcune linee guida di base sulla prevenzione degli attacchi CSRF possono essere trovate su Foglio di cheat di Prevenzione CSRF di OWasp . Speriamo che questo ti aiuti a orientarti verso un percorso efficace verso i tuoi obiettivi di sicurezza.