Creo que podría estar malinterpretando un poco. Inyectar datos maliciosos en scripts no es realmente relevante para CSRF. A veces se usa junto con él, pero eso describiría con más precisión XSS. Un token CSRF no evitaría algo como esto.
Una vulnerabilidad de CSRF es cuando puedes engañar a un usuario para que realice una acción que solo están autorizados a realizar, sin su conocimiento.
Digamos que ha iniciado sesión en su sitio web bancario y hay un formulario para transferir dinero a alguien donde ingresa el número de cuenta de las personas y la cantidad que desea enviar y luego presiona enviar.
Ese formulario se PUBLICARÁ en una url particular y la solicitud tendrá un aspecto similar al siguiente.
POST / transfer
Host: bankingsite.com
Cookie: xxxxxxxxx
Sendto = 12345678 & cantidad = 1000
Ahora la aplicación mirará su cookie para determinar de qué cuenta extraer el dinero.
Ahora imagine en mi sitio web que creo un formulario que se publica en bankingsite.com/transfer que envía 1000 a mi cuenta personal y lo superpongo con un "Haga clic aquí para ganar un iPad gratis"
Ahora, si hiciera clic en él, generaría la misma solicitud de publicación exacta si iniciara sesión en el sitio bancario porque su navegador determinaría que tiene una sesión activa en bankingsite.com y agregará su cookie de sesión a la solicitud.
Bankingsite.com no tiene idea de que no completó ese formulario en su sitio web. Piensan que es una solicitud legítima y proceden a transferirme su dinero sin su conocimiento.
El problema aquí es que la cookie de sesión se envía junto con la solicitud. Un token CSRF es diferente de una cookie de sesión porque el token CSRF no se enviará solo porque el dominio de destino coincida.
Así que digamos que usted codifica su aplicación de banca para enviar un token de csrf usando un encabezado personalizado cuando el usuario carga el formulario de transferencia de dinero. Luego, cuando el usuario envía el formulario de transferencia, pasa el token csrf como un campo oculto y lo valida en el backend antes de autorizar la transacción.
Ahora acaba de hacer imposible ejecutar el escenario de ataque anterior. Si alguien hizo clic en el botón del iPad gratuito, la solicitud contendría la cookie y los datos de la publicación, pero no un token csrf válido porque el atacante no tiene acceso a la misma y la solicitud será denegada.