XSS

JuniorMiddleSeniorФундамент ~40 мин

Границы темы

Scope: выполнение attacker-controlled JavaScript или активного HTML в origin приложения из-за небезопасного потока данных.

Не рассматриваем: каталог payload, browser exploits и WAF rules. Защита строится на корректном использовании parser context и безопасных API, а не на denylist строк.

Результаты обучения

После статьи читатель сможет:

1. построить цепочку source → transform → sink;
2. определить parser context в точке вставки;
3. выбрать output encoding, sanitization или safe sink;
4. объяснить, почему CSP и HttpOnly уменьшают риск, но не устраняют XSS;
5. проверить исправление безопасным учебным тестом.

Основная модель

XSS возникает, когда недоверенные данные из Место поступления данных, которым система не должна автоматически доверять. достигают

Место, где данные интерпретируются: DOM API, SQL executor, shell, template engine или другой потребитель., где браузер трактует их как HTML, JavaScript, URL или

CSS с исполняемой семантикой. Основной вопрос не «есть ли в строке <script>», а «какой parser прочитает данные и в каком context».

Диаграмма

Основные термины

Термин	Смысл	Пример
Source	Откуда приходят недоверенные данные	URL, postMessage, API, DB
Transform	Как данные меняются	decode, concatenate, template render
Sink	API/позиция, интерпретирующая данные	innerHTML, attribute, script
Context	Parser и грамматика в месте вставки	HTML, attribute, URL, JS, CSS
Encoding	Представление символов как данных конкретного context	HTML entities
Sanitization	Удаление/нормализация опасной разметки при разрешённом HTML	HTML sanitizer

End-to-end сценарий

Stored XSS

Диаграмма

Reflected и DOM-based

Тип	Где возникает опасная вставка	Данные сохраняются
Stored	Server output или client render данных из storage	Обычно да
Reflected	Server отражает request data в response	Нет
DOM-based	Client JavaScript переносит source в sink	Не обязательно

Классификация помогает искать поток, но защита всё равно определяется конечным context и sink.

Что происходит под капотом

HTML-документ обрабатывают несколько грамматик. Строка, безопасная как HTML text, не обязательно безопасна внутри JavaScript string или URL.

HTML document
├── text node              → HTML text context
├── attribute="..."        → HTML attribute context
├── href="..."             → URL + attribute context
├── <script>...</script>   → JavaScript context
└── style="..."            → CSS + attribute context

Context	Предпочтительный подход	Опасный пример
HTML text	Framework auto-escape или textContent	innerHTML
Quoted attribute	Auto-escape + allowlist имени attribute	Event handler attribute
URL	Разбор URL, allowlist scheme, затем attribute encoding	javascript:
JavaScript	Не вставлять данные в executable code	String concatenation в script
CSS	Не вставлять недоверенные данные; строгая allowlist	Dynamic style expression
Rich HTML	Проверенный HTML sanitizer	Самодельный regex

Encoding применяется на output под конкретный context. Раннее «экранирование при вводе» портит данные и не знает будущего context; validation решает допустимость данных, но не заменяет output encoding.

Минимальный воспроизводимый пример

Уязвимый вариант

<label for="search">Поиск</label>
<input id="search" />
<div id="result"></div>

<script>
  const query = new URLSearchParams(location.search).get("q") ?? "";
  document.querySelector("#result").innerHTML = `Результат: ${query}`;
</script>

Недоверенный q попадает в HTML sink. Не проверяйте пример на чужом сайте и не используйте payload, выполняющий внешние действия.

Исправленный вариант для обычного текста

<script>
  const query = new URLSearchParams(location.search).get("q") ?? "";
  const result = document.querySelector("#result");
  result.textContent = `Результат: ${query}`;
</script>

textContent создаёт text node: браузер не передаёт строку HTML parser.

Если действительно нужен rich HTML

// Конкретную библиотеку и её конфигурацию нужно ревьюить и регулярно обновлять.
const cleanHtml = sanitizer.sanitize(untrustedHtml);
container.innerHTML = cleanHtml;

Разбор и очистка разрешённой разметки с удалением опасных элементов, атрибутов и URL. нужна только когда бизнес-требование

разрешает ограниченный HTML. Для обычного текста

API вывода, который трактует недоверенное значение как данные, а не как исполняемый код или разметку. проще и надёжнее.

Как проверить защиту

1. Проследить все sources до sinks статическим анализом и code review.
2. Проверить, что текст с <, >, ", ' отображается как текст.
3. Проверить URL schemes и event handler attributes.
4. Добавить regression test на конкретный найденный flow.
5. Включить CSP report-only, собрать нарушения и затем ужесточить policy.

