Атаки на веб-приложения · Словарь ИБ

XSS (межсайтовый скриптинг): что это и как защититься

Проверено экспертной редакцией SecRadar · по первоисточникам ФСТЭК / ФСБ / Банка России

XSS (Cross-Site Scripting, межсайтовый скриптинг) — атака, при которой злоумышленник внедряет вредоносный скрипт в веб-страницу, и этот скрипт исполняется в браузере жертвы, а не на сервере. Атака входит в категорию Injection рейтинга OWASP Top 10, делится на три типа — отражённый, хранимый и DOM-based, — и закрывается не одним продуктом, а комбинацией практик безопасной разработки и сетевой защиты.

Экспертная редакция SecRadar · как мы проверяем факты → Обновлено 14 июля 2026 · ~10 мин чтения ✓ сверено по OWASP, CWE и общепринятой терминологии ИБ

Кратко

XSS: Внедрение вредоносного скрипта в веб-страницу, которое исполняется в браузере жертвы, а не на сервере приложения.
Три типа: Отражённый (reflected) — через ссылку с полезной нагрузкой; хранимый (stored) — скрипт сохранён на сервере; DOM-based — уязвимость целиком в клиентском коде.
Последствия: Кража сессионных cookie и токенов авторизации, действия от имени жертвы, подмена содержимого страницы.
Категория OWASP: Injection — A05 в действующей редакции OWASP Top 10:2025 (была A03:2021-Injection).
Основная защита: Экранирование вывода и Content Security Policy на уровне приложения; валидация ввода и WAF — дополнительные, не основные рубежи.
Отличие от CSRF: XSS выполняет код в браузере жертвы, CSRF лишь подделывает запрос от её имени вслепую — без доступа к содержимому ответа.

Что такое XSS

XSS (Cross-Site Scripting, межсайтовый скриптинг) — это атака на веб-приложение, при которой злоумышленник внедряет вредоносный JavaScript-код в страницу, и этот код выполняется в браузере другого пользователя, а не на сервере. Название «межсайтовый» исторически описывает сценарий, когда скрипт с одного источника получает доступ к содержимому и данным другого сайта в браузере жертвы, хотя на практике атака чаще происходит в рамках одного и того же уязвимого сайта.

Причина та же, что у большинства инъекционных атак, — недостаточная проверка и обработка пользовательского ввода: приложение выводит непроверенные данные (введённые пользователем или взятые из параметра URL) обратно в HTML-страницу, и браузер жертвы интерпретирует их не как обычный текст, а как исполняемый код. Атака возможна везде, где страница отображает данные, которые прошли через пользователя, — поле поиска, комментарий, параметр ссылки, HTTP-заголовок Referer.

факт определение XSS и причина уязвимости — CWE-79, OWASP, общепринятая терминология ИБ

Типы XSS

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

↔ таблицу можно прокрутить вбок

Тип	Откуда берётся код	Требует ли действия жертвы
Отражённый (reflected)	Передаётся в самом запросе — обычно в параметре ссылки — и сервер немедленно «отражает» его обратно в HTML-ответе без проверки	Да — переход по специально составленной ссылке, часто из фишингового письма или сообщения
Хранимый (stored, persistent)	Сохраняется на сервере — в комментарии, профиле пользователя, отзыве, поле формы — и отдаётся всем, кто откроет страницу с этим содержимым	Нет — достаточно открыть обычную страницу сайта, специальная ссылка не нужна
DOM-based	Уязвимость целиком в клиентском JavaScript-коде страницы: скрипт в браузере сам берёт непроверенные данные (например, из URL) и вставляет их в DOM, минуя сервер	Да — обычно переход по ссылке, но сервер при этом может быть полностью корректен

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

факт классификация XSS на reflected/stored/DOM-based — CWE-79, OWASP, общепринятая терминология ИБ факт хранимый XSS как наиболее опасный тип — owasp.org/www-community/attacks/xss/

Последствия и пример атаки

Главное следствие успешной XSS-атаки — код атакующего получает те же права в браузере жертвы, что и легитимный скрипт страницы: доступ к содержимому DOM, к сессионным cookie (если они не защищены флагом HttpOnly), к данным, которые пользователь вводит в формы, и к самому интерфейсу страницы.

Учебный пример хранимого XSS — поле комментария, которое сайт выводит на страницу без экранирования HTML. Атакующий вместо обычного текста комментария отправляет:

Если приложение сохраняет этот текст как есть и выводит его на странице каждому посетителю, браузер каждого, кто откроет страницу с комментарием, выполнит этот код — и отправит cookie текущей сессии на сервер атакующего. Обладая сессионным cookie, атакующий может зайти на сайт под учётной записью жертвы без пароля.

Что именно крадут. Чаще всего цель — сессионные cookie и токены авторизации (кража сессии), но возможны и другие сценарии: перехват данных форм в реальном времени, подмена содержимого страницы (дефейс или фишинговая форма поверх настоящей), скрытая переадресация на вредоносный сайт, выполнение действий от имени жертвы без её ведома — например, смена email или перевод средств, если интерфейс это позволяет.

