AngularJS : masquer les données ajax de firebug et des sessions utilisateur

Question

Je suis en train de créer un site utilisant AngularJS qui permettra aux utilisateurs de créer des comptes sur le site et de se connecter de manière transparente sans rechargement de page. Pour créer un site comme celui-ci, j'utilise le routage AngularJS pour charger différents partiels et $http pour accéder aux scripts de php via xhr. Comme déjà mentionné, j'utilise php pour les scripts côté serveur et j'utilise mysql pour stocker mes données.

Mon problème est que sans rechargement de la page, les données soumises au serveur via le service $http apparaissent dans l'onglet réseau de firebug (ou d'un outil équivalent). Cela signifie que des données privées telles que des mots de passe peuvent être exposées via ces outils jusqu'à ce que la page soit fermée. J'aimerais maintenant trouver un moyen d'empêcher les utilisateurs de voir ces données dans n'importe quel outil. Je pourrais crypter les données côté client. Le problème avec cela est que les scripts sont toujours exposés. Quelqu'un d'autre a-t-il vu ce problème et trouvé un moyen de le contourner ?

Une autre chose que je dois considérer est la meilleure façon de stocker les sessions des utilisateurs dans angular ? Serait-il préférable d'utiliser les sessions de php et d'obtenir le statut de celles-ci en utilisant $http ou en utilisant des cookies ? Encore une fois, les deux méthodes présentent des problèmes liés à la sécurité. Pour les cookies, j'aurai besoin de crypter le contenu et avec le passage de données dans les deux sens par ajax en utilisant des variables de session, tout peut être accessible en utilisant firebug. J'aimerais donc connaître l'opinion des gens à ce sujet.

Answer 1

Pour le problème de visibilité du mot de passe, vous pourriez effectuer le hachage du mot de passe côté client. Le code javascript est visible oui, mais cela ne pose pas de problème. Une fonction de hachage est unidirectionnelle, votre mot de passe ne peut donc pas être récupéré sur la base du résultat du hachage. Le javascript peut avoir le sel codé en dur car il ne s'agit pas d'un secret ( https://stackoverflow.com/a/536756 ).

En option, vous pouvez implémenter un second hachage du côté serveur avant de le comparer à la valeur de la base de données. Mais cela n'offre une protection que dans les cas où vous avez une vulnérabilité qui conduit à la lecture de la valeur du mot de passe, mais où cette même vulnérabilité ne permet pas les mises à jour de la base de données.

Pour d'autres données, vous pouvez considérer l'échange de clés diffie-hellman.

Pour s'assurer que le javascript exécuté côté client est bien le script que vous avez servi, vous avez besoin de https. Cela protège également votre chaîne, mais n'affecte pas votre navigateur ou firebug ( Est-ce correct ? Firebug doit-il voir AJAX protégé par SSL ? ).

Je suis en train de mettre en œuvre quelque chose de similaire avec angularjs et php, mais j'ai décidé de ne pas utiliser le hachage côté client ou l'échange de clés diffie-hellman. Le scénario contre lequel vous vous protégez est assez difficile à mettre en œuvre. L'intrus doit avoir accès à votre navigateur avant et après votre connexion.