Проверка одной строкой не доказывает отсутствие XSS: важны все context и повторные decode/transform этапы.

Ограничения и trade-offs

• Auto-escaping framework защищает стандартные template bindings, но escape hatches (v-html, dangerouslySetInnerHTML) возвращают ответственность разработчику.
• Sanitization сохраняет часть HTML, но требует зрелого parser-based sanitizer и обновлений.
• CSP ограничивает источники и выполнение script, но сложна в настройке и является defense in depth.
• Trusted Types может перекрыть классы DOM sinks, но требует миграции и поддержки конкретных браузеров.
• HttpOnly не даёт JavaScript прочитать cookie, но XSS всё ещё может выполнять authenticated requests из origin пользователя.

Failure modes и типичные ошибки

Ошибка	Почему не работает	Исправление
Удалять слово script	Много parser contexts и обходов	Safe sinks/context encoding
Один encoder для всего	Context имеют разные грамматики	Encoding в точке output
Sanitization через regex	HTML не является регулярным языком для такого разбора	Parser-based sanitizer
Полагаться только на CSP	Policy может быть слабой или обходиться существующим кодом	Исправить source-to-sink flow
Полагаться на WAF	DOM flow может не проходить через server	Исправить application code
Считать HttpOnly защитой от XSS	Уменьшает часть impact, не останавливает execution	Устранить unsafe sink

Безопасность и производительность

Централизованные safe UI primitives уменьшают число решений на каждом call site. Sanitization дорогая относительно textContent, поэтому не следует разрешать rich HTML без требования. При кешировании sanitized output важно инвалидировать его после обновления sanitizer или policy.

Практическое задание

Создайте локальную страницу с тремя sources: query string, API response и postMessage. Добавьте безопасный text output и отдельный rich-text output через sanitizer.

Критерии готовности:

• для каждого source задокументирован конечный sink;
• обычный текст нигде не проходит через HTML parser;
• rich HTML очищается в одном централизованном месте;
• URL принимает только https: и ожидаемые relative paths;
• есть regression tests и CSP report-only.

Подсказка

Составьте таблицу source → transforms → sink → context → control. Начинайте с замены unsafe sink, а не с фильтрации входной строки.

Проверка знаний

ИНТЕРАКТИВНАЯ ПРОВЕРКА

XSS: data flow и контексты

0 / 3

01Восстановите модель прохождения недоверенных данных.

1. Sink интерпретирует данные
2. Данные поступают из source
3. Возникает выполнение или другой impact
4. Данные проходят transforms

02Как безопаснее вывести обычный недоверенный текст в DOM?

Присвоить textContentПрисвоить innerHTML после удаления слова scriptИспользовать innerHTML, полагаясь только на CSP

03Какие меры относятся к defense in depth, но не заменяют безопасный sink?

Content Security PolicyHttpOnly cookieTrusted TypesRegex, удаляющий слово script

Проверено: 0 из 3

Самопроверка

1. Почему HTML encoding нельзя бездумно применять внутри JavaScript context?
2. Чем validation отличается от output encoding?
3. Когда нужен sanitizer вместо textContent?
4. Почему CSP не является основной защитой?
5. Как HttpOnly меняет impact успешной XSS?

Ответы и критерии

1. JavaScript parser использует другую грамматику; HTML-safe строка может оставаться опасной для JS.
2. Validation решает, допустимы ли данные; encoding безопасно представляет допустимые данные в конкретном output context.
3. Только когда продукт действительно разрешает ограниченный rich HTML.
4. Она не исправляет небезопасный data flow, зависит от корректности policy и служит дополнительным барьером.
5. Запрещает прямое чтение cookie через JS, но не мешает выполнять действия от имени пользователя или читать доступные DOM/API-данные.

Краткое резюме

Устойчивая модель XSS — это не blacklist payload, а цепочка source → transforms → sink → parser context. Предпочитайте safe sinks, применяйте context-aware encoding, используйте sanitizer только для разрешённого HTML, а CSP, Trusted Types и cookie attributes — как дополнительные слои.

Следующие шаги

• Same-Origin Policy и browser security model;
• CSP и Trusted Types;
• cookies, sessions и CSRF;
• template injection;
• secure code review и static analysis.

Источники

• OWASP Cross-Site Scripting Prevention Cheat Sheet — context-aware output encoding, safe sinks, sanitization и anti-patterns.
• OWASP DOM based XSS Prevention Cheat Sheet — DOM sources/sinks и client-side contexts.
• OWASP Content Security Policy Cheat Sheet — CSP как defense in depth и варианты deployment.
• HTML Living Standard: Dynamic markup insertion — поведение browser APIs, создающих и разбирающих markup.