Comments 7
Есть отличная статья про проблемы парсеров (BB-коды, маркдаун) которые приводят к XSS от Positive Technologies https://swarm.ptsecurity.com/fuzzing-for-xss-via-nested-parsers-condition/
Ну, кроме expression в IE, других подобных (и эксплуатируемых) XSS с помощью CSS я не припомню. Может кто-то знает?)
А cure53 имплементировали DOMPurify в браузеры https://wicg.github.io/sanitizer-api/#dom-element-sethtml
Да, тоже кроме описанного в статье случая не нашел подобного в CSS. К счастью не потащили эту "фичу" дальше.
Ага, Sanitizer API можно использовать официально со вчерашнего дня, пока, правда только в Хроме: https://caniuse.com/mdn-api_sanitizer. Не знал, что он на основе DOMPurify, спасибо за открытие!
Как вариант, можно любой текст не образуюший конструкции из белого списка подвергать замене всех спецсимволов < > = " ' ` / на html сущности. А не оставлять по принципу "раз не распарсилось в полный тег, значит не надо трогать".
В таком случае мы, получается, идем вразрез с логикой браузера, если она реализует спецификации HTML касательно работы с тегами. Мы вправе только убрать потенциально опасные атрибуты, если говорить именно про санитайзеры. А если разговор про частное решение для конкретного приложения, то да, можем наворотить свою логику.
А есть официальная статистика сколько уязвимостей находится именно через XSS ?
У OWASP есть проект Top Ten, в нем на данный момент XSS на третьем месте, правда вместе с инъекциями.
XSS с мутациями: как безопасный код становится зловредным и при чем здесь innerHTML