Asegurar una aplicación de JavaScript con un backend RESTful

5

Pasé por la pregunta Asegurando un JavaScript individual Aplicación de la página con backend RESTful que tiene discusiones / opciones para asegurar una aplicación del lado del cliente Javascript que invoque las API RESTful.

Sin embargo, a partir de las discusiones, no está claro cómo el "secreto compartido" que se usa para calcular el HMAC se mantiene seguro en el lado del cliente. El almacenamiento de dicho secreto compartido en una cookie (a la que se puede acceder desde scripts) o incluso en el almacenamiento local no es bueno, ya que son vulnerables a las fugas. ¿Se generan dinámicamente las claves para que cada viaje de ida y vuelta al servidor devuelva una nueva clave que se utilizará para calcular el HMAC para el próximo viaje de ida y vuelta?

    
pregunta mithrandir 03.04.2015 - 05:24
fuente

2 respuestas

1

Primero, algunas cosas:

  • No hay un secreto compartido en respuesta de Thomas Pornins a la pregunta vinculada. El servidor usa un secreto que solo sabe para calcular el HMAC. Luego, el cliente obtiene ese HMAC y lo envía al servidor en cada pedido como un token de autenticación. El servidor puede verificarlo recalcularlo con el secreto de los servidores. Tenga en cuenta que el cliente nunca calcula un HMAC.
  • En lugar de implementar esto usted mismo, es probable que desee utilizar una solución existente, como JWT.

Pero aún así, el HMAC o JWT o lo que sea, deben mantenerse seguros del lado del cliente. Personalmente, lo puse en un almacenamiento local, pero una cookie también podría funcionar. Se descartan estos ya que son vulnerables a las "fugas". Puede ser cierto que el malware que se ejecuta como root, o alguien con acceso físico, podría robar estos. Eso es un riesgo Pero aquí está la cuestión: todos los sistemas de inicio de sesión, desde los identificadores de sesión antiguos hasta los JWT modernos, funcionan al permitir que el cliente almacene un secreto. Si no puede aceptar ese riesgo, no puede iniciar sesión y necesitará que el usuario vuelva a escribir la contraseña en cada solicitud. (Pero quién sabe, el malware que puede leer el almacenamiento local también podría leer las pulsaciones de teclado ...)

No estoy seguro de lo que quieres decir con el uso de un nuevo secreto para cada viaje de ida y vuelta, pero no pudo resolver el problema anterior. En la primera solicitud, el cliente se autentica con una contraseña y obtiene un secreto que puede usar para la autenticación futura a cambio. En la siguiente solicitud, el cliente debe autenticarse nuevamente. O bien, ha guardado el secreto y puede usar eso. O no, y luego el usuario tiene que volver a escribir la contraseña.

    
respondido por el Anders 13.05.2018 - 11:08
fuente
0

Mis siete centavos aquí ... Nada puede ser 100% seguro. Pero el 99% es factible. Podría usar el HMAC o incluso un algoritmo RSA con JWT (supongo que está bien versado en JWT. Si no, aquí hay un buen artículo ). El token se genera utilizando dicho algoritmo una vez en cada inicio de sesión exitoso. El secreto solo se guarda en el lado del servidor, pero se han utilizado client nonces (lea más aquí ). Podría pasar el secreto entre el cliente y el servidor, pero tendría que ser dinámico y la generación de tokens podría afectar el rendimiento. Puede desactivar el acceso a las cookies a través de scripts habilitando la propiedad HttpOnly en las cookies que se emiten desde el servidor. También puede establecer tiempos de caducidad cortos para los tokens, por lo que, en caso de robo, caducarán poco después. Asegúrese de establecer TLS 1.0 o superior para todas y cada una de las comunicaciones entre el cliente y el servidor, y quizás un poco de monitoreo y alerta sobre los eventos generados desde la aplicación. Todo lo mejor :)

    
respondido por el zer0kompression 14.03.2018 - 04:56
fuente

Lea otras preguntas en las etiquetas