Почему использование функции eval в JavaScript - плохая идея?

Не будь eval () Саймоном Уиллисоном - 24ways.org/2005/dont-be-eval

Как указано в moduscreate.com/javascript-performance-tips-tricks - (new Function (str)) () более производительна, чем eval (str). Всего мои 2 цента :)

очевидно, новая функция (a) на 67% медленнее, чем eval (a) на chrome

для меня новые функции (а) на 80% медленнее последней версии Chrome на osx

Я добавил статическую функцию, просто чтобы сравнить производительность. jsperf.com/eval-vs-new-function/2

те же предостережения, что и include и require в PHP. eval также можно назвать "include_from_string" или "runtime_compile". Мало того, что это не зло, но я уверен, что это одна из фундаментальных причин создания сценариев - гораздо проще создать сценарий, который приближается к объекту, и начать его использовать / изменять без перекомпиляции, чем перекомпилировать DLL каждый раз. раз вам нужны перемены. С точки зрения высокого уровня Eval - это то же самое, что компилировать файл c в DLL, затем вызывать его «точку входа» и связываться с его »символом состояния (или заставить точку входа вернуть объект состояния).

Какая же тогда альтернатива?

На самом деле альтернатива - просто написать код, который этого не требует. Крокфорд подробно рассказывает об этом, и, если вам нужно его использовать, он в значительной степени говорит, что это недостаток дизайна программы и его необходимо переделать. По правде говоря, я тоже с ним согласен. JS, несмотря на все его недостатки, действительно гибок и позволяет сделать его гибким.

но когда вы получите ответ от сервера с помощью AJAX, вы получите текст ответа xmlHttp.responseText, и вам нужно будет использовать eval для его выполнения.

Неправда, у большинства фреймворков есть метод анализа JSON, и если вы не используете фреймворк, вы можете использовать JSON.parse (). Большинство браузеров поддерживают его, и если вы действительно в затруднительном положении, вы можете довольно легко написать парсер для JSON.

Я не верю этому аргументу, потому что уже сейчас несложно внедрить мошеннический код в приложение Javascript. У нас есть консоли браузера, расширения сценариев и т. д. Каждый фрагмент кода, отправляемый клиенту, не является обязательным для выполнения клиентом.

Дело в том, что мне проще внедрить код в ваш браузер. Допустим, вы используете eval в строке запроса. Если я обманом заставлю вас щелкнуть ссылку, ведущую на этот сайт с прикрепленной строкой запроса, то теперь я выполнил свой код на вашем компьютере с полным разрешением браузера. Я хочу записывать в журнал все, что вы вводите на этом сайте, и отправлять мне? Готово, и меня не остановить, потому что при выполнении eval браузер дает ему наивысшие полномочия.

Я использую его для обработки динамических формул, когда формула отправляется с сервера. Здесь нет угрозы безопасности, и единственной альтернативой было бы написать большую функцию JavaScript для деконструкции формул.

@Kevin Тогда как вы определяете функцию для поддержки ECMAScript 6 (ES6) без eval? Или Крокфорд рекомендует полностью избегать ES6?

@nuander Затем выполните большую функцию как отдельный файл .js и включите его, добавив в документ элемент сценария.

@DamianYerrick При обнаружении некоторых функций невозможно не использовать их. Тогда я бы задал вопрос, действительно ли стоит внедрять ES6 в этом сценарии. Если вам нужно выполнить обнаружение функции, чтобы увидеть, можете ли вы ее использовать, это означает, что вы должны учитывать сценарии, в которых вы не можете. На самом деле это означает, что вам нужно написать свой код дважды (один раз в ES5 и один раз в ES6). Я бы просто остался с ES5 или написал код на TypeScript и т.д., чтобы я мог перенести на ES6, когда мне больше не нужно поддерживать 5.

Зачем кому-либо оценивать строку запроса? В настоящее время вам даже не нужно POST, не говоря уже о GET, потому что есть веб-сокеты. И вы всегда можете изолировать iframe или использовать веб-воркер, где между ними передаются только «сообщения» и нет доступа к пространству имен друг друга.

Eval можно использовать для замены отсутствующих функций метапрограммирования, например шаблонов. Мне больше нравится компактный генератор, чем бесконечный список функций за функциями.

