Acceso seguro al servidor REST autenticado a través de Backbone.js?

Question

He tenido este servidor REST (escrito por mí mismo) que está protegido por autenticación HTTP simple.

Ahora reescribí la aplicación usando backbone.js y no estoy seguro de cómo autenticar a mi cliente. Si lo hago en JS user/pass sería visible.

Entonces, ¿cómo debo modificar mi servidor o mi lado del cliente JS para estar seguro?

Anteriormente acabo de dar al usuario & pase en PHP para cada solicitud al servidor REST, por favor guíame, Gracias.

Answer 1

bien tuve una discusión con mi colega y se acercó con la mejor idea hasta el momento:

Hacer un controlador simple en el lado del cliente (sitio) y el nombre como RESTAPI, se acaba de actuar como un contenedor a su servidor descanso efectivo.

Cuando un usuario entra en su sitio, su sesión de se crean. El controlador RESTAPI conoce las credenciales de su servidor REST real HTTP autenticado y accede al servidor REST en nombre de la red troncal.

Ejemplo: Si tengo a buscar

/mensajes/enviado

desde el reposo del servidor, ahora en lugar Voy a golpear esta url en la recolección de la columna vertebral

sitio/restapi/mensajes/enviados

RESTAPI Con Troller también verifica primero que el usuario solicitante tenga una sesión adecuada en el sitio y el tiempo en que puede buscar el recurso o no.

Así que no se preocupa por las cookies inseguras o salir de su pase servidor REST en la llanura JS o utilizando cualquier otro método oscura :)

Answer 2

La autenticación HTTP básica es propensa a los ataques de espionaje y de hombre en el medio. Se recomienda usar HTTPS.

Sin embargo, si no es una opción, siempre puede enviar una cookie al cliente y tener el nombre de usuario/contraseña ingresados ​​allí para evitar que se muestre en el archivo JS. Huelga decir que la contraseña al menos debe ser encriptada/hash por razones de seguridad. Luego, la responsabilidad estará en el lado del servidor para obtener los detalles de autenticación de la cookie.

Ahora, si no tiene ningún control sobre la modificación del código del lado del servidor, prácticamente no tiene más opción que enterrar los detalles de la credencial en un método global ajaxSend() que enviará los detalles de nombre de usuario/contraseña con cada Solicitud de AJAX Podrías poner esto en otro archivo .js y hacerlo difícil de encontrar, pero estás más o menos restringido a esa forma de seguridad. Aunque, las cookies no hacen su vida más segura. (Sería bueno si la contraseña es hash/encriptada).

La otra cosa que podría hacer es tener una forma de seguridad un poco más complicada: haga que el servidor envíe una copia de seguridad con cada respuesta: el servidor 'firmará' el servidor usando la clave secreta del servidor y podrá Úselo para 'encriptar' el nombre de usuario/contraseña en el lado del cliente para cada solicitud. Su servidor tendría que descifrar constantemente las credenciales. Esto es menos propenso a man-in-the-middle pero aún no es infalible.

HTTPS le ahorraría cada una de las opciones anteriores si es una opción para usted.

Espero que esto ayude.

ACTUALIZACIÓN(según el comentario): La esencia del reparador-dad es la ausencia de estado en el servidor. Es decir, ¡sin sesiones! Por lo tanto, debe enviar las credenciales de usuario con CADA solicitud que el cliente haga del servidor. Si tiene una página de inicio de sesión, entonces es muy difícil estar realmente tranquilo ya que no hay un 'recurso' llamado inicio de sesión. Sin embargo, esto es lo que puede hacer:

1. usuario visita la página de inicio de sesión, introduce las credenciales y los clics 'login' solicitud POST
2. Enviar al servidor con estas credenciales - probablemente a/Login
3. Haga que el servidor devuelve la recurso solicitado para el que se necesitó autenticación Y establecer la cookie con las credenciales válidas para usar en la solicitud 'siguiente'
4. Cada solicitud posterior será dirigida al recurso correspondiente en una URL particular con una acción particular (GET, PUT, POST , BORRAR...). El servidor debe verificar los datos de autenticación de la cookie y decidir si el usuario está autenticado y realizar una autorización adicional para otorgar acceso si es necesario.

Cada solicitud deberá identificarse a sí mismo sin tener el servidor de mantenimiento de la sesión - que es el espíritu de la apatridia (y-dad reparador;)

Answer 3

Si tiene acceso al servidor de código RESTO lado, puede rediseñar la autenticación RESTO. La primera vez, para iniciar sesión, publica el nombre de usuario/contraseña en https, a su vez obtiene una identificación de la sesión que se puede usar en solicitudes posteriores pasándola como cookie.