Ho mitigato lo scripting cross-site nel mio codice mediante convalida dell'input, caratteri di whitelisting (anche tag HTML) e l'uso di intestazioni di protezione X-XSS. Le correzioni che ho implementato per mitigare l'XSS mitigano l'attacco CSRF nella mia applicazione?
In un attacco CSRF, l'attaccante dal sito A può utilizzare il browser dell'utente U come trampolino per attivare una richiesta autenticata contro il sito contro il sito B, a condizione che l'utente U sia già autenticato contro il sito B e B non abbia protezione CSRF.
Un esempio potrebbe essere includere un'immagine sul sito A in questo modo:
<img src=http://site-B/unwanted_action?some_parameters>
Quando includi l'immagine verrà inviata una richiesta contro il sito B che include i cookie esistenti e le informazioni di autenticazione di base che l'utente U ha nel browser per il sito B. Quindi la richiesta sembra autenticata e il sito B verrà eseguito se non è presente alcuna protezione CSRF posto. Quindi tutto ciò che è necessario per l'attacco è che l'utente U visiti il sito A, consapevolmente perché l'autore dell'attacco potrebbe incorporare tale link in un sito pubblico del forum, o inconsapevolmente perché tale link è incorporato in un annuncio. E poiché questa è un'immagine, l'utente non deve compiere alcuna azione e probabilmente non si renderà conto che è successo qualcosa di brutto, come in Come sono stati hackerati milioni di modem DSL in Brasile, per pagare le prostitute di Rio .
Dato l'esempio di cui sopra, dovrebbe essere chiaro che non è necessario alcun XSS per eseguire un CSRF e che né TLS né la protezione del cookie di sessione contro la manomissione aiuteranno contro CSRF.
Volevo aggiungere un addendum alla risposta di @ steffenullrich (totalmente corretta): solo perché il suo esempio utilizza una richiesta GET per CSRF (perché è la più semplice da dimostrare), semplicemente rendendo tutte le richieste che cambiano lo stato solo utilizzabili tramite POST fa NON protezione contro CSRF. Un utente malintenzionato può ancora falsificare facilmente una richiesta POST. Alcuni modi per farlo:
<form> di POST al sito vulnerabile quando inviato, riempilo con <input> pre-compilato che fa ciò che vuoi che facciano, aggiungi JavaScript per inviare automaticamente il modulo e inserisci l'intero cosa in un piccolo invisibile <iframe> su un sito che tu (l'attaccante) controlla. La vittima visita il tuo sito, i carichi iframe, il JS invia il modulo come richiesta POST al sito vulnerabile, il browser della vittima invia i cookie, l'intestazione Authorization e / o qualsiasi altro metodo automatico di autenticazione (IPSec, TLS CERT cliente, semplice controllo dell'indirizzo IP, qualunque cosa), il server esegue l'azione richiesta e la vittima non vede nemmeno perché non sembra accadere nulla sulla pagina principale. Access-Control-Allow-Origin o altre intestazioni di risposta CORS al client della vittima, la richiesta verrà comunque elaborata dal server (e Fetch consente eventualmente di inviare richieste ciecamente senza usare CORS, come se solo inviato tramite un modulo di invio). I verbi HTTP diversi da quelli comuni (GET, POST e, in misura minore, HEAD e OPTIONS) sono più sicuri; I moduli HTML non sono autorizzati a utilizzare questi metodi e le richieste CORS che li utilizzano devono passare un controllo "preflight" in cui il client interroga il server prima di inviare la richiesta effettiva e non lo invierà affatto se il server non lo fa rispondere in modo appropriato. Tuttavia, la migliore protezione contro CSRF è quella di avere un valore segreto (allegato o correlato, ma diverso da, il token di sessione) che è incluso in moduli HTML validi (e quindi in richieste non forgiate da tali moduli) ma è diverso per ogni sessione utente in modo che l'aggressore non possa prevedere quale sarebbe il token anti-CSRF della vittima. Se questo token manca o non è corretto per la sessione dell'utente che invia, supponiamo che si tratti di un attacco CSRF e ignori l'azione richiesta.