Отражённый XSS.

Отражённый XSS (непостоянный, Type-1) возникает, когда веб-приложение принимает данные из HTTP-запроса — обычно из параметра URL или поля формы — и без должного кодирования вывода возвращает их в ответе. Атака требует, чтобы жертва перешла по подготовленной ссылке, поэтому распространяется через фишинг, вредоносную рекламу или мессенджеры. Успешная эксплуатация позволяет похитить сессионные cookie, совершить действия от имени пользователя или перерасти в полный захват учётной записи. Защита включает контекстно-зависимое HTML-кодирование, строгую Content Security Policy и фреймворки с автоматическим экранированием шаблонов.

Анатомия атаки отражённого XSS

flowchart LR
  A[Атакующий формирует ссылку со скриптом в параметре] --> B[Доставка через фишинг / рекламу / чат]
  B --> C[Жертва переходит по ссылке]
  C --> D[Приложение отражает ввод без кодирования]
  D --> E[Браузер исполняет скрипт в сессии жертвы]
  E --> F[Кража cookie / действия от имени пользователя / захват аккаунта]

Почему полезную нагрузку нужно кодировать под её контекст

Ключевая тонкость XSS в том, что «кодирование» зависит от контекста: одно и то же значение безопасно в одном месте и опасно в другом. Данные в HTML-тексте требуют кодирования HTML-сущностей; в атрибуте — кодирования атрибута и кавычек; в блоке <script> или обработчике событий — кодирования JavaScript-строки; в URL — URL-кодирования. Единственный проход кодирования, применённый вслепую, пропустит случаи, когда один и тот же параметр отражается сразу в нескольких контекстах. Шаблонизаторы, экранирующие по умолчанию (JSX в React, Angular или серверные шаблоны с контекстным экранированием), устраняют большинство отражённых XSS — при условии, что разработчики избегают лазеек вроде dangerouslySetInnerHTML или innerHTML.

Браузерные фильтры больше не являются защитой. Google удалила XSS Auditor в Chrome 78 (октябрь 2019 года), так как его было легко обойти, он давал ложные срабатывания и сам мог использоваться для избирательного отключения легитимных скриптов; поддерживаемый им заголовок X-XSS-Protection сегодня фактически неактуален. Надёжные меры — это контекстно-зависимое кодирование вывода, строгая Content Security Policy (желательно на основе nonce или hash), cookie с флагом HttpOnly, чтобы украденный скрипт не мог прочитать сессию, и валидация ввода как эшелонированная защита, а не главный барьер.