¿Con qué frecuencia debe ser la Actualización de Token en la seguridad CSRF?

7

Para comenzar con el fondo, esta publicación es lo que dice Jeff Atwood sobre los tokens CSRF. En esta misma página, continúa diciendo:

  

Un método de prevención aún más fuerte, aunque más complejo, es   aprovechar el estado del servidor: para generar (y rastrear, con tiempo de espera) un   clave aleatoria única para cada formulario HTML único que envíe a la   cliente. Usamos una variante de este método en Stack Overflow con gran   éxito.

Pero en esta publicación, Jeff nunca hace comentarios sobre cuándo y cómo deben actualizarse los tokens.

Estaba usando una técnica similar en una aplicación web en la que estaba trabajando. Funciona así:

  1. Siempre que el usuario envíe POST datos a mi servidor, se enviará un token csrf.
  2. Este token CSRF se almacena en una cookie criptográficamente sólida en la sesión del usuario.
  3. Si el token es válido, la solicitud del usuario se procesa y viceversa.
  4. Si la solicitud es válida, descarte el token antiguo en el lado del servidor y cree un token nuevo. La respuesta del servidor contiene un nuevo token csrf que se utilizará en la siguiente solicitud. El token anterior en todos los formularios de una página se actualiza con el nuevo para que la próxima solicitud se procese correctamente.

¿Es aconsejable actualizar los tokens después de cada solicitud POST o debería realizarse la actualización solo cuando el usuario realiza una solicitud GET y mantiene el mismo token hasta que se realice la próxima solicitud GET?

    
pregunta c0da 17.03.2012 - 08:20

1 respuesta

8

El punto principal de un token CSRF es que no se puede haber enviado desde otro sitio. Por lo tanto, (a) no puede ser predicho o detectado por un atacante, y (b) no se adjunta automáticamente a una solicitud de la forma en que lo es una cookie.

Por lo tanto, teóricamente, si un token CSRF nunca se revela a terceros, teóricamente, no tiene que caducar para nada. Pero luego corres el riesgo de que tu ficha se "filtre" de alguna manera. Por lo tanto, su período de caducidad debería ser lo suficientemente corto para combatir la posibilidad de que un token salga y se use contra su usuario.

Realmente no hay pautas, pero una buena técnica sólida es generar automáticamente un token en CADA solicitud que incluya un código de tiempo firmado, y luego aceptar tokens hasta una cierta edad.

Una función de ejemplo podría ser:

concat(current_time,salt,sha256_sum(concat(salt,userid,current_time,secret_string)))

El token contiene información de tiempo y sal, pero también contiene una firma que no se puede falsificar y que está vinculada al ID de usuario.

Luego puede definir su propio intervalo de caducidad: una hora, un día, 2 horas. Lo que sea. El intervalo en este caso no está vinculado al token, por lo que puede establecer las reglas de caducidad como desee.

Por lo menos, sin embargo, los tokens CSRF deben caducar cuando la sesión de inicio de sesión expira o cuando el usuario cierra la sesión. No hay ninguna expectativa por parte del usuario de que el formulario que usted trajo ANTES de cerrar sesión continuará funcionando DESPUÉS de que vuelva a iniciar sesión nuevamente.

    
respondido por el tylerl 17.03.2012 - 08:56