¿Se garantiza que una cadena aleatoria en una cookie y un encabezado sean lo mismo para proteger contra XSRF?

3

En un esquema de cookie-to-header para enviar los tokens xsrf / csrf , el servidor establece un número pseudoaleatorio criptográficamente seguro como una cookie en la máquina del cliente. Se espera que el código de script java en la máquina cliente lea este código de la cookie, asegurando así con la misma política de origen del navegador que el script es de la misma página que el token. Luego, el script toma el token y lo agrega al encabezado de solicitud http con el nombre xsrf-token o algo así.

Mientras tanto, se supone que el servidor debe mantener un registro persistente del token xsrf emitido. Cuando llega la solicitud, toma el token del encabezado, lo compara con el registro, si coincide, ¡estamos dentro!

Aquí es donde comienza mi confusión. Dado que estamos almacenando la información en la cookie, inevitablemente se enviará con cada solicitud al servidor cuando se realice la solicitud http. Entonces, en el extremo del servidor no solo tenemos una, sino dos copias de la misma información. ¿Por qué no podemos hacer coincidir uno con el otro y aceptar la validez de la solicitud? ¿No vale la pena todo este ejercicio solo porque confiamos en que el navegador realice sus comprobaciones de origen cruzado? ¿No confiamos en las cookies? Para mi ingenuidad, al menos esto parece algo que podría funcionar. Por supuesto, podría estar muy equivocado y confiaría en usted para que me llame en caso de que me esté perdiendo algo básico.

Supongo que me estoy perdiendo algo. Así que aquí está el esquema que estoy implementando actualmente para mi sitio. Estoy utilizando tokens JWT para establecer y asegurar la identidad del usuario en una cookie httponly. Lo que propongo es emitir un token JWT separado (que contiene solo un número pseudoaleatorio) firmado por una clave completamente diferente y almacenarlo en una cookie de sesión. El código del lado del cliente lo lee, lo envía en el encabezado. El servidor lee el campo de cookie y encabezado y ve que son iguales. Luego, el servidor autentica el token JWT y ve que de hecho fue firmado por la clave en el servidor.

Mi pregunta es, ¿puede funcionar esto? Con esto no me refiero solo a la que involucra los tokens de JWT. También me refiero a la que no tiene ningún tipo de verificación para verificar que el servidor fue el emisor, es decir, el que solo tiene un número pseudoaleatorio y solo una única verificación para coincidir con la cookie. Cualquier sugerencia constructiva es bienvenida, incluso informarme sobre cómo estoy siendo un simple idiota. ¿Cuáles son algunas vulnerabilidades que se encuentran en este esquema? ¿Hay potencial para seguir investigando esto? ¿Es este un esquema suficientemente bueno para protegerse contra CSRF?

    
pregunta Debabrata Roy 29.10.2017 - 02:52
fuente

1 respuesta

1

Sí, el sistema que usted describe, simplemente comparando un valor de cookie con un valor de encabezado, es una defensa CSRF completamente funcional. De hecho, incluso tiene un nombre: doble envío de cookies . Es una excelente manera de hacer anti-CSRF cuando no desea mantener el estado del servidor. Tenga en cuenta que no necesita un JWT para esto. Cualquier número aleatorio seguro criptográficamente servirá.

Entonces, ¿por qué no siempre haces esto? ¿Por qué molestarse en guardar un token aleatorio en una sesión, cuando puede hacer que el cliente haga todo el trabajo pesado? Quizás las cookies de doble envío son algo más propensas a errores de implementación (por ejemplo, qué sucede si ambos están vacíos, problemas de tipeo suelto, etc.). Pero creo que la razón principal es que el token ordinario es más simple de entender. El servidor guarda un secreto que el atacante desconoce. El funcionamiento del doble envío es conceptualmente más difícil de entender.

    
respondido por el Anders 29.10.2017 - 10:08
fuente

Lea otras preguntas en las etiquetas