¿Cuál es la forma correcta de implementar tokens de formulario anti-CSRF?

La mejor manera de crear la protección CSRF correctamente:

  

No.

La mayoría de los marcos comunes tienen esta protección ya incorporada (ASP.NET, Struts, Ruby, creo), o existen bibliotecas existentes que ya han sido revisadas. (por ejemplo, CSRFGuard de OWASP ).

Otra opción, dependiendo de su contexto, es forzar la reautenticación del usuario, pero solo para operaciones específicas y sensibles.

Según sus comentarios, si necesita implementar esto usted mismo, su solución no es tan mala, pero la simplificaría.
Puede generar un nonce criptográfico-aleatorio (el tiempo suficiente), almacenarlo en la memoria de la sesión y cambiarlo cada X minutos (también almacena el tiempo de caducidad en la sesión). En cada formulario, incluye el nonce en un campo de formulario oculto y compara ese valor cuando se publica el formulario.
Si el token del formulario coincide, está claro. Si no, puede aceptar por ejemplo el token anterior también, para manejar los casos de borde.

Aunque debo decir que he visto demasiados intentos fallidos para implementar esto por mi cuenta, realmente recomiendo esta ruta. Aún es mejor encontrar un paquete mínimo para hacer esto por usted.

Hay una buena explicación sobre OWASP: OWASP CSRF Prevention Cheat Sheet

En resumen, dicen que hay dos formas:

1. Agrega un token aleatorio a cada sesión de usuario. Solo si este token está presente y es correcto, se aplicarán los cambios; de lo contrario, la solicitud debería rechazarse. Es importante que el token solo se envíe con una solicitud POST, ya que las solicitudes GET pueden filtrar el token a diferentes lugares (historial del navegador, archivos de registro, etc.).

   También es posible generar un token por solicitud, pero esto conduce a problemas de usabilidad. Por ejemplo, el botón Atrás ya no funcionaría correctamente. Pero, por supuesto, la seguridad aumentaría.

   También asegúrate (para mejorar aún más la seguridad) de que el token solo se envíe por TLS, para que no haya ningún hombre en los problemas intermedios.

2. La otra opción es usar algún tipo de desafío: respuesta (por ejemplo, CAPTCHAs o tokens únicos).

La página OWASP también muestra algunas medidas que no funcionan. Estos son

• Uso de cookies (secretas)
• No se utilizan solicitudes GET
• Transacciones de varios pasos
• Reescritura de URL

Además de la respuesta de @Andreas Arnold, hay una alternativa. Implementé el Encrypted Token Pattern de OWasp.

Además de prevenir los ataques csrf, tiene la ventaja adicional de implementar la seguridad de objetos.

Solo aquellos que están autorizados a modificar objetos, pueden hacerlo. Otros no tendrán el texto o clave de cifrado correcto / válido. Normalmente cifro sessionId , timestamp , userId y / o recordId .

timestamp previene las repeticiones de ataques. sessionid aísla los cambios en esta sesión solamente userId aísla los cambios en este usuario solamente. Si incluye recordId , entonces al costo del procesamiento adicional usted gana más seguridad.

No creo que haya mucho error (aunque pueda estar equivocado;) al incluir una marca de tiempo en el token que se va a incluir e incluir esta marca de tiempo como un campo de formulario oculto, tal vez codificado en hexadecimal como ofuscación básica, puedes a continuación, compruebe la rigidez en la presentación.

Tiendo a pensar que la protección CSRF basada en token puede romperse con bastante facilidad: un atacante solo necesita saber cómo solicitar una página protegida CSRF, normalmente estas páginas tienen el token como un campo oculto. El atacante luego toma el token de la página (bastante trivial) y lo utiliza para construir un ataque CSRF.