En general, sabemos que un token aleatorio agregado a cada solicitud es una buena solución contra CSRF. Pero, ¿con qué exactitud funciona? El servidor web genera el token, lo envía al cliente en forma oculta, luego este token se agrega a la solicitud y el servidor web lo valida (para mí es razonable). El segundo enfoque podría ser que el cliente genere el token y lo envíe al servidor web. Pero cómo el servidor web conoce el token, es correcto si no fue generado por el servidor web.
El token siempre lo genera el servidor, nunca el cliente. Usted tiene razón en que si el cliente generó el token, entonces el servidor no pudo verificar que fuera válido. Es por esto que cada esquema de mitigación de CSRF incluye un token generado por el servidor. Entonces, dado que el servidor creó el token, siempre sabe cuál debe ser el valor del token y puede validar que el cliente envió el token correcto.
Si una secuencia de comandos tiene varios formularios para manejar, como lo hace la mayoría del código MVC, la cookie que contiene el token CSRF será la misma para todos, por lo tanto, se eliminará el propósito del token CSRF, ya que cada token CSRF debe ser específico. / p>
Los tokens CSRF son un poco más complicados que eso. Estos son tokens que impiden que las personas publiquen formularios en su sitio web que causan efectos no deseados a sus usuarios. Te daré un ejemplo de lo que sucede con y sin
En su sitio web, tiene un formulario que permite a las personas que han iniciado sesión publicar un mensaje en el canal de chat principal.
<form action="postmessage/" method="post>
<textarea name="message"></textarea>
<input type="submit" value="Send!" />
</form>
Cuando se envíe este formulario, irá a "postmessage /". Esa página tomará el contenido del área de texto y la publicará en la fuente junto con la identificación del usuario.
Ahora, imagina que vamos a un sitio que no es confiable. En ese sitio, existe el siguiente código
<form action="fakesite.fake/postmessage/" method="post" id="secretform">
<input type="hidden" name="message" value="Go to betterfakesite.fake its much better than this site">
</form>
<a href="membersarea/" id="fakelink">Go to Members Area">
<script>
document.getElementById("fakelink").onclick = function(e) {
e.preventDefault();
document.getElementById("secretform").submit();
</script>
Dado que no hay protección CSRF, cuando una persona haga clic en ese enlace, se enviará a su sitio e inmediatamente publicará un mensaje en el que se le pedirá que vaya a otro lugar.
Ahora, intentemos nuevamente con un token CSRF
<form action="postmessage/" method="post>
<input type="hidden" name="_csrf" value="GENERATEDBYSERVER">
<textarea name="message"></textarea>
<input type="submit" value="Send!" />
</form>
Cuando visita esta página, se genera un token para el formulario. Este token debe almacenarse en la sesión de usuarios en el lado del servidor. Cuando una persona envía el formulario, también lo hará a lo largo del token, que luego el servidor puede comparar con los tokens que tiene en la sesión de los usuarios. Si no está allí, rechace el mensaje. Si es así, acéptalo y elimina el token.
Ahora, cuando vaya a la página maliciosa y haga clic en el enlace, será redirigido a su sitio, pero no se habrá realizado ninguna publicación. El token CSRF te protegió.
Un token es tan seguro como lo creas. Al generar un token, guárdelo siempre en la sesión de los usuarios. En PHP es la variable $ _SESSION, y otros equivalentes de lenguaje. Lo que esto asegura es que una persona no puede generar una tonelada de estos tokens, luego usarlos contra otras personas.
JavaScript, de forma predeterminada, evita las solicitudes entre sitios, la página malintencionada no puede intentar adjuntar una copia de la página para extraer un token. Tampoco pueden crear secuencias de comandos de su servidor para hacerlo, ya que los tokens son únicos para la sesión del usuario.