flujo de trabajo de protección JWT y CSRF

Question

flujo de trabajo de protección JWT y CSRF

#1 de dirkt (1 votos)
#2 de RaISug (0 votos)

2

Tengo un esquema de autenticación y autorización personalizado basado en tres tokens JWT: token de referencia (opaco), token de acceso y token de actualización. El backend establece el token de referencia en una cookie y lo envía con cada solicitud al servidor.

Desde entonces, estoy usando cookies, necesito prevenir el ataque CSRF. He escrito este subproceso SO y este artículo stormpath , pero todavía no obtengo el flujo de trabajo, que debo seguir para prevenir el ataque CSRF.

Mi carga útil del token de referencia es similar a

{
    "iss": "http://galaxies.com",
    "exp": 1300819380,
    "scopes": ["explorer", "solar-harvester", "seller"],
    "sub": "[email protected]",
    "jti": "d9b9714c-7ac0-42e0-8696-2dae95dbc33e"
}

en lugar de la propiedad xsrfToken , estoy usando un campo estándar jti . Entonces, mi cliente tiene este token de referencia con este campo jti , este token de referencia se envía al servidor con cada solicitud, el servidor puede decodificar este token de referencia y encontrar el token de acceso correspondiente al valor jti en su caché. Ahora me pregunto si este esquema me impide los ataques CSRF o ¿debo hacer algunos pasos adicionales en el lado del servidor y del lado del cliente para hacer esto?

Lo que realmente no entiendo es por qué debo establecer un nuevo encabezado X-XSRF-TOKEN en el lado del servidor y qué debo hacer con este encabezado más adelante.

csrf jwt

pregunta Jacobian 29.08.2017 - 12:50

fuente

2 respuestas

Lea otras preguntas en las etiquetas csrf jwt

Reemplazo de la pantalla de nombre de usuario y contraseña con una pantalla de código PIN para facilitar el acceso móvil Este sitio web afirma que la contraseña + cookie cuenta como 2FA

score 1 · Answer 1

Estoy en la misma situación que usted, y aquí es cómo entiendo el proceso:

El servidor envía el token JWT a través de Set-Cookie ... ; Secure ; HttpOnly . Esto evitará que Javascript en el cliente lea el token JWT y, por lo tanto, evitará que los ataques XSS roben el token JWT.
El servidor también envía un token XSRF al que puede acceder el Javascript en el lado del cliente , ya sea en un encabezado adicional, en una cookie legible del lado del cliente o como respuesta a la solicitud del token JWT. Luego, el cliente debe agregar activamente este token XSRF a cada solicitud, por ejemplo, como un encabezado adicional. El token XSRF también forma parte del token JWT, por lo que el servidor puede verificar que ambos coincidan.

Esto evita los ataques CSRF, porque mientras el atacante CSRF puede hacer que la cookie con el token JWT se envíe junto con una solicitud, no puede leer el token XSRF y, por lo tanto, no puede agregar esto a la solicitud.
El token de actualización funciona de la misma manera.

Esto no evita el escenario en el que un ataque XSS ejecuta solicitudes al incluir el token XSRF. Solo evita que un ataque XSS robe el token completo y lo use en otro lugar. Sin embargo, dado que los ataques XSS pueden hacer casi cualquier cosa que pueda hacer Javascript del lado del cliente, esto es probablemente hasta donde se puede llegar.

Proteger el token JWT de acceso contra el robo a través de XSS no es tan importante, sin embargo, proteger el token JWT refresh contra el robo es extremadamente . Se espera que el token JWT de acceso tenga un corto tiempo de caducidad, pero un token JWT de actualización robado no puede ser revocado, ya que el token no tiene estado, por lo que le otorgará al atacante acceso ilimitado. Todavía se pueden cambiar las claves utilizadas para firmar el token JWT, haciendo que todos los tokens JWT sean inválidos.

El proceso hwole tampoco protege contra ningún tipo de ataque MITM, por lo que es importante usar https.

Como el XSRF realmente puede ser cualquier cosa, no veo por qué no se pudo usar el campo jti que ya está presente. Sin embargo, el esfuerzo adicional del lado del cliente para agregar esta información a cada solicitud es crucial.

score 0 · Answer 2

En resumen, el ataque XSRF podría explotarse cuando visita un sitio web de un atacante y hace clic en alguna forma que activa, por ejemplo, una transacción de dinero en un sistema bancario en línea que no tiene protección XSRF, por supuesto, también debe tener una sesión activa en ese sistema

Para que el ataque sea exitoso, todas las cookies de su sesión deben transferirse al sistema bancario y, dado que todas las cookies se transfieren de forma predeterminada por el navegador, el ataque será exitoso.

Por lo tanto, para evitar el ataque, el servidor debe solicitar algo adicional, en el caso de XSRF esa cosa es un token, llamado token XSRF.

En su caso, usó la cookie de referencia como cookie XSRF y como cookie de sesión, por lo que el ataque sería explotable. Lo que significa que debe separar el token XSRF de la cookie de referencia