Comprender qué proteger con JWT

Question

Comprender qué proteger con JWT

#1 de crovers (2 votos)
#2 de Julian Knight (1 votos)

2

Así que escribí una aplicación ficticia, un formulario de inicio de sesión escrito en angular2, esto publica el nombre de usuario y la contraseña en una API de descanso. Si las credenciales son correctas, la API devuelve un JWT (codificado en el JWT con varios permisos). El JWT se guarda en el almacenamiento del navegador local.

Esto funciona absolutamente bien, el JWT se almacena en el almacenamiento local (según las guías que he leído en línea) y se puede acceder a cualquiera con un poco de conocimiento del navegador (elemento de inspección, recursos de vista, etc.), y una vez que acceda al El token JWT, se puede descifrar fácilmente sin el uso de una clave.

En mi aplicación angular2, decodifica la clave. Si la clave contiene "valor1 = Verdadero", permite al usuario acceder a cierta parte del sitio web. Si el valor de la clave es falso, devuelve al usuario a la página de inicio con un mensaje de acceso denegado. Nuevamente funciona bien en mi configuración de prueba.

Como la clave solo se almacena localmente, puedo crear un JWT en cualquier lugar, pegarlo en el almacenamiento local de mis navegadores con las credenciales correctas y luego puedo acceder a las áreas restringidas del sitio web.

¿He perdido algo, ya que esto realmente no parece seguro? Digamos que mi aplicación estaba en línea en mynewapp.com y el área mynewapp.com/private estaba protegida con esta autenticación JWT, la aplicación verificó un JWT válido, si se encuentra un token JWT válido, inspecciona el token, para ver si contiene los permisos relevantes para acceder a esta área, si no lo hace, qué es lo que impide que la persona detrás del navegador modifique el contenido del almacenamiento local de los navegadores para manipular los datos para acceder a esta área prohibida.

La única forma en que puedo pensar es:

Si JWT existe, realice una llamada a la API al servidor REST, si el usuario con JWT tiene permiso para acceder al área solicitada, devuelva verdadero y permita que la solicitud continúe dentro de Angular

De lo contrario, REST Api devuelve falso y el usuario no puede continuar.

jwt

pregunta crooksey 19.12.2016 - 16:10

fuente

2 respuestas

Lea otras preguntas en las etiquetas jwt

¿Por qué la cuenta de administrador del sistema * nix (root) tiene una contraseña segura si se inhabilitan los inicios de sesión remotos? ¿Este ataque de reflejo de DNS es un ataque de DOS o DDOS?

score 2 · Answer 1

Si los JWT se usan para autorización o autenticación, deben estar firmados o encriptados (lo que depende de su caso de uso exacto). Si tiene un recurso de autenticación y muchos otros recursos que desean consumir el JWT, firmar con una clave privada (en el recurso de autenticación), verificar con una clave pública (en los otros recursos) es un buen patrón. Si tiene varios servidores que funcionan como puntos finales de autenticación y como recursos, una clave de cifrado compartida puede funcionar bien, ya que el token se puede crear y cifrar y luego descifrar cuando sea necesario verificarlo.

Un JWT contiene reclamos, pero esos reclamos, como usted supone, no deben ser manipulables en el lado local.

La gente en Auth0 (exención de responsabilidad: no tiene ninguna relación con Auth0) tiene un montón más de información sobre los algoritmos de firma JWT estándar.

Una nota: las restricciones en Angular2 (como todas las páginas del lado del cliente) solo son adecuadas para la conveniencia del usuario final, por ejemplo, ocultar las páginas a las que no pueden acceder para que no se confundan. NUNCA debe contar con estos, ya que cualquier restricción en Angular2 / JS puede ser anulada de manera trivial. Antes de recuperar los datos restringidos o realizar operaciones restringidas, las comprobaciones de autorización del usuario deben realizarse en el SERVIDOR. De hecho, deben realizarse comprobaciones de autorización para cada operación, nunca confíe en el cliente, nunca.

score 1 · Answer 2

"¿Me he perdido algo?"

Tipo de - has visto ciertamente la falla principal con JWT. Eso es en realidad no proporciona mucho en el camino de la seguridad. En particular, es susceptible de "ataques de repetición".

Por lo que sé, no hay manera de asegurar completamente un sistema utilizando solo un JWT. Debe tener comprobaciones adicionales en el extremo del servidor.

Un método simple podría ser. por ejemplo, creación y token encriptado en el servidor que incluyó la dirección IP de los originadores. Compararía el token con una versión nueva en el servidor cada pocos contactos desde el navegador (o cada pocos segundos / minutos, según el tipo de aplicación y la cantidad de datos que transfiera). Restrinja el número de controles para evitar ataques de DOS.

Al ajustar la frecuencia con la que realiza la comprobación, puede equilibrar el uso de los recursos del servidor con la seguridad necesaria.

Estoy seguro de que hay muchas otras formas de hacer verificaciones similares. También podría reducir el riesgo al reducir el tiempo de espera en el token, esto no es tan seguro pero ciertamente ayuda.