XSS Protection - безопасно ли кому-то создавать эксплойт, который видят только они?

Question

Короче говоря, у меня есть веб-приложение, которое помимо прочего позволяет пользователям (которым необходимо войти в систему) создавать, развертывать и получать представления из онлайн-форм, используя JSON инфраструктуру для хранения данных.

В тот момент, когда пользователь сохраняет свою вновь созданную форму, выполняются различные проверки, чтобы предотвратить внедрение SQL и выявить потенциальные эксплойты XSS.

Однако при создании фактической формы любой код, введенный в поля, отображается в реальном времени в браузере пользователя. Таким образом, если бы я решил ввести следующее в поле абзаца:

<a href="#" onclick="alert(1);">click me</a>

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

Итак, мой вопрос заключается в том, какой риск существует, позволяя пользователям динамически создавать контент в режиме реального времени, включая JS, при условии, что они не могут развернуть его или сохранить в моей БД? Я чувствую, что, вероятно, существует риск, но я не эксперт по XSS.

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

Answer 1

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

Что сразу приходит на ум, так это то, что если злоумышленник отправит законному пользователю фрагмент текста для копирования-вставки в поле. Возможно, будет нелегко обнаружить код в большом фрагменте текста, и таким образом злоумышленник может использовать его против ничего не подозревающего пользователя. Кроме того, хотя я думаю, что гораздо менее вероятно, ограниченный контроль над клиентским компьютером может помочь использовать это. Таким образом, существуют векторы атаки, которые могут быть возможны - или нет, это зависит от вашего приложения, от того, кто его использует и как.

В профессиональных тестах на проникновение этот обычно считается действительным XSS.

Кроме того, обратите внимание, что проверки «для предотвращения SQL инъекции и обнаружения потенциальных XSS-эксплойтов» на стороне ввода, вероятно, недостаточно эффективны, особенно для такого сложного пользовательского ввода. Чтобы предотвратить внедрение SQL, вам нужно каким-то образом параметризовать запросы, а для предотвращения XSS вам нужна выходная кодировка или, если требуется HTML, то проверенное решение для очистки (например, Google Caja, но есть и другие).

В вашем случае использования Javascript html дезинфицирующее средство (например, HTML Очиститель или чистая Javascript часть Caja) может помочь предотвратить XSS. Это должно быть интегрировано с вашим кодом пользовательского интерфейса, чтобы все, что вводится в поле ввода, было должным образом очищено перед добавлением в DOM. Обратите внимание, что это необходимо только в том случае, если требуется отображение предоставленного пользователем ввода HTML. В противном случае вы можете просто вывести кодирование любого введенного пользователем (или просто назначить его DOM в качестве текстового узла).