Комментарии 10
Опыт показывает, что разработка веб-приложения устойчивого к XSS-атаке, по-прежнему является нетривиальной задачей
То есть разработчики вычищают проблемы браузера. Не впервой, понятно, но всё же стоит называть вещи своими именами — веб-разработка вынуждена воевать с чужими проблемами, просто потому, что веб неподконтролен веб-разработчикам. Правильно определить проблему = получить предпосылки для её эффективного решения.
В частности я бы рекомендовал не увлекаться созданием страниц на одном JS. JS доверяет браузеру гораздо больше, чем возможно. Сервер вам поможет (если вы об этом не знали).
Ну нет, основной источник XSS — это подготовка HTML-разметки через операции над строками. Если вы собираете страницу или её часть конкатенацией строк — у вас, вполне вероятно, есть XSS-уязвимость, независимо от того на сервере или в браузере вы это делаете.
В данном случае, именно браузеры пытаются вычистить проблемы разработчиков. Точнее, предлагают разработчикам новое API, потому что старое API уязвимо по построению.
Вы вычитали в моём комментарии то, чего там не было.
Хотя за вами замечена особенность — коротко и самоуверенно заявлять, а потом ничего не объяснять (как и в этот раз).
А строки здесь как раз были, вот ваше:
Если вы собираете страницу или её часть конкатенацией строк — у вас, вполне вероятно, есть XSS-уязвимость
Ну да, я именно это и заявил. Разумеется, в этом виноват именно тот, кто готовит таким образом разметку ("подготавливающий"), а никак не строки.
Зависимости в сложном JS приложении, которое полностью обязано исполняться в браузере, всегда отследить сложнее, чем на сервере.
Ну так предложенное решение в итоге к этой фильтрации и сводится. Точнее, к экранированию.
А ограничение на скрипты с чужого домена ничего принципиально не изменит: непосредственная-то угроза заключается в inline-скрипте. Кстати, возможность отключить эти inline-скрипты появилась уже давно.
Trusted Types — новый способ защиты кода веб-приложений от XSS-атак