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

Question

Я понял, что JSON.parse () не позволяет злоумышленнику внедрить javascript в ответ, поскольку анализатор JSON - это просто анализатор текста, а не анализатор сценариев, поэтому не закрывайте это дублирование всех других вопросов, которыепоговорим об этом.Это другой вопрос.

Если злоумышленник может перехватить ваш Ajax-вызов и вставить Javascript в Ajax-вызов, разве он не может с такой же вероятностью взломать вашу реальную веб-страницу и вставить произвольный javascript на вашу страницу, с которой он может выполнить точныйта же атака?

Конечно, вам нечего терять, используя JSON.parse () вместо eval () (если у вас еще нет анализатора JSON в вашей среде и вам не нужно добавлять больше кода для получения1), но в каких ситуациях это действительно повышает безопасность, если ваша веб-страница обслуживается тем же хостом, что и ваш ajax-вызов?

Answer 1

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

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

Возможно, у кого-то, работающего на вашем сервере, плохой день, и он делает что-то глупоесоздание JSON путем конкатенации необработанного пользовательского ввода:

<?php
    print '{"foo": ' . $_GET['bar'] . '}';
?>

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

Answer 2

Что ж, если они могут вставить ваши AJAX-ответы, то они, вероятно, уже успешно вас так или иначе (ARP, DNS или что-то еще).

См. http://en.wikipedia.org/wiki/Man-in-the-middle_attack для получения более подробной информации об этих типах атак.

Вы правы в том, что, если они могут внедрить в ваш ответ AJAX, они могут также внедрить целые страницы,Действительно, все, что вы получаете ИЛИ отправляете по сети, теперь уязвимо в MitM, если не используется что-то вроде HTTPS \ SSL.

Answer 3

Это очень хороший момент.Единственное, о чем я могу подумать, это то, что JSON.parse будет иметь возможность быть быстрее, чем eval.

Гораздо менее вероятное преимущество заключается в том, что браузер уже имеет кешированный HTML / JavaScript и сервер использует Cache-Control сказать, что его не нужно перезагружать.Если это произойдет, то, конечно, перехватывающий человек не сможет изменить страницу.Но это очень редкий набор обстоятельств.Скорее всего, вам потребуется, чтобы браузер проверил наличие более новой версии HTML / JavaScript, которая является поведением по умолчанию.

Что касается разницы в безопасности, я думаю, что вы правы.

Что касается меня, я работаю только с системами, подтвержденными HTTPS.Но у меня есть функция, которая использует JSON.parse, если она доступна, и использует eval только для улучшения скорости.

Answer 4

Хорошо ... Я не защищаю использование eval, но я не думаю, что это представляет проблему безопасности в Javascript , потому что Javascript - это язык на стороне клиента. Если вы не используете eval в своем коде, что мешает мне запустить javascript:my_own_evil_code() в консоли или адресной строке? Это Javascript, я могу запускать свой собственный код или изменять ваш, создавать свои собственные HTTP-запросы и делать что-либо с HTTP-ответами или даже добавлять свой собственный eval к вашим функциям.

Вам не следует использовать eval, если доступно другое сопоставимое решение, но если вы просто для простоты хотите сделать eval('('+jsonstring+')') для эмуляции JSON.parse, я не думаю, что это большая ошибка.