Как стать автором
Обновить

Комментарии 10

Каковы основные источники XSS? Браузеры. То есть их уязвимости и плагины, которые туда устанавливаются. Со стороны приложения же фильтрация специфических для html символов в основном устраняет проблему. То есть проблема не в приложениях, а в браузерах, ну и в любви к бесконтрольной установке расширений, содержащих всякую заразу. Но поскольку с точки зрения пользователя он взаимодействует с приложением, то и вину за всё он возлагает на приложение. И то же самое следом начинают считать разработчики:
Опыт показывает, что разработка веб-приложения устойчивого к XSS-атаке, по-прежнему является нетривиальной задачей

То есть разработчики вычищают проблемы браузера. Не впервой, понятно, но всё же стоит называть вещи своими именами — веб-разработка вынуждена воевать с чужими проблемами, просто потому, что веб неподконтролен веб-разработчикам. Правильно определить проблему = получить предпосылки для её эффективного решения.

В частности я бы рекомендовал не увлекаться созданием страниц на одном JS. JS доверяет браузеру гораздо больше, чем возможно. Сервер вам поможет (если вы об этом не знали).

Ну нет, основной источник XSS — это подготовка HTML-разметки через операции над строками. Если вы собираете страницу или её часть конкатенацией строк — у вас, вполне вероятно, есть XSS-уязвимость, независимо от того на сервере или в браузере вы это делаете.


В данном случае, именно браузеры пытаются вычистить проблемы разработчиков. Точнее, предлагают разработчикам новое API, потому что старое API уязвимо по построению.

То есть всё дело во вражеских строках? А «подготавливающий», разумеется, ни при чём.

Вы вычитали в моём комментарии то, чего там не было.

Не надо так передёргивать. Потому что я могу сказать по другому — вы написали такое, что невозможно понять (по другому).

Хотя за вами замечена особенность — коротко и самоуверенно заявлять, а потом ничего не объяснять (как и в этот раз).

А строки здесь как раз были, вот ваше:
Если вы собираете страницу или её часть конкатенацией строк — у вас, вполне вероятно, есть XSS-уязвимость

Ну да, я именно это и заявил. Разумеется, в этом виноват именно тот, кто готовит таким образом разметку ("подготавливающий"), а никак не строки.

Я написал выше, что проблема (в основном) устраняется фильтрацией ряда символов. А вот проблема уязвимости браузера так легко не устраняется. Если браузер разрешает качать скрипты с чужого домена, значит кто-то этим воспользуется. Ну а писатели на JS вообще могут сослаться на JS-библиотеку где-нибудь в сети, мол «всё равно я её оттуда скачал», и тут эту библиотеку кто-то меняет…

Зависимости в сложном JS приложении, которое полностью обязано исполняться в браузере, всегда отследить сложнее, чем на сервере.

Ну так предложенное решение в итоге к этой фильтрации и сводится. Точнее, к экранированию.


А ограничение на скрипты с чужого домена ничего принципиально не изменит: непосредственная-то угроза заключается в inline-скрипте. Кстати, возможность отключить эти inline-скрипты появилась уже давно.

А вы с чем спорите?

Дать волю чужим скриптам можно если не экранировать вводимые пользователем данные. Ну или если довериться браузеру и разработчикам на JS. По какому из этих двух пунктов возражение?
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре , чтобы оставить комментарий