Это плохое использование eval () Javascript? - PullRequest
Новая
       4

Это плохое использование eval () Javascript?

2 голосов
/ 10 марта 2011

Я прочитал несколько вещей о Eval Javascript, поэтому я думаю, что мое использование имеет смысл.

Я нахожусь в классе информационной безопасности, и мы проводим статистический анализ лотерейных карточек . Тем не менее, наши карты бинго (и, вероятно, вряд ли будут жертвами этой конкретной ситуации). Однако наш текущий процесс сильно глючит, поэтому у меня была идея хранить данные карты на моем сервере, и позволить одноклассникам писать функции javascript в текстовой области, а затем нажимать кнопку, которая будет просто eval(textarea.value). Это позволило бы нам сделать довольно полезные вычисления для данных без особых проблем. У меня также была идея «сохранения процедур» в виде текста, который они могли бы загрузить в текстовую область и затем оценить.

Это плохая зона для eval()? Или несколько серая зона? Кроме того, с какими потенциальными проблемами я могу столкнуться? Очевидно, что они потенциально могут помешать их просмотру страницы, но пока я не делаю глупостей, простая перезагрузка страницы должна исправить это, верно?

Спасибо!

Ответы [ 3 ]

6 голосов
/ 10 марта 2011

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

Если он говорит с кодом на стороне сервера, убедитесь, что он проверен как любой другой внешний ввод.

Вы также должны убедиться, что он не может быть предварительно заполнен чем-то вроде параметра GET и т. Д.

Обновление

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

Например, ваши уравнения могут иметь заполнители 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. Конечно, вы никогда не допустите, чтобы имена заполнителей были произвольными - сделайте их такими, какими они должны быть.
3 голосов
/ 10 марта 2011

Я не хочу быть мелодраматичным, но это, вероятно, один из худших случаев использования eval(), так как вы будете выполнять произвольный, предоставленный пользователем JavaScript.Это позволило бы пользователю выполнить код в вашем домене, что сделало бы атаку XSS слишком простой.

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

1 голос
/ 10 марта 2011

С точки зрения безопасности это нормально, так как пользователь может сломать только свой собственный браузер ... в этом нет ничего нового.

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

При этом вы не делаете коммерческий продукт, и это звучитКак это сэкономит вам много усилий, поэтому я бы просто пойти на это.

...