¿Es adecuado un token CSRF por sesión con HTTPS?

Para evitar el CSRF, debe tener algo indiscutible en la parte explícita de la solicitud (GET o POST). Se prefiere colocarlo en la parte POST, ya que es más difícil filtrarlo y, por lo general, solo protege las solicitudes que desencadenan una acción, que debería ser POST.

Un valor aleatorio por sesión no se puede adivinar y debería hacer el trabajo. El mecanismo estándar de token anti CSRF integrado en ASP.net funciona así.

HTTPS evita que se pierda el token en el cable y también evita los ataques de reproducción. Así que un token de una sola vez no parece necesario.

Un token CSRF por sesión podría proporcionar una protección adecuada contra CSRF, pero se puede obtener una mejor seguridad al usar un token CSRF diferente para cada formulario.

En el caso de alguna otra vulnerabilidad, un atacante puede robar o usar incorrectamente un token CSRF. En ese caso, es una buena idea limitar el token CSRF tanto como sea posible. Este Ruby on Rails PR cambia el token CSRF para que solo sea válido para una acción y un método específicos, de modo que el CSRF robado Las fichas no pueden usarse para ningún otro propósito. Esto se describe un poco más en un blog de ingeniería de GitHub .

Esta es una defensa en medida de profundidad. En el caso de que alguna otra vulnerabilidad permita robar un token CSRF, es una buena idea limitar la validez de los tokens CSRF.