Пока строка не исходит от пользователя или ограничена браузером, вы можете. JavaScript имеет много возможностей для метапрограммирования, используя такие вещи, как изменение прототипов, obj [member], Proxy, json.parse, window, функции декоратора (наречия), где newf = decorator (oldf), функции более высокого порядка, такие как Array.prototype.map (f) , передача аргументов другим функциям, аргументы ключевого слова через {}. Можете ли вы рассказать мне о сценарии использования, в котором вы не можете использовать это вместо eval?

Только если ваша серверная безопасность - отстой. Безопасность на стороне клиента - полная чушь.

@JeffWalden, отличный комментарий. Я обновил свой пост, хотя понимаю, что с тех пор, как вы опубликовали, прошел год. Xnzo72, если бы вы немного уточнили свой комментарий (как это сделал Джефф), то я мог бы с вами согласиться. Джефф указал на ключ: «eval одной и той же строки несколько раз может избежать накладных расходов на синтаксический анализ». Как бы то ни было, вы просто ошибаетесь; №3 верен для многих сценариев.

@Prestaul: Поскольку предполагаемый злоумышленник может просто использовать любой инструмент разработчика для изменения JavaScript в клиенте, почему вы говорите, что Eval () открывает ваш код для атак путем внедрения? Еще не открыта? (Я, конечно, говорю о клиентском JavaScript)

@EduardoMolteni, нас не волнует (и мы действительно не можем запретить) пользователям запускать js в своих собственных браузерах. Атаки, которые мы пытаемся избежать, - это когда значения, предоставленные пользователем, сохраняются, а затем помещаются в javascript и eval'd. Например, я мог бы установить свое имя пользователя на: badHackerGuy'); doMaliciousThings();, и если вы возьмете мое имя пользователя, объедините его в какой-то скрипт и оцените его в браузерах других людей, тогда я могу запустить любой javascript, который захочу, на их машинах (например, заставить их +1 к моим сообщениям , разместите их данные на моем сервере и т. д.)

AFAIK, инструменты разработчика google-chrome и chromium делают отладку eval'ed кода так же, как отладку других файлов js. но вы не можете ставить точки останова.

В общем, # 1 верно для довольно многих, если не для большинства вызовов функций. Опытные программисты не должны выделять и избегать eval () только потому, что неопытные программисты злоупотребляют ею. Однако опытные программисты часто имеют лучшую архитектуру в своем коде, а eval () будет редко требоваться или даже думать о нем из-за этой лучшей архитектуры.

@frodeborli, я не согласен с вашим вступительным словом. eval принципиально отличается от вызова функции. Прочтите мой комментарий к EduardoMolteni (2 выше вашего) для объяснения. Инъекционные атаки, в частности, относятся к получению пользовательского ввода и разрешению его выполнения где-нибудь, кроме их собственного браузера. (например, сервер или браузер другого пользователя) Однако я согласен с тем, что eval требуется редко, если вы хорошо спроектируете свои приложения. Этого следует избегать, потому что почти всегда есть лучшее и более безопасное решение.

@TamilVendhan Конечно, вы можете ставить точки останова. Вы можете получить доступ к виртуальному файлу, созданному Chrome для вашего расширенного кода, добавив оператор debugger; в исходный код. Это остановит выполнение вашей программы в этой строке. Затем после этого вы можете добавить точки останова отладки, как будто это просто еще один файл JS.

Спасибо. Этот краткий ответ, который я только что сказал, будет именно моим. Я могу использовать eval в моей текущей задаче / контексте. Существует так много непонятных советов просто не использовать его.

@frodeborli Ваше второе утверждение также неверно. Многие опытные программисты / фреймворки все еще часто используют evil(). Взгляните, например, на SAP OpenUI5.

@ProfK Хорошо подумайте, прежде чем использовать eval()! Существуют более строгие CSP, препятствующие использованию eval(). Возьмем, к примеру, Firefox OS.

@AndreFiedler Ни одно из моих утверждений не является неправильным. Если хотите, можете не согласиться. Любая функциональность может быть реализована на любом полном языке Тьюринга. Лишь в нескольких языках есть eval, поэтому eval НЕ НУЖЕН - это просто удобство. Совершенно другой вопрос, является ли eval вызовом функции или языковой конструкцией.

@frodeborli да, это никогда не НУЖНО, но мое заявление касалось experienced programmers often have a better architecture in their code. Не так часто, как вы думали. ;)

@AndreFiedler У опытных программистов может быть плохой код. С этим мы можем согласиться. :) Но группа опытных программистов обычно имеет лучшую архитектуру, чем была у них, когда они были неопытными, вот что я хотел сказать.

