Token CSRF en solicitud GET

Si estás generando los tokens de forma aleatoria segura, un atacante no puede inferir el siguiente token de los anteriores. Así que no debería haber ningún riesgo realista.

Otro punto importante aquí es usar SSL. Cualquier proxy / proxy inverso entre el usuario y el servidor ni siquiera puede ver los parámetros GET para registrarlos. Los únicos lugares donde se registra el token están en los dos extremos de la conexión SSL.

El inicio de sesión en el extremo del usuario (Historial, por ejemplo) ocurre después de hacer clic en el enlace. El inicio de sesión en el extremo del servidor no conlleva ningún riesgo (si no confía en el lugar donde se descifra el tráfico SSL, entonces hay problemas más grandes).

Las solicitudes GET deben ser idempotentes, lo que significa que no puede invalidar el token una vez que se usa porque cualquier solicitud de repetición no dará la misma respuesta.

Las solicitudes GET tampoco deben realizar cambios de estado en el sistema, por lo tanto, no se debe requerir que tengan protección CSRF. Incluso el cierre de sesión no debe ser una solicitud GET para el método que realmente ejecuta el cierre de sesión (aunque podría tener un enlace GET que navega a otra página antes de que una solicitud POST realice la acción).

Para solucionar el problema idempotente, con una solicitud GET repetida y con el mismo token CSRF suministrado, puede mostrar la respuesta almacenada en caché desde la primera solicitud, sin realizar ningún cambio de estado. Sin embargo, aún está violando el estándar si realiza cambios de estado, consulte rfc7231 :

  

Los métodos de solicitud se consideran "seguros" si sus semánticas definidas son
  esencialmente solo lectura

     

De los métodos de solicitud definidos por esta especificación, el GET, HEAD,
  Las opciones y los métodos TRACE se definen como seguros.

Como nota al margen, también argumentaría que los procesos que requieren un uso intensivo de recursos también deberían ser POST (con protección CSRF) en lugar de GET, de lo contrario, un atacante podría hacer un sistema DoS utilizando un vector CSRF.

Por lo tanto, si necesita CSRF para un método, entonces no implemente esto como un GET.

  

Teniendo en cuenta que cuando alguien inicie sesión en el token, ya estará invalidado e inutilizable si el atacante desea realizar CSRF.

Hay un caso de esquina si el usuario obtiene la dirección pero no puede usar el token (debido a fallas transitorias de la red, etc.). Es poco probable que esto sea lo suficientemente significativo como para preocuparse por un token CSRF, pero puede ser un problema para otros tokens más sensibles.

Sin embargo, los tokens CSRF de un solo uso tienden a plantear problemas de usabilidad, como romper la navegación y navegar por múltiples pestañas ... sin mencionar que son súper feos. :-) Dado que las solicitudes GET deben ser idempotentes y, por lo tanto, no necesitan protección CSRF, el token-in-URL suele ser un olor de diseño. Pero dudo que haya mucho que puedas explotar aquí.

Probablemente sea lo suficientemente seguro, pero no elimina por completo el problema de la navegación y el registro de hombro. Un atacante podría temporalmente hacer la Red de modo que pueda usar un token de navegación por el hombro antes de que el usuario tenga la oportunidad de hacerlo, y una solicitud puede aparecer en los registros pero no se invalida cuando el sitio web (o la base de datos, o la red) está inactivo durante un intento de pageload. Más allá de eso, no puedo pensar en ninguna vulnerabilidad que no ocurra también cuando pones el token en los datos POST.

No estoy seguro de que sea práctico invalidar todos los tokens después del uso. A menudo abro varias páginas en una nueva pestaña de fondo, por ejemplo, en foros SMF más antiguos, hago clic con el botón central en el botón de eliminar mensajes privados para que no sea necesario volver a cargar la página antes de que pueda eliminar otra. Puede generar un token único para todos los enlaces que aparecen en una página, pero luego llega a un nivel de complejidad en el que podría comenzar a usar HMAC en lugar de un token simple.