Accès sécurisé au serveur REST authentifié via Backbone.js?

Question

J'ai eu ce serveur REST (écrit par moi-même) qui est sécurisé par simple authentification HTTP.

Maintenant, j'ai réécrit l'application en utilisant backbone.js et je ne sais pas comment procéder pour authentifier mon client. Si je le fais dans JS utilisateur/passe serait visible.

Alors, comment dois-je modifier mon serveur ou mon côté client JS pour être sécurisé?

Auparavant, je viens de donner l'utilisateur & passer en PHP pour chaque demande à REST Server, s'il vous plaît guide moi, Merci.

Answer 1

D'accord, j'ai discuté avec mon collègue et est venu avec la meilleure idée jusqu'à présent:

Faites un contrôleur simple dans votre côté client (site) et nommez-le comme RESTAPI, il agira simplement comme un wrapper à votre serveur REST réel. Lorsqu'un utilisateur se connecte à votre site, sa session est créée. Le contrôleur RESTAPI connaît les informations d'identification de votre serveur REST réel authentifié HTTP et il accède au serveur REST au nom du backbone.

Exemple: Si je dois chercher

/messages/envoyé

de REST Server, maintenant au lieu que je vais frapper cette URL dans la collection backbone

site/restapi/messages/envoyé

Le RESTAPI Con Troller vérifie d'abord que l'utilisateur demandeur a une session correcte sur le site et qu'il est autorisé à aller chercher la ressource ou non.

donc pas de soucis au sujet des cookies non sécurisés ou laisser votre carte REST Server dans la plaine JS ou en utilisant une autre méthode obscure :)

Answer 2

L'authentification de base HTTP est sujette à des attaques d'écoute indiscrète et à des attaques de type intermédiaire. Il est recommandé d'utiliser HTTPS. Cependant, si ce n'est pas une option, vous pouvez toujours renvoyer un cookie au client et y saisir le nom d'utilisateur/mot de passe pour l'empêcher d'être affiché dans le fichier JS. Va sans dire que le mot de passe devrait au moins être crypté/haché pour des raisons de sécurité. Ensuite, le fardeau de la preuve sera sur le serveur pour obtenir les détails d'authentification du cookie. Maintenant, si vous n'avez aucun contrôle sur la modification du code côté serveur, vous n'avez plus d'autre choix que d'enterrer les informations d'identification dans une méthode globale ajaxSend() qui enverra le nom d'utilisateur/mot de passe à chaque Demande AJAX. Vous pourriez juste mettre cela dans un autre fichier .js et le rendre difficile à trouver, mais vous êtes plutôt limité à cette forme de sécurité. Bien que les cookies ne rendent pas votre vie plus sûre. (Ce serait bien si le mot de passe est hashed/encrypted). L'autre chose que vous pourriez faire est d'avoir une forme de sécurité un peu plus compliquée: le serveur envoie un nonce avec chaque réponse - le nonce serait 'signé' par le serveur en utilisant la clé secrète du serveur et vous pouvez utilisez-le pour "crypter" le nom d'utilisateur/mot de passe du côté client pour chaque requête. Votre serveur devra alors décrypter constamment les informations d'identification. C'est moins sujet à l'homme-dans-le-milieu, mais toujours pas infaillible. HTTPS vous sauvera de chacun des éléments ci-dessus si c'est une option pour vous.

Espérons que cela aide.

MISE À JOUR(comme par commentaire): L'essence de-ness reposant est l'absence d'état sur le serveur. Oui, pas de sessions! Par conséquent, vous devez envoyer les informations d'identification de l'utilisateur avec CHAQUE demande faite par le client au serveur. Si vous avez une page de connexion, il est très difficile d'être vraiment reposant car il n'y a pas de 'ressource' appelée connexion. Cependant, voici ce que vous pouvez faire:

1. visites de l'utilisateur page de connexion, entre les informations d'identification et de clics de login '
2. Envoyer requête POST au serveur avec ces informations d'identification - probablement/Connexion
3. Demandez au serveur retourner le ressource demandée pour laquelle l'authentification était nécessaire ET configurer le cookie avec les informations d'identification valides à utiliser dans la demande 'suivante'
4. Chaque requête suivante sera dirigée vers la ressource correspondante à une URL particulière avec une action particulière (GET, PUT, POST , EFFACER...). Le serveur doit vérifier les données d'authentification du cookie et décider si l'utilisateur est authentifié et effectuer une autorisation supplémentaire pour accorder l'accès si nécessaire.

Chaque demande doit s'identifier sans avoir le serveur à maintenir la session - qui est l'esprit de l'apatridie (et ness repos;)

Answer 3

Si vous avez accès à votre côté serveur code REST, vous pouvez redessiner l'authentification REST. La première fois, pour vous connecter, vous devez poster un nom d'utilisateur/mot de passe sur https, puis obtenir un identifiant de session qui peut être utilisé dans les demandes suivantes en le passant comme cookie.