Безопасность с использованием AJAX и установка innerHTML?

Question

Рассмотрим следующие обстоятельства:

• Я посылаю запрос AJAX (без пользовательского ввода) в PHP, который запускает функцию.
• Функция возвращает строку необработанного HTML. Может быть что угодно - список ссылок, куча пустых divs, SVG для вставки встроенного текста, большая часть страницы ... В его создании не используются пользовательские входные данные.
• Я получаю строку в качестве ответа и вставляю ее в div .
• Я (в настоящее время и в идеале хотел бы продолжить), используя чистый JS - нет библиотек.

Принимая во внимание, что в JS существует определенный уровень неуверенности, насколько неуверенным является то, что я только что сделал?

OWASP XSS Cheat Sheet говорит, чтобы избежать всех «ненадежных данных». Является ли результат моего запроса AJAX ненадежным с учетом вышеуказанных обстоятельств? Является ли результатом какого-либо запроса AJAX как «ненадежного»?

Является ли вставка HTML таким образом плохой практикой? Если да, то что я должен делать вместо этого?

Редактировать прояснить несколько вещей:

• URL переменные в запросе AJAX только используется для запуска функции PHP на сервере. Никакие переменные не передаются этой функции вообще (в частности, я использую компонент com_ajax Joomla).
• Все возвращенного кода статизирован и написан мной.

Answer 1

Пока реакция действительно статическая и не включает в себя ввод данных пользователя любого рода, это прекрасно. Сам AJAX (как вы намекали) не делает его уязвимым для XSS (пока транспорт безопасен, что практически означает https).

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

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

Лучшей практикой является кодирование всего по умолчанию, чтобы избежать ошибок. Если вы уверены, что доверяете источнику данных, которые хотите вставить в DOM как HTML, все в порядке. Моделирование угроз может помочь обнаружить, что вам нужно и не следует доверять, но в некоторых случаях это также может быть очевидным.