Per prevenire gli attacchi CSRF la creazione di un cookie crittografato con un nonce impedisce un attacco CSRF? Inoltre, a quella verifica il referrer contro l'origine del bersaglio. Non riesco a modificare migliaia di pagine per incorporare il token in ogni invio e non ho lo stato di sessione.
For preventing CSRF attacks does creating an encrypted cookie with a nonce prevent a CSRF attack?
No, il fatto che determinati cookie non possano difendersi da Cross Site Request Forgery, perché il browser invierà comunque i cookie, indipendentemente dal fatto che la richiesta fosse Cross-Site o Same-Site.
In addition, to that checking the referrer against the target origin. I cannot change 1000s of pages to embed the token in each submit and I do not have session state.
Leggi il foglio Cheat di prevenzione CSRF OWSAP per i metodi raccomandati per prevenire CSRF. Esaminare in particolare le tecniche di verifica delle stesse origini che sono più facili da implementare rispetto ai token. Cerca anche la descrizione di OWSAP dei limiti di questa tecnica, se ce ne sono.
Se ricordo bene, il controllo dell'origine è una contromisura efficace contro CSRF per la maggior parte (se non tutti) dei client "principali".
In primo luogo, dobbiamo capire il problema principale di CSRF; il server si fida di ogni richiesta che inviamo, in altre parole, il server non garantisce che la richiesta sia stata inviata consapevolmente da un utente legittimo, per questo motivo, dobbiamo aggiungere un elemento per identificare correttamente ogni richiesta.
L'idea principale per proteggere againts CSRF è l'implementazione di un elemento unico e questo deve essere difficile da prevedere, quindi le misure come token o CAPTCHA sono buone soluzioni. Il CAPTCHA non è efficiente nella maggior parte dei casi, perché a un utente non piace introdurre valori sul CAPTCHA per ogni sito che visita, ricorda, ci deve essere un equilibrio tra sicurezza e prestazioni, in questo modo, la soluzione principale sarà essere token.
Ora, controllare l'origine non è sufficiente per proteggere contro CSRF; immagina un sito Web vulnerabile all'XSS, puoi iniettare uno script per eseguire un attacco CSRF; un altro esempio potrebbe essere un modulo modificabile in cui è possibile aggiungere o modificare elementi per personalizzare una pagina Web che potrebbe essere visitata per ogni utente dell'applicazione, è possibile aggiungere qualcosa come:
<img src="http://mywebsite/transfer?account=123456&quantity=1000000" />
Se l'applicazione web convalida l'origine, in questo caso la richiesta sarà valida, perché appartiene alla stessa origine.
Spero che questa informazione ti aiuti.
No, la crittografia del cookie non fa assolutamente nulla per proteggersi dagli attacchi CSRF, perché un utente malintenzionato non ha mai bisogno di accedere al cookie per preformare l'attacco. Il bowser lo invia automaticamente per il dominio su cui è stato impostato.
Il controllo degli header di riferimento e di origine invece è abbastanza buono, ma non perfetto in quanto il client potrebbe essere configurato per non inviare queste intestazioni.
L'invio del token nella richiesta è davvero l'unica soluzione perfetta, ma probabilmente sarai in grado di farla franca semplicemente controllando le intestazioni.