Лошо ли е това използване на eval() на Javascript?

Ако въвеждането на потребителя, което е eval()'d, винаги идва от потребителя, това трябва да е добре, единственият злонамерен JavaScript, който могат да изпълнят след това, е върху самите тях (което така или иначе биха могли да направят).

Ако говори с код от страна на сървъра, уверете се, че е валидиран като всеки друг външен вход.

Трябва също така да се уверите, че не може да бъде предварително попълнен от нещо като GET param и т.н.

Актуализация

Ако изпълнявате само основна математика с променливи, можете да използвате регулярен израз, за ​​да сте сигурни, че стойността е чиста от неаритметика и след това да я eval().

Например вашите уравнения могат да имат заместители CARD1 и CARD2.

var textarea = document.getElementsByTagName('textarea')[0],
    placeholders = ['CARD1', 'CARD2'];

document.getElementsByTagName('button')[0].onclick = function() {

    var value = textarea.value;

    // Strip placeholders
    var placeholderStripped = value.replace(new RegExp(placeholders.join('|'), 'g'), '');

    var safe = placeholderStripped.match(/^[\d\+\-\/\*\(\)]+$/);

    if (safe == null) {

        alert('Not a valid equation');
        return;

    }

    for (var i = 0, placeholdersLength = placeholders.length; i < placeholdersLength; i++) {
        value = value.replace(new RegExp(placeholders[i], 'g'), document.getElementById(placeholders[i].toLowerCase()).value);
    }

    document.getElementById('result').innerHTML = eval(value);

}

jsFiddle.

• Използвайте прости имена на контейнери и всички главни букви за удобство. Ако използвате по-сложни имена, може да се наложи да използвате функция за екраниране на регулярен израз, преди да ги join().
• Разрешаваме номера 0-9, +, -, /, *, ( и ). В момента не позволяваме десетични знаци. Това може да се добави, ако е необходимо.
• Когато най-накрая eval() входа, той трябва да съдържа само имена на заместители (които ще бъдат заменени) и основните аритметични знаци по-горе.
• Кодът, публикуван по-горе, е силно зависим от контекста на jsFiddle. Разбира се, никога няма да позволите имената на заместители да бъдат произволни - направете ги такива, каквито трябва да бъдат.

Не искам да бъда мелодраматичен, но това вероятно е една от най-лошите употреби на eval(), тъй като ще изпълнявате произволен, предоставен от потребителя JavaScript. Това би позволило на потребителя да изпълни код на вашия домейн, което би направило XSS атака абсурдно проста.

Редактиране: Като се замисля, може би съм твърде драматичен. Докато не поддържате тези функции и те просто се eval управляват на машината на клиента, тогава всъщност не позволявате нищо, което потребителят вече не може да направи в своята локална JavaScript конзола в браузъра. Просто се уверете, че не запазвате тези функции за други потребители, които да използват по-късно.

От гледна точка на сигурността това е ОК, тъй като потребителят може да разбие само собствения си браузър... което не е нищо ново.

Въпреки това, от гледна точка на дизайна на GUI, това би се считало за разхвърляно. Ако потребителят може да предостави вход, който нарушава интерфейса и разбира се с пълен достъп до скриптове, те могат, тогава това се счита за грешка на интерфейса.

Въпреки това, вие не правите комерсиален продукт и изглежда, че това ще ви спести много усилия, така че просто бих го предпочел.