Tengo una solicitud que utiliza un token de una sola vez incrustado en la página para garantizar la protección CSRF: un atacante podría engañar a mis usuarios para que realicen una solicitud ilícita, pero no pueden obtener el token, e incluso si se puede cambiar con cada solicitud y puede caducar.
Hasta ahora, tan seguro.
Quiero implementar la sincronización en segundo plano con un trabajador del servicio, para que un usuario pueda publicar datos sin conexión y luego enviar esa información más tarde cuando obtenga una conexión.
Sin embargo, eso significa que la página no está disponible para obtener el token CSRF, y cualquier token vinculado con la solicitud cuando el usuario la genera, puede que no sea válido en el momento en que se envían los datos.
Esto parece ser un problema general en cualquier sitio web progresivo, ¿cuál es la mejor práctica para manejarlo?
Creo que la sincronización en segundo plano podría solicitar un nuevo token, aplicarlo a los datos para enviarlo y luego enviarlo, y eso sigue siendo un bucle que un atacante CSRF no pudo aprovechar, pero no estoy seguro de eso. ¿Alguien puede confirmar esto de cualquier manera?
En este momento, los tokens CRSF aseguran que la solicitud proviene de una página específica, que tendrá que cambiar para que funcione cualquier proceso en segundo plano. En su lugar, tendrá que haber algún tipo de servicio de token CSRF, por lo que solo podremos asegurarnos de que el usuario haya hecho una solicitud anterior y recientemente de ese servicio. ¿Sigue siendo una protección adecuada contra la CSRF?