Knowledge Base

Reflected XSS: безопасная проверка экранирования вывода

Категория: Web App Security · Риск: high

Reflected XSS: безопасная проверка экранирования вывода

Что проверяет NodeRoute

Расширенный режим отправляет несколько `GET`-запросов с уникальной неисполняемой меткой в распространённых поисковых параметрах. Метка содержит HTML-значимые символы, но не содержит JavaScript, обработчиков событий или другого исполняемого кода.

Проверка доступна только после подтверждения управления доменом через DNS. Она отвечает на узкий вопрос: возвращается ли введённое значение в HTML и экранирует ли приложение специальные символы.

Почему это важно

Если приложение вставляет пользовательский ввод в HTML без контекстного экранирования, злоумышленник может попытаться сформировать ссылку, выполняющую код в браузере посетителя. Возможные последствия:

кража доступной JavaScript сессии;
подмена элементов страницы;
фишинг от имени сайта;
выполнение действий в контексте вошедшего пользователя.

Как читать результат

`Ввод не отражается` означает только то, что проверенные параметры главной страницы не вернули метку. Это не доказывает отсутствие XSS на других страницах.

`Ввод отражается, но экранируется` означает, что HTML-значимые символы были преобразованы или удалены на проверенной поверхности.

`Ввод отражён без экранирования` является признаком HTML injection и требует ручного подтверждения контекста. NodeRoute не запускает JavaScript и не пытается эксплуатировать находку, поэтому отчёт не должен утверждать факт компрометации.

Безопасные границы проверки

только подтверждённый владельцем домен;
только короткие `GET`-запросы;
неисполняемая случайная метка;
ограниченный список параметров;
короткие timeout;
без сохранения данных и изменения состояния;
без обхода WAF, авторизации или CSP;
без проверки форм входа и приватных страниц.

Как исправить

Используйте экранирование, соответствующее месту вставки данных:

HTML-текст: HTML entity encoding;
значение атрибута: attribute encoding и кавычки вокруг значения;
URL: безопасное построение URL и проверка схемы;
JavaScript: не вставляйте пользовательские строки в исполняемый код;
DOM: применяйте `textContent`, а не `innerHTML`, если разметка не нужна.

Современный шаблонизатор с включённым auto-escaping должен оставаться основным барьером. CSP полезна как дополнительная защита, но не заменяет корректное экранирование.

Проверка после исправления

1. Повторите enhanced-скан подтверждённого домена. 2. Убедитесь, что результат изменился на `ввод отражается, но экранируется` или `отражение не обнаружено`. 3. Проверьте конкретный шаблон и контекст вручную в тестовой среде. 4. Добавьте регрессионный тест на исходный параметр. 5. Убедитесь, что cookie сессии имеют `HttpOnly`, `Secure` и подходящий `SameSite`.

Частые ошибки

считать наличие CSP доказательством отсутствия XSS;
экранировать только `<` и `>`, забывая о кавычках и контексте;
отключать auto-escaping для удобства;
объявлять XSS подтверждённой только по отражению текста;
запускать исполняемые payloads на production-сайте.

Не делать

Не применяйте эту проверку к чужим системам без письменного разрешения. Не используйте исполняемые payloads, кражу cookie, обход авторизации или попытки закрепления. Подтверждение уязвимости с воздействием выполняется только владельцем в отдельной тестовой среде.

Связанные статьи

[Content-Security-Policy](/kb/http/content-security-policy)
[Cookie Secure / HttpOnly / SameSite](/kb/web_app_security/cookie-security)
[Правила авторизованного security testing](/kb/compliance_legal/authorized-testing-rules)
[Safe Active Diagnostics](/kb/monitoring/safe-active-diagnostics)