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

Тем не менее, я всегда уклонялся от использования, eval()если я могу избежать этого, потому что это зло (и, правильно или неправильно, я всегда думал, что это еще более зло в JavaScript, потому что код, который должен быть оценен, может быть изменен пользователем ).

Итак, когда можно использовать его?

Я хотел бы воспользоваться моментом, чтобы рассмотреть предпосылку вашего вопроса - это eval () - " зло ". Слово « зло », используемое людьми на языке программирования, обычно означает «опасный», или, точнее, «способный причинить много вреда простой командой». Итак, когда можно использовать что-то опасное? Когда вы знаете, в чем опасность, и когда вы принимаете соответствующие меры предосторожности.

Кстати, давайте посмотрим на опасности при использовании eval (). Вероятно, есть много небольших скрытых опасностей, как и все остальное, но есть два больших риска - причина, по которой eval () считается злом - это производительность и внедрение кода.

• Производительность - eval () запускает интерпретатор / компилятор. Если ваш код скомпилирован, то это большой успех, потому что вам нужно вызывать возможно тяжелый компилятор во время выполнения. Тем не менее, JavaScript по-прежнему в основном интерпретируемый язык, что означает, что вызов eval () не является большим ударом по производительности в общем случае (но см. Мои конкретные замечания ниже).
• Внедрение кода - eval () потенциально запускает строку кода с повышенными привилегиями. Например, программа, работающая как администратор / root, никогда не захочет eval () ввода пользователя, потому что этот ввод может быть «rm -rf / etc / Important-file» или хуже. Опять же, JavaScript в браузере не имеет этой проблемы, потому что программа все равно запускается под собственной учетной записью пользователя. JavaScript на стороне сервера может иметь эту проблему.

На ваш конкретный случай. Насколько я понимаю, вы сами генерируете строки, поэтому, если вы будете осторожны, чтобы не генерировать строку типа "rm -rf что-то важное", нет риска внедрения кода (но, пожалуйста, помните, это очень Трудно обеспечить это в общем случае). Кроме того, если вы работаете в браузере, то внедрение кода представляет собой довольно незначительный риск, я считаю.

Что касается производительности, вам придется сравнить ее с простотой кодирования. По моему мнению, если вы анализируете формулу, вы можете также вычислить результат во время анализа, а не запускать другой анализатор (тот, что внутри eval ()). Но это может быть проще для кода с использованием eval (), и снижение производительности, вероятно, будет незаметным. Похоже, что eval () в этом случае не более злой, чем любая другая функция, которая может сэкономить вам время.

eval()не зло Или, если это так, это зло так же, как отражение, файловый / сетевой ввод / вывод, многопоточность и IPC являются «злыми» в других языках.

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

Когда вы доверяете источнику.

В случае JSON более или менее сложно вмешаться в источник, потому что он исходит от веб-сервера, которым вы управляете. Пока сам JSON не содержит данных, загруженных пользователем, нет существенного недостатка в использовании eval.

Во всех других случаях я бы сделал все возможное, чтобы пользовательские данные соответствовали моим правилам, прежде чем передавать их в eval ().

Давайте настоящие люди:

1. Каждый крупный браузер теперь имеет встроенную консоль, которую ваш потенциальный хакер может использовать в изобилии для вызова любой функции с любым значением - зачем им пытаться использовать оператор eval - даже если они могут?

2. Если для компиляции 2000 строк JavaScript требуется 0,2 секунды, какова будет моя производительность, если я получу четыре строки JSON?

Даже объяснение Крокфорда «зло - это зло» слабо.

eval is Evil, функция eval является наиболее часто используемой функцией JavaScript. Избегай это

Как мог бы сам Крокфорд сказать: «Такое утверждение порождает иррациональный невроз. Не покупайте его».

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

Кстати: Prototype.js вызывает eval напрямую пять раз (в том числе в evalJSON () и evalResponse ()). jQuery использует его в parseJSON (через конструктор функций).

Я склонен следовать советам Крокфорда в для eval(), и избежать его полностью. Даже способы, которые, кажется, требуют этого, не делают. Например, setTimeout()позволяет вам передавать функцию, а не Eval.

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