факт последствия успешной XSS-атаки и роль сессионных cookie — CWE-79, OWASP Cheat Sheet Series оценка пример с комментарием и кражей cookie — учебная иллюстрация механики, не воспроизведение конкретного инцидента

Как защититься

Основная защита от XSS находится в коде приложения, а не в отдельном защитном продукте — это корректное экранирование вывода и Content Security Policy. Средства статического и динамического анализа кода помогают найти уязвимость до релиза, а сетевая защита снижает риск для уже опубликованного приложения, но не заменяет исправление в самом коде.

Основа

Экранирование вывода

Символы, которые браузер интерпретирует как разметку или код (<, >, кавычки), заменяются на безопасные HTML-сущности при каждом выводе непроверенных данных на страницу — независимо от того, откуда эти данные пришли.

Барьер второго уровня

Content Security Policy

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

До релиза

Валидация ввода

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

Дополнительно

WAF

Web Application Firewall фильтрует известные паттерны XSS на уровне HTTP-трафика — полезный дополнительный рубеж, в том числе на время исправления уже найденной уязвимости, но не замена защиты внутри кода.

На портале класс WAF — основная техническая защита веб-приложений на сетевом уровне, включая фильтрацию XSS-паттернов в трафике. Найти уязвимость до того, как она попадёт в продакшн, помогают классы SAST — статический анализ исходного кода на предмет мест, где вывод не экранирован, — и DAST — динамический анализ уже работающего приложения, который пытается внедрить полезную нагрузку так же, как это сделал бы реальный атакующий.

факт роль экранирования вывода и CSP как основной защиты от XSS — OWASP Cheat Sheet Series (XSS Prevention, Content Security Policy) оценка место WAF, SAST и DAST в общей схеме защиты — редакционная систематизация, не заменяет продуктовую консультацию

Частые вопросы

Что такое XSS простыми словами?

XSS — это когда злоумышленник подсовывает сайту вредоносный кусок JavaScript-кода так, что сайт сам показывает его другим посетителям как часть страницы. Браузер жертвы не отличает этот код от обычного содержимого сайта и выполняет его — в результате атакующий может украсть сессию пользователя, его пароли или совершить действия от его имени. Метка: факт — общепринятое определение термина (CWE-79).

Чем XSS отличается от CSRF?

XSS выполняет собственный код в браузере жертвы и получает полный доступ к содержимому страницы, куки и вводимым данным. CSRF не внедряет код — он заставляет браузер жертвы отправить запрос от её имени на сайт, где она уже авторизована, но не даёт атакующему прочитать ответ. XSS — это выполнение кода, CSRF — подделка запроса вслепую. Подробный разбор — на странице CSRF. Метка: факт — сопоставление по CWE-79 и CWE-352.

Чем XSS отличается от SQL-инъекции?

Обе атаки используют недостаточную проверку пользовательского ввода, но целятся в разные места. SQL-инъекция атакует базу данных на сервере — злоумышленник получает доступ к чужим данным через сервер приложения. XSS атакует браузер другого пользователя: вредоносный код выполняется в его сессии и крадёт куки, токены или данные прямо на клиенте, не трогая сервер напрямую. Подробнее — SQL-инъекция и XSS. Метка: факт — сопоставление по CWE-89 и CWE-79.

Что такое хранимый XSS?

Хранимый (stored) XSS — тип атаки, при котором вредоносный скрипт сохраняется на сервере: в комментарии, профиле пользователя, отзыве или другом поле, которое отображается другим посетителям. Скрипт выполняется в браузере каждого, кто откроет страницу с этим содержимым, — без перехода по специальной ссылке, в отличие от отражённого XSS. Метка: факт — CWE-79, классификация OWASP.

Может ли CSP полностью защитить от XSS?

Нет, но корректно настроенная Content Security Policy резко снижает ущерб от XSS даже там, где уязвимость всё же есть — она запрещает браузеру выполнять инлайн-скрипты и код с недоверенных источников. CSP работает как дополнительный барьер, а не замена основной защиты — экранирования вывода при формировании HTML-страницы. Метка: факт — OWASP Cheat Sheet Series (Content Security Policy).

В какую категорию OWASP Top 10 входит XSS?

XSS входит в категорию Injection — в действующей редакции OWASP Top 10:2025 она обозначена как A05 (в редакции 2021 года была A03:2021-Injection). Категория объединяет атаки, где непроверенный пользовательский ввод выполняется как код: SQL-, NoSQL-, command-инъекции и межсайтовый скриптинг, который в более ранних редакциях OWASP Top 10 (2013, 2017) выделялся отдельной категорией. Полный разбор всех категорий — на странице OWASP Top 10. Метка: факт — owasp.org, официальный документ OWASP Top 10.

Словарь терминов ИБ на SecRadar

XSS и другие атаки на веб-приложения — независимые разборы без привязки к вендору, с прямыми ссылками на классы СЗИ, которые закрывают конкретную угрозу.

Открыть словарь →