Je sais que la sécurité est sans existence ou très difficile dans le côté du client JavaScript. Je sais que mon code côté serveur devrait finalement décider de qui il donne des données à ou accepte les données de.
Cela dit, est le suivant d'accord à faire. Par "ok", je veux dire s'il s'agissait de la méthode utilisée sur une nouvelle application populaire branchée cool web. Puis-je dormir la nuit sachant que je ne verrai pas "Super Cool Web App piraté, changez vos mots de passe!" Dans l'ensemble de la HN et de Reddit (ou de toute autre source d'informations, les gens se soucient de cette implémentation.
S'il n'est pas sécurisé. Pourquoi? Comment cette information peut-elle être obtenue (nom d'utilisateur et mot de passe)?
S'il est sécurisé? A quel point êtes-vous certain? Pourquoi est-ce sécurisé? Ce qui m'empêche d'obtenir cette information en dehors de mon incapacité évidente à l'instant.
Les réponses partielles sont les bienvenues. Je cherche juste une meilleure compréhension.
Modifier Je pense au cas d'une certaine tentative de vol d'informations d'utilisateur. Je crois comprendre que les cookies ne sont pas sécurisés car 1.) Les autres javascripts (via XSS ou autre) peuvent y accéder et parce que 2.) ils sont transmis dans la claire. I Figure SSL s'occuperait du deuxième problème et laissez simplement supposer que je suis capable d'empêcher XSS. Il semblerait maintenant que les cookies soient maintenant sécurisés, non? Je suis au courant de certaines vulnérabilités de navigateur supposées qui facilitent la fabrication de cookies. C'est ce qui m'a fait poser cette question. Compte tenu de toutes les choses qui fabriquent des cookies insécurité, c'est-ce (code ci-dessous) meilleur? http://jsfiddle.net/ktastrophy/vxejm/1/ ou voir code ci-dessous
(Testé uniquement en chrome)
5 Réponses :
Lorsque vous avez affaire à des valeurs sensibles stockées dans JavaScript, vous avez deux préoccupations de sécurité primaires:
Le deuxième élément ci-dessus devient beaucoup plus pertinent lorsque vous avez des applications à partir de plusieurs sources sur une seule page (par exemple, des applications Facebook). Dans ces cas, vous devriez prendre des précautions de ne pas exposer des variables sensibles en utilisant des fermetures à l'espace de noms. Vous faites déjà cela: votre objet Dans votre cas, je suppose qu'il n'y a pas d'autre code sur la page, à l'exception de votre propre et que la possibilité d'injection est minimale - votre code est sécurisé :)
utilisateur est déclaré à l'intérieur d'une fermeture. Cela empêche toute autre fonction JS de la page de pouvoir accéder à l'objet utilisateur .
Si les données que vous stockez apparaissent à l'intérieur du code source, NO, une méthode TOSTRING CODE> de fonction peut être utilisée pour activer un corps de fonction en code source. var f = (function () {
var x = "secret";
return function (a, b) { return a(b + x.length); };
})();
f(eval, "x//");
Ne répond pas à ma question, mais c'est très intéressant. Merci.
@Elliotb. J'ai répondu à la question dans le titre: "stocke des données sensibles dans une fonction d'auto-invoquance, insécurité?" Étant donné que d'autres qui trouvent que ce fil doit connaître l'histoire complète sur l'intégrité de la fonction avant de prendre des décisions avec des répercussions de sécurité éventuelles.
Parfaitement bien pour enregistrer la valeur d'une zone d'entrée dans une valeur JavaScript car, car l'utilisateur le saisit évidemment de cela.
Cependant! Il est généralement mal vu de stocker des mots de passe utilisateur comme texte brut n'importe où.
SSL le fera très dur (pas impossible suffisamment de temps, mais suffisamment de temps que c'est la majeure partie du Web utilise aussi sécurisé) pour un observateur malveillant pour intercepter et recréer un message. Stocker temporairement un mot de passe unique dans une variable JavaScript entré sur cette page est correcte. Mais, ne l'envoie pas
non. Ce que vous pouvez et devez faire est:
Dans le code JavaScript Clientside, il ne peut y avoir de sécurité. L'utilisateur entre toutes les données en tant que texte brut et, en tant que tel, on peut accéder à chaque script exécuté dans votre page. Par conséquent, vous aurez besoin de prévenir les XSS . Bien sûr, les cookies sont directement disponibles pour chaque script exécuté sur votre domaine pendant que les données cachées dans la portée de certaines fonctions ne sont pas une "variable globale", mais chaque script malveillant peut y accéder, tout comme votre propre application.
@Your Code: C'est vrai, personne ne peut accéder à l'objet de l'extérieur. Mais tout le monde peut accéder à l'élément d'entrée de mot de passe et tout le monde peut utiliser des objets du navigateur pour espionner la demande de l'API.
Comme votre exemple l'a fait, vous êtes parfaitement sûr.
Cela ne remplace cependant pas de cookies. Dans votre exemple, vous stockez le mot de passe dans le code localement, mais contrairement aux cookies, ces valeurs ne peuvent jamais être utilisées ultérieurement.
Il serait préférable de ne pas stocker la valeur du tout et utiliser l'authentification HTTP traditionnelle sur SSL.
En supposant que vous allez seulement que le processus de connexion réussisse lorsque le serveur vérifie avec succès le nom d'utilisateur et le mot de passe par rapport à la base de données, alors si le JavaScript est piraté ou non n'est pas pertinent. Disons que quelqu'un peut tripoter avec le nom d'utilisateur ou le mot de passe avant de soumettre. Et alors? Soit la personne connaît des informations d'identification valides ou non.
Je t'entends. J'ai édité ma question pour être un peu plus clair.
Si vous considérez que les cookies ne sont pas sécurisés, vous devriez simplement abandonner l'idée d'une application Web sécurisée. Ils sont essentiellement l'un des piliers fondamentaux de la sécurité des applications Web, donc si vous pensez qu'ils sont vulnérables, il n'y a pas d'alternative.