Даже если это надежный источник, я не использую его, потому что код, возвращаемый JSON, может быть искажен, что в лучшем случае может сделать что-то нехорошее, а в худшем - показать что-то плохое.

Я видел, как люди выступают за то, чтобы не использовать eval, потому что это зло , но я видел, как те же люди динамически используют Function и setTimeout, поэтому они используют eval под капотами : D

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

Теперь эпилог к ​​этому посту:

Если вам ДЕЙСТВИТЕЛЬНО это нужно (80% времени eval НЕ требуется) и вы уверены в том, что делаете, просто используйте eval (или лучшую функцию;)), затворы и ООП покрывают 80/90% случай, когда eval может быть заменен с использованием другой логики, остальное - это динамически генерируемый код (например, если вы пишете интерпретатор) и, как вы уже сказали, оценка JSON (здесь вы можете использовать безопасную оценку Крокфорда;))

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

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

Производительность EVAL может быть увеличена с помощью следующего метода; вместо выполнения сценария вы должны вернуть функцию.

var a = eval("3 + 5");

Это должно быть организовано как

var f = eval("(function(a,b) { return a + b; })");

var a = f(3,5);

Кеширование f, безусловно, улучшит скорость.

Также Chrome позволяет легко отлаживать такие функции.

Что касается безопасности, использование eval или нет вряд ли будет иметь значение,

1. Во-первых, браузер вызывает весь сценарий в песочнице.
2. Любой код, который является злом в EVAL, является злом в самом браузере. Злоумышленник или кто-либо другой может легко внедрить узел сценария в DOM и сделать что-нибудь, если он / она сможет что-либо проверить. Не использовать EVAL не будет иметь никакого значения.
3. В основном это плохая защита на стороне сервера, которая вредна. Плохая проверка файлов cookie или плохая реализация ACL на сервере вызывают большинство атак.
4. Недавно в нативном коде Java была уязвимость Java и т. Д. JavaScript был и предназначен для работы в песочнице, тогда как апплеты были разработаны для работы вне песочницы с сертификатами и т. Д., Которые приводят к уязвимостям и многим другим.
5. Написание кода для имитации браузера не сложно. Все, что вам нужно сделать, это сделать HTTP-запрос к серверу с вашей любимой строкой агента пользователя. Все инструменты тестирования в любом случае имитируют браузеры; если злоумышленник хочет причинить вам вред, EVAL является их последним средством. У них есть много других способов справиться с вашей безопасностью на стороне сервера.
6. DOM браузера не имеет доступа к файлам и не имеет имени пользователя. Фактически ничто на машине, которой eval не может дать доступ.

Если ваша серверная безопасность достаточно надежна, чтобы кто-то мог атаковать откуда угодно, вам не стоит беспокоиться о EVAL. Как я уже упоминал, если EVAL не существует, у злоумышленников есть много инструментов для взлома вашего сервера независимо от возможностей EVAL вашего браузера.

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

"FirstName + ' ' + LastName"

В отличие от

"LastName + ' ' + FirstName"

Как мое отображаемое имя, которое может исходить из базы данных и не является жестко закодированным.

При отладке в Chrome (v28.0.1500.72) я обнаружил, что переменные не связаны с замыканиями, если они не используются во вложенной функции, которая создает замыкание. Я думаю, это оптимизация движка JavaScript.

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

Вот мой тестовый код:

(function () {
    var eval = function (arg) {
    };

    function evalTest() {
        var used = "used";
        var unused = "not used";

        (function () {
            used.toString();   // Variable "unused" is visible in debugger
            eval("1");
        })();
    }

    evalTest();
})();

(function () {
    var eval = function (arg) {
    };

    function evalTest() {
        var used = "used";
        var unused = "not used";

        (function () {
            used.toString();   // Variable "unused" is NOT visible in debugger
            var noval = eval;
            noval("1");
        })();
    }

    evalTest();
})();

