Отражённый, хранимый и DOM-based XSS: в чём разница?

Справочная страница

Краткий ответ

Отражённый, хранимый и DOM-based XSS описывают разные пути от недоверенных данных к небезопасному контексту браузера. Они могут пересекаться: выясните источник значения, сохраняется ли оно, какой код его выводит и каких пользователей оно достигает.

Три типа

Отражённый XSS — значение находится в запросе

Значение запроса попадает в ответ без кодирования для нужного контекста, и браузер интерпретирует его как разметку или сценарий. Злоумышленник может отправить жертве подготовленную ссылку, но основная ошибка — небезопасный вывод данных запроса. Исправляйте обработку в точке вывода.

Хранимый XSS — значение сохраняется

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

DOM-based XSS — клиентский код передаёт данные в небезопасную точку DOM

Клиентский JavaScript читает недоверенный источник (например, location.hash, параметр URL или данные сервера) и передаёт его в небезопасную точку DOM, такую как innerHTML. Значение может не попасть на сервер, но это не обязательно: DOM-based XSS описывает клиентский путь source-to-sink и может сочетаться с отражённой или хранимой доставкой. Исправляйте поток данных на клиенте.

Почему различие важно для исправления

Исправляйте XSS в точке вывода: применяйте кодирование для конкретного контекста или безопасный DOM API. Отражённый и хранимый XSS часто связан с серверным выводом, но небезопасная точка может возникнуть и при клиентском рендеринге. Для DOM-based XSS используйте textContent вместо innerHTML для текста; если нужен HTML, используйте поддерживаемый санитайзер с явной политикой. Серверное кодирование не заменяет проверку клиентских потоков source-to-sink.

Эти категории могут пересекаться

Отражённый и хранимый XSS описывают, как ввод попадает на страницу и сохраняется ли он. DOM-based описывает клиентский путь от источника к точке вывода. Категории не взаимоисключающие: сохранённый текст профиля, который клиентский код вставляет в innerHTML, может одновременно быть хранимым и DOM-based XSS.

DOM-based XSS: небезопасная точка вывода и текстовый режим

НЕБЕЗОПАСНО — разбирать недоверенный текст как HTML

const value = new URLSearchParams(location.search).get("q") ?? "";
target.innerHTML = value;

БЕЗОПАСНЕЕ ДЛЯ ТЕКСТА — вывести как текст

const value = new URLSearchParams(location.search).get("q") ?? "";
target.textContent = value;

Источники

См. также XSS (межсайтовый скриптинг, CWE-79): как он работает и как его предотвратить в любом языке — flawopen.com Риски безопасности addJavascriptInterface в Android Защита Angular от XSS: безопасные значения и обходные API XSS из-за MIME sniffing: Content-Type и nosniff CSP и экранирование вывода: нужны ли оба? Безопасен ли dangerouslySetInnerHTML в React? Достаточно ли DOMPurify для безопасного innerHTML?