Javascript Eval (и друзья) - PullRequest
Новая
       27

Javascript Eval (и друзья)

8 голосов
/ 13 февраля 2012

Некоторые утверждают, что eval - это зло.

Любая обычная HTML-страница может выглядеть следующим образом: 

        <script src="some-trendy-js-library.js"></script>
    </body>
</html>

То есть, если человек, который делает это, знает свою работу и оставляет JavaScript для загрузки наконец страницы.

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

<script src="//foo.com/bar.js"></script>

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

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

Теперь, когда я ясно изложил свою точку зренияздесь возникает вопрос ...

При определенных условиях, таких как запрос AJAX или (что более интересно) соединение через веб-сокет, каков наилучший способ выполнить ответ отсервер?

Вот пара, чтобы вы подумали ...

  • eval() вывод сервера.(этот парень просто упал в обморок?)
  • запустил именованную функцию, возвращаемую сервером: var resp = sock.msg; myObj[resp]();
  • создайте мой собственный парсер, чтобы выяснить, что сервер пытается сказать мне безвозиться с javascript напрямую.

Ответы [ 5 ]

5 голосов
/ 13 февраля 2012

При определенных условиях, таких как запрос AJAX или (что более интересно) соединение через веб-сокет, каков наилучший способ выполнить ответ от сервера?

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

Давайте разберем виды ответов на несколько разных категорий:

  1. Статический javascript, загружаемый по требованию
  2. Динамический ответ из надежного источника в защищенном канале, который не содержит никакого указанного содержимогоненадежными сторонами.
  3. Динамический ответ от смешанных источников (может быть, в основном доверенный, но включает закодированные строки, указанные ненадежными сторонами), который в основном представляет собой данные
  4. Побочные эффекты на основе данных

Для (1) нет разницы между XHR + eval и <script src>, но XHR + eval имеет несколько преимуществ.

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

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

Для (4) было бы лучше, если бы вы могли разделить его на проблему с данными и код.JSONP позволяет это, если вы можете проверить результат перед выполнением.Разберите данные, используя JSON.parse или что-то еще с небольшим злоупотреблением полномочиями, поэтому функция, которую вы написали и одобрили для внешнего использования, дает побочные эффекты.Это сводит к минимуму чрезмерное злоупотребление властью.Наивный eval здесь опасен.

5 голосов
/ 13 февраля 2012

«Зло» не означает «запрещено» .Иногда есть совершенно веские причины использовать так называемые «злые» функции.Их просто называют «злыми», так как они могут быть и часто используются неправильно.

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

4 голосов
/ 13 февраля 2012

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

Если вы контролируете домен, то делайте что хотите.

2 голосов
/ 13 февраля 2012

Пусть ваш сервер вернет JSON и интерпретирует этот JSON на клиенте.Клиент выяснит, что делать с JSON, так же, как сервер выяснит, что делать с запросами, полученными клиентом.

Если ваш сервер начинает возвращать исполняемый код, у вас возникла проблема.НЕ потому, что произойдет что-то «плохое» (хотя это может произойти), а потому, что ваш сервер не несет ответственности за то, что клиент знает или не должен делать .

Это похоже наотправил код на сервер и ожидал, что сервер его выполнит.Если у вас нет ДЕЙСТВИТЕЛЬНО веской причины (такой как IDE в браузере), это плохая идея.

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

Редактировать:

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

2 голосов
/ 13 февраля 2012

Сервер должен предоставлять вам данные, а не код.Вы должны заставить сервер отвечать данными JSON, чтобы ваш код JS мог действовать соответствующим образом.Если сервер отправляет имена функций для вызова с помощью myObj[resp]();, он все еще тесно связывает логику сервера с логикой клиента.

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

...