(function () {
    var noval = function (arg) {
    };

    function evalTest() {
        var used = "used";
        var unused = "not used";

        (function () {
            used.toString();    // Variable "unused" is NOT visible in debugger
            noval("1");
        })();
    }

    evalTest();
})();

Здесь я хотел бы отметить, что eval () не обязательно должен ссылаться на нативную eval()функцию. Все зависит от названия функции . Таким образом, при вызове натива eval()с псевдонимом (скажем, var noval = eval;а затем во внутренней функции noval(expression);) тогда оценка expressionможет потерпеть неудачу, когда она ссылается на переменные, которые должны быть частью замыкания, но на самом деле это не так.

Microsoft объясняет, почему eval () работает медленно в их браузере, в блоге IE, рекомендации по производительности IE + JavaScript, часть 2. Неэффективность кода JavaScript .

Нижняя граница

Если вы создали или санировали свой код eval, это никогда не было злом .

Чуть подробнее

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

evalэто не зло , если он выполняется на клиенте, даже при использовании unsanitized ввода созданного клиента .

Очевидно, что вы всегда должны очищать входные данные, чтобы иметь некоторый контроль над тем, что потребляет ваш код.

аргументация

Клиент может выполнить любой произвольный код, который он хочет, даже если разработчик не кодировал его; Это верно не только для того, что уклоняется, но и призыв к evalсебе .

Единственный случай, когда вы должны использовать eval (), это когда вам нужно запускать динамический JS на лету. Я говорю о JS, который вы загружаете асинхронно с сервера ...

... И 9 раз из 10 вы можете легко избежать этого путем рефакторинга.

evalредко является правильным выбором. В то время как могут быть многочисленные случаи, когда вы можете выполнить то, что вам нужно, объединяя сценарий и выполняя его на лету, в вашем распоряжении обычно гораздо более мощные и поддерживаемые методы: нотация ассоциативного массива ( obj["prop"]такая же, как obj.prop) , замыкания, объектно-ориентированные методы, функциональные методы - используйте их вместо этого.

Что касается клиентского сценария, я думаю, что вопрос безопасности является спорным. Все, что загружено в браузер, подвергается манипуляциям и должно рассматриваться как таковое. Использование оператора eval () практически исключает риск, когда есть гораздо более простые способы выполнения кода JavaScript и / или манипулирования объектами в DOM, такими как строка URL в вашем браузере.

javascript:alert("hello");

Если кто-то хочет манипулировать своим DOM, я говорю: откажитесь. Безопасность для предотвращения любого типа атаки всегда должна быть ответственностью серверного приложения, точка.

С прагматической точки зрения нет смысла использовать eval () в ситуации, когда все можно сделать иначе. Тем не менее, есть конкретные случаи, когда следует использовать eval. Когда это так, это определенно можно сделать без риска взорвать страницу.

<html>
    <body>
        <textarea id="output"></textarea><br/>
        <input type="text" id="input" />
        <button id="button" onclick="execute()">eval</button>

        <script type="text/javascript">
            var execute = function(){
                var inputEl = document.getElementById('input');
                var toEval = inputEl.value;
                var outputEl = document.getElementById('output');
                var output = "";

                try {
                    output = eval(toEval);
                }
                catch(err){
                    for(var key in err){
                        output += key + ": " + err[key] + "\r\n";
                    }
                }
                outputEl.value = output;
            }
        </script>
    <body>
</html>

На стороне сервера eval полезен при работе с внешними сценариями, такими как sql или influenxdb или mongo. Там, где пользовательская проверка во время выполнения может быть выполнена без повторного развертывания ваших служб.

Например, служба достижений со следующими метаданными

