Es perfectamente posible usar el patrón de token del sincronizador junto con el soporte de navegación / multi-pestaña adecuado. Es solo si sigues el consejo cuestionable:
Para mejorar aún más la seguridad de este diseño propuesto, considere la posibilidad de aleatorizar el nombre del parámetro del token CSRF o el valor para cada solicitud
que tienes problemas. En realidad, no hay ninguna buena razón para hacer esto en cada solicitud.
El token CSRF solo tiene una ventaja al cambiar de lugar la autorización, generalmente en el inicio de sesión y otras rutas que cambian el estado de inicio de sesión (por ejemplo, registro, recuperación de cuenta, usuario de conmutación). Estos son los puntos en los que también debería estar ciclando su identificador de sesión, por lo que tiene sentido hacer ambas cosas a la vez. Cambiar la ID de sesión evita el secuestro de la sesión a través de la fijación de la sesión; el cambio del token CSRF evita un ataque CSRF a través de la fijación de la sesión.
Navegar de nuevo a una página en caché en el estado de cierre de sesión o de inicio de sesión anterior (o mantener una abierta en otra pestaña) y luego intentar romper algo se rompe, pero la mayoría de las personas probablemente no esperarán que funcione. en ese punto.
Puede agregar algún JavaScript para detectar esa situación si lo desea, verificando que la cookie de sesión coincida con la que se usó en el momento de la creación de la página. (O una cookie asociada que no es el identificador y no es httponly , según corresponda). Luego, si no coincide, puede agregar un div de advertencia y volver a cargar el enlace en la página, y / o evitar los controles de formulario activos. en la página de ser receptivo. Ejecutaría esa verificación onload , más onpageview para bfcache si está permitiendo el almacenamiento en caché, y posiblemente en un sondeo ocasional para detectar el caso de múltiples pestañas. (Esto también puede ser útil para capturar el tiempo de espera de sesión en el lado del cliente y presentar un error más amigable).