¿Cómo funciona el token XSRF por solicitud? (Solución angular)

Question

¿Cómo funciona el token XSRF por solicitud? (Solución angular)

#1 de Anders (6 votos)

6

Quiero proteger mi aplicación contra XSRF. Aunque realmente no pude entender cuál es el problema y cómo funciona mi solución, después de algunas investigaciones se me ocurrió una solución que utiliza Angular. Hasta donde llegué, mi solución requiere los siguientes pasos:

El cliente envía una solicitud para mi SPA.
Envío un token XSRF (no solo HTTP para que JS pueda leerlo). También guardo este token XSRF en la sesión de usuarios en el servidor.
Para cada solicitud POST quiero que mi cliente lea el token de XSRF y establezca un encabezado X-XSRF-TOKEN para este token.
Comprobaré cada solicitud comprobando si el encabezado de la solicitud y la sesión del usuario coinciden con el token XSRF. Si lo hacen, también verificaré la autenticación de JWT si es necesario.
Después de validar el token XSRF, haré cambios en la base de datos. También cambiaré el token de XSRF nuevamente, y enviaré el token nuevo al usuario, y cambiaré el token para la sesión.

Pero no estoy seguro de cómo esto ayuda, si tengo una vulnerabilidad XSS, ya que cualquier código JavaScript inyectado también podría hacer lo mismo. Quiero entender el problema y cómo ayuda esa solución.

Para tu información, también estoy implementando la autenticación basada en JWT, usando Redis para la administración de sesiones, en un servidor Express.

web-application csrf

pregunta FurkanO 14.06.2016 - 19:03

fuente

1 respuesta

Lea otras preguntas en las etiquetas web-application csrf

XSS dentro de CSS cuando "está codificado? ¿Con qué vectores de infección generalmente se entregan Trojan.Linux.BillGates?

score 6 · Accepted Answer

¿El plan es bueno?

Tu plan me queda bien. El uso de un token CSRF es la solución estándar para este tipo de problema. Pero no debe sentirse seguro solo porque un extraño en Internet le dice que se ve bien; asegúrese de entender lo que está haciendo y por qué, de lo contrario, está obligado a cometer errores.

(Un punto secundario: no estoy seguro de que deba cambiar el token en cada solicitud).

Entonces, ¿por qué funciona?

De esta antigua respuesta de la mía:

El atacante engaña a la víctima para que visite http://evil.com que contiene un formulario que automáticamente realiza un POST a http://bank.com/transfer?to=evilHacker&amount=1000000 . Si la víctima ya ha iniciado sesión en su banco, el navegador enviará la cookie con el ID de sesión como de costumbre y no hay forma de que el servidor bancario sepa que la víctima no tenía la intención de transferir el dinero. Tenga en cuenta que esto se basa en que el navegador envíe la cookie con el ID de sesión a bank.com .

Entonces, ¿cómo puede ayudar un token CSRF? Si el bank.com siempre comprueba que hay un token aleatorio único para esa sesión en la solicitud, evil.com no puede falsificar la solicitud ya que el pirata informático malvado que ejecuta ese sitio no sabe qué es el token.

Pero ¿qué pasa con XSS?

Como usted dice en su pregunta, esto no ayudará si hay una vulnerabilidad XSS. De hecho, no hay protección CSRF que lo ayude en ese caso, pero si es vulnerable a XSS, tiene mayores problemas que los símbolos CSRF robados de los que debe preocuparse.

Entonces, lo único que hay que hacer aquí es trabajar en la protección de XSS.