{
  "568ff113-abcd-f123-84c5-871fe2007cf0": {
    "msg_enum": "quest/registration",
    "timely": "all_times",
    "scope": [
      "quest/daily-active"
    ],
    "query": "`SELECT COUNT(point) AS valid from \"${userId}/dump/quest/daily-active\" LIMIT 1`",
    "validator": "valid > 0",
    "reward_external": "ewallet",
    "reward_external_payload": "`{\"token\": \"${token}\", \"userId\": \"${userId}\", \"amountIn\": 1, \"conversionType\": \"quest/registration:silver\", \"exchangeProvider\":\"provider/achievement\",\"exchangeType\":\"payment/quest/registration\"}`"
  },
  "efdfb506-1234-abcd-9d4a-7d624c564332": {
    "msg_enum": "quest/daily-active",
    "timely": "daily",
    "scope": [
      "quest/daily-active"
    ],
    "query": "`SELECT COUNT(point) AS valid from \"${userId}/dump/quest/daily-active\" WHERE time >= '${today}' ${ENV.DAILY_OFFSET} LIMIT 1`",
    "validator": "valid > 0",
    "reward_external": "ewallet",
    "reward_external_payload": "`{\"token\": \"${token}\", \"userId\": \"${userId}\", \"amountIn\": 1, \"conversionType\": \"quest/daily-active:silver\", \"exchangeProvider\":\"provider/achievement\",\"exchangeType\":\"payment/quest/daily-active\"}`"
  }
}

Которые затем позволяют,

• Прямая инъекция объекта / значений через буквальную строку в формате json, полезная для шаблонных текстов

• Можно использовать в качестве компаратора, скажем, мы устанавливаем правила, как проверять квест или события в CMS

Против этого:

• Могут быть ошибки в коде и поломка вещей в сервисе, если они не полностью протестированы.

• Если хакер может написать скрипт в вашей системе, то вы в значительной степени облажались.

• Один из способов проверки вашего скрипта - хранить хеш ваших скриптов где-нибудь в безопасности, чтобы вы могли проверить их перед запуском.

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

Вопросы безопасности являются наиболее известными. Но также имейте в виду, что JavaScript использует JIT-компиляцию, и это плохо работает с eval. Eval чем-то напоминает «черный ящик» для компилятора, и JavaScript должен уметь предсказывать код заранее (до некоторой степени), чтобы безопасно и правильно применять оптимизацию производительности и область видимости. В некоторых случаях влияние на производительность может даже повлиять на другой код за пределами eval.

Если вы хотите узнать больше: https://github.com/getify/You-Dont-Know-JS/blob/master/scope%20%26%20closures/ch2.md#eval

Это нормально, если вы имеете полный контроль над кодом, который передается evalфункции.

Только во время тестирования, если это возможно. Также обратите внимание, что eval () намного медленнее, чем другие специализированные оценщики JSON и т. Д.

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

Итак ... когда не следует использовать eval ()? Eval () не должен использоваться, только когда есть вероятность, что третье лицо может изменить его. Например, перехватить соединение между клиентом и вашим сервером (но если это проблема, используйте HTTPS). Вы не должны использовать eval () для анализа кода, написанного другими людьми, как на форуме.

Если это действительно нужно, eval - это не зло. Но 99,9% случаев использования eval, с которыми я сталкиваюсь, не нужны (не считая setTimeout).

Для меня зло - это не производительность или даже проблема безопасности (ну, косвенно, это и то и другое). Все такие ненужные использования eval добавляют к адскому обслуживанию. Инструменты рефакторинга скинуты. Искать код сложно. Непредвиденные последствия этих уловок легион.

Когда eval () JavaScript не является злом?

Я всегда пытаюсь отговорить от использования eval . Почти всегда доступно более чистое и удобное решение. Eval не нужен даже для анализа JSON . Eval добавляет в ад обслуживания . Недаром его осуждают такие мастера, как Дуглас Крокфорд.

Но я нашел один пример, где его следует использовать:

Когда вам нужно передать выражение.

Например, у меня есть функция , которая строит общий google.maps.ImageMapTypeобъект для меня, но я должен сказать ему рецепт, как он должен построить URL плитки из zoomи coordпараметров:

my_func({
    name: "OSM",
    tileURLexpr: '"http://tile.openstreetmap.org/"+b+"/"+a.x+"/"+a.y+".png"',
    ...
});

function my_func(opts)
{
    return new google.maps.ImageMapType({
        getTileUrl: function (coord, zoom) {
            var b = zoom;
            var a = coord;
            return eval(opts.tileURLexpr);
        },
        ....
    });
}