webpack будет с вами спорить :)

eval не так уж и плох. Я использую его в своем Epic Random String Generator, и он отлично работает!

Если вы каждый раз выполняете другой код, компиляция и кеширование не принесут пользы, независимо от того, используете ли вы eval или нет.

(1) чем это отличается от require / include? Если вам нужно включить внешний код / ​​код пользователя, почему это вообще проблема? (2) современные движки javascript могут сообщить вам точную строку и смещение ошибок внутри оцененного кода, как если бы вы запускали этот код из anonymousScope.js. (3) чем это отличается от любого процесса компиляции? Я бы сказал, что условное создание функции с помощью eval часто бывает быстрее, чем написание функции с условиями в ней или использование глобальных переменных (например, ручное встраивание), когда эти сгенерированные функции вызываются много раз.

@Dmitry, я просто обращусь к 1 и 2: большая разница в том, что, если вы используете eval, вы программно генерируете код, и наиболее распространенная причина, по которой люди делают это, - это вводить предоставленную пользователем информацию (или код) в код . Это принципиально небезопасно, так как без нужды открывает ваш код для атак с использованием инъекций. Если вы используете генерацию кода для оптимизации, возможно, это законное использование, но это, безусловно, вариант использования меньшинства.

Наиболее частое использование eval - реализовать «требовать» функциональность, не изобретая новый синтаксический анализатор. Также я не уверен, что вы знаете, что такое атаки с использованием инъекций, но на стороне клиента вы не можете избежать инъекций, кроме как локальными объектами функций, а локальные объекты iife не могут быть затронуты ничем, кроме редактора памяти. На стороне сервера вам нужно быть осторожным, кому вы разрешаете выполнять произвольный код, но даже там он все еще используется для реализации требования и в качестве альтернативы оболочки.

@ Дмитрий, я думаю, вы в корне неправильно понимаете атаки с использованием инъекций ... Нет никакой угрозы от инъекций, сделанных на стороне клиента пользователем, просматривающим собственный контент. Нас беспокоит XSS, который связан с внедрением вредоносного контента от ДРУГОГО пользователя, предоставляя им доступ к странице, на которой зарегистрирован другой пользователь. Есть способы избежать этого, но если вы используете eval, это полностью зависит от знания и трудолюбие разработчиков. Если вы хотите требовать, просто используйте библиотеку, которая делает это правильно. См .: codereview.stackexchange.com/questions/25901/…

@Prestaul eval в xss опасен, но его можно смягчить, скрывая важные данные в локальных переменных внутри функций и проверяя учетные данные перед eval текста, загруженного из чужих доменов. например, вместо eval кода вы можете json проанализировать запрос на eval и проверить учетные данные объектов перед eval его свойства кода. Тем не менее, я не могу представить, что нужно оценивать xss.

Почему безопасность является проблемой, если клиент в любом случае может делать с нашим кодом все, что хочет? Грязная обезьяна ?

@PaulBrewczynski, проблема безопасности возникает, когда пользователь A сохраняет свою часть кода для evaluated, а затем этот небольшой фрагмент кода запускается в браузере пользователя B.

Хотя это правда - если ваш контент не динамический, зачем вообще использовать eval для него? Вместо этого вы можете просто поместить код в функцию и вызвать ее!

Просто, например, для анализа возвращаемого значения (например, JSON-строк, определенных сервером строк и т. д.), Полученного в результате вызова Ajax.

А ну понятно. Я бы назвал их динамическими, потому что клиент не знает заранее, что это такое, но теперь я понимаю, что вы имеете в виду.

За 3+ года, прошедшие с тех пор, как я ответил на этот вопрос, мое понимание происходящего, скажем так, углубилось. На самом деле происходит создание нового контекста выполнения. См. dmitrysoshnikov.com/ecmascript/chapter-1-execution-contexts

Разве использование eval не медленнее, чем просто парсинг JSON?

@Qix - запуск этого теста в моем браузере (Chrome 53) показывает, что оценка несколько быстрее, чем разбирать.

@PeriataBreatta А, странно. Интересно, почему. В то время я прокомментировал, что это не так. Тем не менее, Chrome нередко получает странное повышение производительности в определенных областях среды выполнения от версии к версии.

