Что представляет собой «неправильное использование» функции Javascript Eval? [закрыто]

Eval - общеизвестно спорная языковая особенность. Дуглас Крокфорд категорически отвергает это. Мне интересно, какие конкретные риски приносит Эвал. По этому вопросу Improper use of eval opens up your code for injection attacks.

Какое неправильное использование команды Eval, и какие дыры в безопасности они открывают?

Когда я реализовывал движок JScript, я выступал за то, чтобы печатать рубашки EVAL IS EVIL , но, к сожалению, мы так и не смогли обойти это.

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

Еще несколько мыслей в этом ключе смотрите в моих статьях 2003 года на эту тему:

Общее зло:

http://blogs.msdn.com/b/ericlippert/archive/2003/11/01/53329.aspx

Инъекция атаки зла:

http://blogs.msdn.com/b/ericlippert/archive/2003/11/04/53335.aspx

Большинство дыр в безопасности представляют собой дыры того же типа, что и в SQL-инъекции, а именно объединяют вводимые пользователем данные в код JavaScript. Разница в том, что, хотя есть способы обеспечить, чтобы это не происходило с SQL, с помощью JavaScript мало что можно сделать.

В качестве тривиального и бесполезного примера приведем упрощенный калькулятор JavaScript:

textbox1.value = eval(textbox2.value);

Одним из правильных примеров использования являются некоторые из упаковщиков JavaScript, которые сжимают JavaScript, вытаскивая общие слова и заменяя их короткими заменами из 1-2 символов. Затем упаковщик выводит все это вместе с кодом замены строки на основе сгенерированного словаря, а затем проверяет результат.

Есть некоторые вещи, которые невозможно сделать в JS без Eval подобных функций ( eval, Function, и , возможно , больше).

Взять applyк примеру. Его легко использовать при использовании обычных вызовов функций:

foo.apply(null, [a, b, c])

Но как бы вы сделали это для объектов, которые вы создаете с помощью нового синтаксиса?

new Foo.apply(null, [a, b, c]) не работает, и не делают аналогичные формы.

Но вы можете обойти это ограничение с помощью evalили Function(я использую Functionв этом примере):

Function.prototype.New = (function () {
    var fs = [];
    return function () {
        var f = fs[arguments.length];
        if (f) {
            return f.apply(this, arguments);
        }
        var argStrs = [];
        for (var i = 0; i < arguments.length; ++i) {
            argStrs.push("a[" + i + "]");
        }
        f = new Function("var a=arguments;return new this(" + argStrs.join() + ");");
        if (arguments.length < 100) {
            fs[arguments.length] = f;
        }
        return f.apply(this, arguments);
    };
}) ();

Пример:

Foo.New.apply(null, [a, b, c]);

Конечно, вы можете вручную создавать функции, которые Function.prototype.Newиспользуют, но это не только многословно и неуклюже, но и (по определению) должно быть конечным. Functionпозволяет коду работать с любым количеством аргументов.

Несколько прямым ответом с моей стороны была разработка ориентированной на разработчика области тестирования API. Мы дали текстовую область на странице и кнопку Run. Центральная точка страницы была для них, чтобы они могли испытать вещи в Javascript против нашего API-интерфейса для взаимодействия с iframe, что было не так легко сделать в локальной среде.

Все злонамеренное, что могло быть сделано в этом случае, могло также быть сделано разработчиком, открывшим свои инструменты F12.

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

В Firefox появилась новая экспериментальная функция asm.js, с которой я работал. Это позволяет скомпилировать ограниченное подмножество языка Javascript в нативный код. Да, это очень круто, но у него есть ограничения. Вы можете думать об ограниченном подмножестве Javascript как о C-подобном языке, встроенном в Javascript. Это на самом деле не предназначено для чтения или написания людьми.

Это ограниченное подмножество Javascript не позволяет мне вставлять сгенерированный во время выполнения код в скомпилированный код после его компиляции.

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

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

Тем не менее, мне нравится использовать evalдля двух видов вещей (хотя, возможно, могут быть и лучшие, менее злые альтернативы):

1. Поскольку evalэто способ «явного кеширования кода», его можно использовать для повышения производительности. Обратите внимание, что оптимизаторы постоянно улучшаются, но просто нет никакой гарантии относительно того, что они могут сделать для вас. Делая вещи явными в коде, вы действительно можете помочь оптимизатору принимать более разумные решения.
2. Он также может использоваться для предоставления базовых форм безопасности типов, а также других языковых функций, которые отсутствуют в JS, без ухудшения производительности.

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

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

У меня есть ситуация, когда eval выглядит как путь, вычисляя строку и возвращая существующую переменную, имя которой совпадает со строкой.

У меня есть несколько таблиц: table1ResultsTable, table2ResultsTable, tableNResultsTable. У меня есть переменные с одинаковыми именами, которые являются объектами данных JQuery. Я использую их для настройки таблиц и вызова функций с данными jQuery.

Каждой таблице присвоен класс = "resultsTable". Теперь мне нужно получить переменную при нажатии на таблицу. Я делаю это:

$('resultsTable).on('click', 'td', function(event) {
    var cResultsTable = eval(event.target.parentElement.parentElement.parentElement.id);
    [etc]
});

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