http_only para cookies con tokens JWT

5

Estoy tratando de averiguar cómo usar los JWT que se transmiten en las cookies para un SPA. Debe estar en las cookies porque queremos que las solicitudes que no son ajax también envíen el jwt, y debería "funcionar" para todos. subdominios Tengo la cookie con el token que se genera y actualiza bien en el lado del servidor. Lo que estoy tratando de averiguar es cómo el lado del cliente debe obtener la información (is_logged_in y el nombre de usuario del usuario que inició sesión) y mantener esa información sincronizada con el ciclo de vida de la cookie del lado del servidor, ya que quiero que caduque después de 1 hora de ninguna solicitud, y debería aparecer en el navegador cuando eso sucede. Mi problema es que la información de usuario que quiero está en una cookie que es http_only para evitar XSS. He pensado en un par de opciones y me gustaría recibir opiniones sobre lo que es un compromiso de seguridad razonable:

1) envíe el token jwt idéntico en dos cookies, una utilizada para la autenticación real del servidor y amp; auth, que está marcado como http_only y seguro, y un segundo que es idéntico pero no es http_only, por lo que el cliente puede decodificarlo para obtener la información actual del usuario y el tiempo de caducidad.

2) envía la información del usuario en una segunda cookie que no es http_only y se ve a simple vista, pero que solo tiene un nombre de usuario registrado.

3) intenta que el cliente realice un seguimiento de la información de inicio de sesión por sí solo, esto parece problemático hasta ahora y es fácil de usar pero no tiene cookies inseguras volando por ahí.

Estoy pensando que me podría estar perdiendo algún aspecto de seguridad de las opciones anteriores, por lo tanto, pregunte aquí. gracias!

    
pregunta Iain Duncan 06.08.2015 - 22:23
fuente

2 respuestas

2

Esto suena bien y parece ser una buena solución para proteger la cookie de sesión contra los ataques XSS duplicando el valor del nombre de usuario en una cookie que no es solo http.

De todos modos, todas las comprobaciones de autorización se deben realizar en el lado del servidor. Entonces, si su cliente quiere hacer algo en el lado del servidor, envía la solicitud y luego el servidor realiza las comprobaciones de autorización, sin tener en cuenta la cookie que no es solo de http: solo utiliza la cookie de sesión protegida por http.

Si solo se utiliza el no http solo para fines de UI, no puede dañar la sesión porque el servidor examinará todas las solicitudes utilizando la cookie de sesión.

    
respondido por el SilverlightFox 10.08.2015 - 12:53
fuente
1

Tuve que leer su pregunta un par de veces para comprender lo que estaba describiendo en la opción uno: si la cookie de su sesión contiene un valor de texto claro predecible (en su ejemplo, el nombre de usuario autenticado y el hecho redundante de que se autentiquen) entonces su seguridad es fundamentalmente quebrantada. La sesión debe ser aleatoria o encriptada con valores / sales de inicialización variables en el tiempo.

En su segunda opción, suponiendo que la cookie de sesión es segura, ¿cuál es la consecuencia de que la segunda cookie insegura se vea comprometida? No mucho. Aunque vale la pena señalar que la mayoría de los medios a través de los cuales la cookie podría estar comprometida ascienden a un hombre en el tipo de ataque del navegador (incluido xss), momento en el que el atacante podrá explotar la cookie de sesión para crear solicitudes que se originan en el navegador de las víctimas. .

    
respondido por el symcbean 07.08.2015 - 03:56
fuente

Lea otras preguntas en las etiquetas