Quand la fonction eval() de JavaScript n'est-elle pas mauvaise ?

Question

J'écris un code JavaScript pour analyser les fonctions saisies par l'utilisateur (pour une fonctionnalité de type feuille de calcul). Après avoir analysé la formule, je pourrait le convertir en JavaScript et l'exécuter eval() sur elle pour obtenir le résultat.

Cependant, j'ai toujours évité d'utiliser eval() si je peux l'éviter, car c'est un mal (et, à tort ou à raison, j'ai toujours pensé que c'est encore plus mal en JavaScript, car le code à évaluer peut être modifié par l'utilisateur).

Alors, quand peut-on l'utiliser ?

Answer 1

J'aimerais prendre un moment pour répondre à la prémisse de votre question - que eval() est " maléfique ". Le mot " maléfique Le terme "dangereux", tel qu'il est utilisé par les personnes travaillant dans les langages de programmation, signifie généralement "dangereux", ou plus précisément "capable de causer beaucoup de dégâts avec une commande d'apparence simple". Alors, quand est-il acceptable d'utiliser quelque chose de dangereux ? Quand vous savez quel est le danger et quand vous prenez les précautions appropriées.

Pour en venir au fait, examinons les dangers de l'utilisation de eval(). Il existe probablement de nombreux petits dangers cachés, comme pour tout le reste, mais les deux grands risques - la raison pour laquelle eval() est considéré comme un mal - sont les performances et l'injection de code.

• Performance - eval() exécute l'interpréteur/compilateur. Si votre code est compilé, c'est un gros problème, car vous devez appeler un compilateur potentiellement lourd au milieu de l'exécution. Cependant, JavaScript est encore principalement un langage interprété, ce qui signifie que l'appel à eval() n'est pas un gros problème de performance dans le cas général (mais voir mes remarques spécifiques ci-dessous).
• Injection de code - eval() exécute potentiellement une chaîne de code sous des privilèges élevés. Par exemple, un programme exécuté en tant qu'administrateur/Root ne voudra jamais exécuter eval() une entrée utilisateur, car cette entrée pourrait être "rm -rf /etc/important-file" ou pire. Encore une fois, JavaScript dans un navigateur n'a pas ce problème, parce que le programme est exécuté dans le propre compte de l'utilisateur de toute façon. Le JavaScript côté serveur pourrait avoir ce problème.

Venons-en à votre cas spécifique. D'après ce que j'ai compris, vous générez les chaînes vous-même, donc en supposant que vous faites attention à ne pas permettre à une chaîne comme "rm -rf quelque chose d'important" d'être générée, il n'y a pas de risque d'injection de code (mais n'oubliez pas que c'est le cas de très très dur pour s'en assurer dans le cas général). De plus, si vous vous exécutez dans le navigateur, l'injection de code est un risque assez mineur, je crois.

Pour ce qui est des performances, vous devrez les comparer à la facilité de codage. Je pense que si vous analysez la formule, vous pouvez tout aussi bien calculer le résultat pendant l'analyse plutôt que de lancer un autre analyseur (celui qui se trouve dans eval()). Mais il peut être plus facile de coder en utilisant eval(), et l'impact sur les performances sera probablement imperceptible. Il semble que eval() dans ce cas ne soit pas plus maléfique que toute autre fonction qui pourrait éventuellement vous faire gagner du temps.

Answer 2

eval() n'est pas mauvais. Ou, si c'est le cas, c'est un mal de la même manière que la réflexion, les entrées/sorties de fichiers/réseaux, le threading et l'IPC sont "mauvais" dans d'autres langages.

Si, pour votre objectif , eval() est plus rapide qu'une interprétation manuelle, ou rend votre code plus simple, ou plus clair... alors vous devriez l'utiliser. Si ce n'est ni l'un ni l'autre, alors vous ne devez pas le faire. C'est aussi simple que cela.

Answer 3

Quand vous faites confiance à la source.

Dans le cas de JSON, il est plus ou moins difficile d'altérer la source, car elle provient d'un serveur web que vous contrôlez. Tant que le JSON lui-même ne contient pas de données téléchargées par un utilisateur, il n'y a pas d'inconvénient majeur à utiliser eval.

Dans tous les autres cas, je ferais tout mon possible pour m'assurer que les données fournies par l'utilisateur sont conformes à mes règles avant de les transmettre à eval().

Answer 4

Soyons réalistes, les amis :

1. Tous les principaux navigateurs disposent désormais d'une console intégrée que le pirate en herbe peut utiliser abondamment pour invoquer n'importe quelle fonction avec n'importe quelle valeur - pourquoi se donnerait-il la peine d'utiliser une instruction eval, même s'il le pouvait ?

2. S'il faut 0,2 seconde pour compiler 2000 lignes de JavaScript, quelle est la dégradation de mes performances si j'évalue quatre lignes de JSON ?

Même l'explication de Crockford pour "l'ovale est le mal" est faible.

eval est diabolique, La fonction eval est la fonction la plus mal utilisée de l'interface utilisateur. JavaScript. Évitez-la

Comme Crockford lui-même pourrait dire "Ce genre de déclaration tend à générer une névrose irrationnelle. Ne l'achetez pas."

Comprendre l'évaluation et savoir quand elle peut être utile est bien plus important. Par exemple, eval est un outil judicieux pour évaluer les réponses du serveur qui ont été générées par votre logiciel.

BTW : Prototype.js appelle eval directement cinq fois (y compris dans evalJSON() et evalResponse()). jQuery l'utilise dans parseJSON (via le constructeur Function).

Answer 5

J'ai tendance à suivre Le conseil de Crockford para eval() et l'éviter complètement. Même les méthodes qui semblent l'exiger ne le sont pas. Par exemple, le setTimeout() vous permet de passer une fonction plutôt que eval.

setTimeout(function() {
  alert('hi');
}, 1000);

Même si c'est un de confiance je ne l'utilise pas, car le code renvoyé par JSON peut être confus, ce qui pourrait, au mieux, faire quelque chose de louche, au pire, exposer quelque chose de mauvais.