Digamos que el sitio web example.com tiene protección CSRF. Envían un token CSRF en un encabezado personalizado y en campos de entrada ocultos.
Por ejemplo, para agregar una nueva carpeta, su solicitud http debe contener el token CSRF. Lo que he observado es que si realiza la misma solicitud, con el token CSRF, pero sin una cookie de sesión todavía funciona.
¿Debería funcionar así, puedo crear una carpeta sin cookie de sesión, pero solo con el token CSRF?
En términos generales, no.
Normalmente, se supone que la protección de CSRF y la autenticación de sesión son conceptos completamente separados. Se supone que la responsabilidad de un token CSRF es una clave única para una solicitud; nada más, mientras que un identificador de sesión o token de sesión se supone para simplemente identificar a un usuario que tiene permiso para realizar la acción en primer lugar.
Debería tener ambos en su lugar a menos que el token CSRF tenga ambas responsabilidades de alguna manera (lo que, honestamente, indicaría que alguien intentó ser demasiado inteligente con su diseño de seguridad, y falló).
Una interesante. Si el token CSRF también identifica al usuario, entonces no puedo verlo como una vulnerabilidad en sí misma. Algunos sistemas pueden funcionar sin cookies (aunque usted menciona que este está diseñado para funcionar con con cookies) y puede pasar un token de autenticación en un campo de formulario oculto que se usa como identificador de sesión y como anti Token CSRF.
En su caso, como el sistema utiliza cookies, parece ser un defecto de autorización.
Debería probar otras pruebas para averiguar si se trata de una vulnerabilidad:
Nota: para crear dos sesiones, necesitarías un navegador diferente o podrías crear una en modo privado / de incógnito.
Por "sesión activa" Me refiero a una sesión actual a corto plazo en el sitio web (por ejemplo, una con una caducidad de 15 a 30 minutos aproximadamente). Para los sitios que implementan la funcionalidad "recordarme", esto debe implementarse mediante un mecanismo diferente que crea una nueva "sesión activa" cada vez que el usuario regresa, y un nuevo token CSRF para acompañarlo (en lugar de simplemente crear una sesión activa larga).
Si alguno de los anteriores sigue teniendo éxito, entonces ha descubierto una falla en la administración de la sesión.
Escenario 1: si el token se genera mediante un PRNG criptográficamente seguro, no es posible realizar un ataque básico como el que describe, incluso si el token de sesión no se envía a través de esa solicitud en particular. Trabaja también, así que en general esto no funciona.
Escenario 2: Sin embargo, si los tokens que genera su aplicación no son sólidos y tienen derivaciones, esto debería funcionar pero fallaría si los tokens de la sesión no lo acompañan, nuevamente como lo indica @ AgmLauncher en su respuesta.
Escenario 3 : el token CSRF falla + tienes el token de sesión, por ejemplo, a través de XSS - funciona.
Lea otras preguntas en las etiquetas web-application xss csrf