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

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

Отже, коли це нормально використовувати?

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

До речі, давайте розглянемо небезпеку використання eval (). Мабуть, існує багато невеликих прихованих небезпек, як і все інше, але два великі ризики - причину, через яку eval () вважається злом, - це продуктивність та введення коду.

• Продуктивність - eval () виконує інтерпретатор / компілятор. Якщо ваш код складений, то це великий удар, тому що вам потрібно викликати можливо важкого компілятора в середині виконання. Однак JavaScript все ще є переважно інтерпретованою мовою, а це означає, що виклик eval () не є великим успіхом у загальній справі (але дивіться мої конкретні зауваження нижче).
• Введення коду - eval () потенційно виконує рядок коду під підвищеними привілеями. Наприклад, програма, що працює як адміністратор / root, ніколи не захоче eval () вводити користувача, тому що цей вхід потенційно може бути "rm -rf / etc / важливий файл" або гірше. Знову ж таки, JavaScript у браузері не має такої проблеми, оскільки програма все одно працює у власному обліковому записі користувача. На серверному JavaScript може виникнути ця проблема.

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

Що стосується продуктивності, то вам доведеться зважити це проти простоти кодування. На мою думку, якщо ви аналізуєте формулу, ви можете також обчислити результат під час розбору, а не запустити інший аналізатор (той, що знаходиться в eval ()). Але кодування за допомогою eval () може бути простіше, і хіт продуктивності, ймовірно, буде непомітний. Схоже, що eval () в цьому випадку не є більш злим, ніж будь-яка інша функція, яка, можливо, може заощадити ваш час.

eval()не зло. Або, якщо це так, це зло так само, як відображення, введення / виведення файлів / мережі, нарізка ниток та IPC є "злом" іншими мовами.

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

Коли ви довіряєте джерелу.

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

У всіх інших випадках я намагаюся забезпечити відповідність даних, що надаються користувачем, моїм правилам перед тим, як подавати їх до eval ().

Давайте отримаємо справжніх людей:

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

2. Якщо для складання 2000 рядків JavaScript потрібно 0,2 секунди, що таке зниження продуктивності, якщо я оцінюю чотири рядки JSON?

Навіть пояснення Крокфорда про "eval - зло" є слабким.

eval - Зло, функція eval - це найбільш нецільова функція JavaScript. Уникайте цього

Як може сказати сам Крокфорд, "подібне твердження має породження ірраціонального неврозу. Не купуйте цього".

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

BTW: Prototype.js викликає eval безпосередньо п'ять разів (у тому числі в evalJSON () та evalResponse ()). jQuery використовує його в parseJSON (через конструктор функцій).

Я схильний слідувати порадам Крокфорд в для eval(), і уникнути його повністю. Навіть способи, які, як видається, вимагають цього не роблять. Наприклад, програма setTimeout()дозволяє передавати функцію, а не eval.

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

Навіть якщо це надійне джерело, я не використовую його, тому що код, повернутий JSON, може бути пошкодженим, що може в кращому випадку зробити щось вибагливе, в гіршому випадку, викрити щось погане.

Я бачив людей, які захищають не використовувати eval, тому що це зло , але я бачив, що ті ж люди динамічно використовують функцію та setTimeout, тому вони використовують eval під капотами : D

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

Тепер епілогом до цієї публікації є:

Якщо вам дійсно це потрібно (80% часу eval НЕ потрібен), і ви впевнені в тому, що робите, просто використовуйте eval (або краще функцію;)), закриття та OOP покривають 80/90% у випадку, коли eval можна замінити за допомогою іншого виду логіки, решта - це динамічно генерований код (наприклад, якщо ви пишете перекладача) і, як ви вже говорили, оцінюючи JSON (тут ви можете використовувати безпечну оцінку Crockford;))

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не є злом, якщо працює на клієнті, навіть якщо використовується несанізований вхід, створений клієнтом .

Очевидно, що ви завжди повинні санітувати дані, щоб мати певний контроль над тим, що витрачає ваш код.

Обґрунтування

Клієнт може запустити будь-який довільний код, який він хоче, навіть якщо розробник не кодував його; Це справедливо не тільки для того, що ухиляється, але і заклик до evalсебе .

Єдиний випадок, коли вам слід використовувати eval (), це коли вам потрібно запускати динамічний JS на льоту. Я говорю про JS, який ви асинхронно завантажуєте з сервера ...

... І 9 разів з 10 ви могли легко уникнути цього, рефакторинг.

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

Що стосується сценарію клієнта, я думаю, що питання безпеки є суперечливим моментом. Все, що завантажується в браузер, підлягає маніпуляції, і до цього слід ставитися. При використанні оператора eval () немає нульового ризику, коли є набагато простіші способи виконання коду JavaScript та / або маніпулювання об'єктами в DOM, наприклад, рядок URL у вашому браузері.

javascript:alert("hello");

Якщо хтось хоче маніпулювати їхнім DOM, я кажу розмахуючи. Захист для запобігання будь-якого типу атаки завжди повинен відповідати серверній програмі, періоду.

З прагматичної точки зору, використовувати 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 або influxdb або 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 додають пекла технічного обслуговування. Інструменти для реконструкції скидаються. Пошук коду важкий. Непередбачуваними наслідками цих овалів є легіон.

Коли JavaScript eval () не злий?

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

Але я знайшов один приклад, де його слід використовувати:

Коли вам потрібно передати вираз.

Наприклад, у мене є функція, яка будує 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: import .

Як це зазвичай робиться.

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. Ваш сервер читає створений вами файл. Багато параметрів 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 (), щоб уникнути цього.