Penso che potresti fraintendere un po '. L'inserimento di dati dannosi negli script non è realmente rilevante per CSRF. A volte viene utilizzato insieme a questo, ma ciò potrebbe descrivere in modo più accurato XSS. Un token CSRF non impedirebbe qualcosa di simile.
Una vulnerabilità CSRF è quando sei in grado di ingannare un utente per eseguire un'azione che solo loro sono autorizzati a eseguire, a loro insaputa.
Supponiamo che tu abbia effettuato l'accesso al tuo sito web bancario e che ci sia un modulo per trasferire denaro a qualcuno in cui inserisci il numero di conto personale e l'importo che desideri inviare e poi invia.
Tale modulo verrà inviato a un determinato URL e la richiesta sarà simile a questa.
POST / transfer
Host: bankingsite.com
Cookie: xxxxxxxxx
Sendto = 12345678 & importo = 1000
Ora l'applicazione guarderà il tuo cookie per determinare da quale account prelevare il denaro.
Ora immagina sul mio sito web che creo un modulo che invii a bankingsite.com/transfer che invia 1000 al mio account personale e lo sovrappongo con un "Clicca qui per vincere un iPad gratuito"
Ora se dovessi fare clic su di esso, genererebbe la stessa esatta richiesta di posta se tu fossi loggato nel sito bancario perché il tuo browser determinerebbe che tu hai una sessione attiva con bankingsite.com e aggiungerebbe il tuo cookie di sessione alla richiesta.
Bankingsite.com non ha idea che tu non abbia compilato quel modulo sul loro sito web. Pensano che sia una richiesta legittima e procedono a trasferire i tuoi soldi a me a tua insaputa.
Il problema qui è che il cookie di sessione viene inviato insieme alla richiesta. Un token CSRF è diverso da un cookie di sessione perché il token CSRF non verrà inviato solo perché il dominio di destinazione corrisponde.
Quindi diciamo che si codifica la propria applicazione bancaria per inviare un token csrf usando un'intestazione personalizzata quando l'utente carica il modulo di trasferimento. Quindi, quando l'utente invia il modulo di trasferimento, si passa il token csrf come campo nascosto e lo si convalida sul back-end prima di autorizzare la transazione.
Ora hai appena reso impossibile eseguire lo scenario di attacco sopra. Se qualcuno ha cliccato su quel pulsante ipad gratuito, la richiesta conterrebbe i cookie e i dati post, ma nessun token csrf valido perché l'utente malintenzionato non ha accesso ad esso e la richiesta verrebbe negata.