Мой пример использования eval: импорт .

Как это обычно делается.

var components = require('components');
var Button = components.Button;
var ComboBox = components.ComboBox;
var CheckBox = components.CheckBox;
...
// That quickly gets very boring

Но с помощью evalнебольшой вспомогательной функции он выглядит намного лучше:

var components = require('components');
eval(importable('components', 'Button', 'ComboBox', 'CheckBox', ...));

importable может выглядеть так (эта версия не поддерживает импорт конкретных элементов).

function importable(path) {
    var name;
    var pkg = eval(path);
    var result = '\n';

    for (name in pkg) {
        result += 'if (name !== undefined) throw "import error: name already exists";\n'.replace(/name/g, name);
    }

    for (name in pkg) {
        result += 'var name = path.name;\n'.replace(/name/g, name).replace('path', path);
    }
    return result;
}

Эвал не злой, просто неправильно

Если вы создали код, входящий в него, или можете доверять ему, все в порядке. Люди продолжают говорить о том, что пользовательский ввод не имеет значения с eval. Ну вроде ~

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

В зависимости от того, где находится eval, многие веб-сайты используют SPA, и eval может упростить пользователю доступ к внутренним компонентам приложения, что в противном случае было бы нелегко. Теперь они могут создать поддельное расширение для браузера, которое может записывать данные в eval и снова красть данные.

Просто должен понять, какой смысл использовать Eval. Генерация кода на самом деле не идеальна, когда вы можете просто создавать методы для таких вещей, использовать объекты или тому подобное.

Теперь хороший пример использования eval. Ваш сервер читает файл swagger, который вы создали. Многие из параметров URL создаются в формате {myParam}. Таким образом, вы хотите прочитать URL-адреса, а затем преобразовать их в строки шаблона без необходимости выполнять сложные замены, поскольку у вас много конечных точек. Таким образом, вы можете сделать что-то вроде этого. Обратите внимание, что это очень простой пример.

const params = { id: 5 };

const route = '/api/user/{id}';
route.replace(/{/g, '${params.');

// use eval(route); to do something

Генерация кода. Недавно я написал библиотеку под названием Hyperbars, которая ликвидирует разрыв между виртуальным домом и рулем . Это делается путем анализа шаблона руля и преобразования его в гиперскрипт . Гиперскрипт сначала генерируется в виде строки, а перед возвращением eval()превращается в исполняемый код. я нашелeval() в этой конкретной ситуации полную противоположность зла.

В основном из

<div>
    {{#each names}}
        <span>{{this}}</span>
    {{/each}}
</div>

К этому

(function (state) {
    var Runtime = Hyperbars.Runtime;
    var context = state;
    return h('div', {}, [Runtime.each(context['names'], context, function (context, parent, options) {
        return [h('span', {}, [options['@index'], context])]
    })])
}.bind({}))

Производительность eval() не является проблемой в подобной ситуации, потому что вам нужно только один раз интерпретировать сгенерированную строку, а затем многократно использовать исполняемый вывод.

Вы можете увидеть , как генерация кода было достигнуто , если вам интересно здесь .

Я считаю, что eval - очень мощная функция для клиентских веб-приложений и безопасная ... Такая же безопасная, как и JavaScript, а это не так. :-) Проблемы безопасности, по сути, являются проблемой на стороне сервера, потому что теперь, с помощью такого инструмента, как Firebug, вы можете атаковать любое приложение JavaScript.

Eval полезен для генерации кода, когда у вас нет макросов.

Для (глупого) примера, если вы пишете компилятор Brainfuck , вы, вероятно, захотите создать функцию, которая выполняет последовательность инструкций в виде строки, и вычислить ее для возврата функции.

Когда вы анализируете структуру JSON с помощью функции синтаксического анализа (например, jQuery.parseJSON), она ожидает идеальную структуру файла JSON (каждое имя свойства в двойных кавычках). Тем не менее, JavaScript является более гибким. Поэтому вы можете использовать eval (), чтобы избежать этого.