Здесь небольшая старая ветка, но из того, что я прочитал - не утверждая, что я сам проследил это - JSON.parse на самом деле eval вводит его на заключительном этапе. Так что с точки зрения эффективности требуется больше работы / времени. Но с точки зрения безопасности, почему бы просто не проанализировать? eval - отличный инструмент. Используйте его для вещей, у которых нет другого пути. Чтобы передавать функции через JSON, есть способ сделать это без eval. Этот второй параметр в JSON.stringify позволяет вам запустить обратный вызов, который вы можете проверить с помощью typeof, если это функция. Затем получите функцию .toString (). Если поискать, есть несколько хороших статей по этому поводу.

Хм, думаю, мне повезло, когда я впервые изучал JavaScript. Я всегда использовал document.getElementById для доступа к DOM; по иронии судьбы, в то время я сделал это только потому, что понятия не имел, как объекты работают в JavaScript ;-)

согласны. Иногда eval в порядке, например для ответов JSON от веб-сервисов

@schoetbi: Разве вы не должны использовать JSON.parse() вместо eval() для JSON?

@ Nyuszika7H: когда сможешь, конечно. Увы, есть еще несколько браузеров, в которых его нет.

@bobince code.google.com/p/json-sans-eval работает во всех браузерах, как и github.com/douglascrockford/JSON-js. Json2.js Дуга Крокфорда действительно использует eval внутри, но с проверками. Кроме того, он совместим со встроенной поддержкой JSON в браузере.

Конечно, вы можете использовать библиотеки, если хотите. Но все браузеры должны будут загрузить код библиотеки, даже если у них есть встроенная поддержка, поэтому они никогда не будут его использовать. В случаях, когда я уверен, что JSON будет безопасным и действительным как литерал JS, а также как JSON, я бы предпочел сэкономить лишний объем и пухлость для eval.

@bobince Есть что-то, что называется функцией обнаружения и полифиллами, для обработки недостающих библиотек JSON и других вещей (см. modernizr.com)

«eval - не всегда зло». Не так ли? Я не знаю ни одного случая, когда eval был бы лучшим вариантом. FWIW вы можете достичь большей части той же функциональности, используя конструктор Function (developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/…), что немного менее злобно.

Просто обновите приведенный выше код .. --hi there! - необходимо заключить в кавычки, так как это строка. eval ('al' + 'er' + 't (' + '«привет!»' + ')');

[]["con"+"struc"+"tor"]["con"+"struc"+"tor"]('al' + 'er' + 't(\'' + 'hi there!' + '\')')()

Ура, были сайты социальных сетей, которые ограничивали alert (), но разрешали eval () ?!

Вы также можете использовать Function () {}, но будьте осторожны при использовании их на сервере, если вы не хотите, чтобы пользователи перехватили ваш сервер, ха-ха-ха.

Да. Я нашел, по крайней мере, пока в Chrome, вариант использования, который кажется более эффективным. Запустите RAF, который вычисляет строку в заданной переменной на каждой итерации. Используйте setInterval для установки в этой строке только графически ориентированных вещей, таких как установка преобразований и т. д. Я пробовал много других подходов, таких как перебор функций в массиве или использование переменной для установки преобразований только для изменяемых элементов, но пока это кажется наиболее эффективным. Когда дело доходит до анимации, самый верный тест - это ваши глаза.

это можно сделать с помощью namespaceToTest[namespaceParts[i]], здесь нет необходимости в eval, поэтому if (typeof namespaceToTest[namespaceParts[i]] === 'undefined') { namespaceToTest[namespaceParts[i]] = {}; - единственное отличие от else namespaceToTest = namespaceToTest[namespaceParts[i]];.

Ни один движок javascript не может найти и оценить в коде со 100% гарантией. Поэтому он должен быть к этому готов в любой момент.

Не могли бы вы подсказать, как я могу оценить имя динамической переменной, локальное для функции, без eval? Функции Eval (и подобные) являются последним средством на большинстве языков, которые их содержат, но иногда это необходимо. В случае получения имени динамической переменной какое решение является более безопасным? В любом случае, сам javascript не обеспечивает реальной безопасности (серверная сторона, очевидно, является основной защитой). Если вам интересно, вот мой вариант использования eval, который я бы хотел изменить: stackoverflow.com/a/48294208

есть не только консоль разработчика, вы также можете ввести javascript: code в адресную строку, чтобы создать собственную консоль разработчика на странице, если ее нет, как в старых браузерах IE и мобильных устройствах.