XSS-уязвимость
Обновлено: 16.06.2026
Это тип уязвимости веб-приложений, при которой злоумышленник внедряет вредоносный код в страницу сайта, сервера или базу данных, а браузер другого пользователя исполняет его как доверенный.
Главная опасность XSS в том, что атака направлена не на сервер напрямую, а на пользователей сайта. Браузер жертвы не знает, что скрипт вредоносный: он получает его от доверенного ресурса и исполняет.
XSS входит в список критичных уязвимостей по версии OWASP Top 10 и встречается как на небольших сайтах, так и в крупных веб-приложениях с миллионами пользователей.
Как расшифровывается XSS
XSS — это сокращение от Cross-Site Scripting, что дословно переводится как «межсайтовый скриптинг». Сокращение используется именно в виде XSS, а не CSS — чтобы не путать с CSS (Cascading Style Sheets), языком стилей веб-страниц.
Термин появился в конце 1990-х годов, когда исследователи безопасности начали описывать атаки, при которых скрипты одного сайта исполнялись в контексте другого. Со временем значение термина расширилось: сегодня под XSS понимают любое внедрение и выполнение вредоносного кода в веб-интерфейсе через незащищенный ввод или вывод данных.
Простое объяснение XSS на одном примере
Представьте интернет-магазин с разделом отзывов. Покупатели оставляют комментарии о товарах, и сайт отображает их на странице продукта.
Злоумышленник оставляет необычный текст, а сообщение со вставленным скриптом. Если сайт не проверяет и не обрабатывает пользовательский ввод перед выводом, вредоносный код сохраняется в базе данных и попадает на страницу.
Когда следующий покупатель открывает страницу товара, его браузер загружает страницу вместе со скриптом. Браузер не знает, что скрипт вредоносный: он получен от доверенного сайта магазина. Вредоносный скрипт исполняется и данные утекли злоумышленнику. Именно так работает базовая XSS-атака, через доверие браузера к содержимому страницы.
Как работает XSS-атака
В основе XSS лежит простая идея: если сайт принимает данные от пользователя и выводит их обратно на страницу без должной обработки, злоумышленник может подменить эти данные вредоносным кодом. Браузер получит страницу с этим кодом и исполнит его в привилегированном контексте сайта.
Проблема не в самом JavaScript как языке. Проблема — в том, как приложение обращается с пользовательскими данными: принимает, хранит, обрабатывает и выводит их.
Где появляется вредоносный скрипт
Точкой входа для XSS служит любое место, где сайт принимает данные от пользователя и впоследствии отображает их.
Типичные векторы внедрения:
- Поля форм: регистрация, авторизация, обратная связь
- Строка поиска и фильтры
- Комментарии, отзывы, рейтинги
- Личный кабинет: имя, фамилия, описание профиля
- Чат и сообщения в поддержку
- URL-параметры, GET-запросы, POST запросы итд
- Загружаемые файлы с метаданными
Почему браузер выполняет вредоносный код
Браузер работает по простому принципу, если контент получен от сайта, которому пользователь доверяет, браузер исполняет его без дополнительных вопросов. Он не умеет отличать "авторский" JavaScript от кода, который злоумышленник внедрил через уязвимое поле ввода.
Хорошая метафора: представьте официальное письмо от банка. Вы доверяете отправителю и читаете содержимое. Но если злоумышленник смог вложить в конверт свою записку вместе с оригинальным письмом, вы прочитаете и её — потому что доверяете источнику, а не содержимому.
Именно так работает XSS, браузер доверяет сайту и исполняет весь код, который получает от него, включая внедренный злоумышленником.
Кто страдает от XSS — сайт, пользователь или бизнес
Короткий ответ: страдают все.
Технически скрипт исполняется в браузере пользователя. Но последствия затрагивают каждую из сторон
| Сторона | Что происходит | Последствия |
| Пользователь | Скрипт исполняется в его браузере | Кража данных, компрометация аккаунта, фишинг |
| Сайт | Используется как вектор атаки | Потеря доверия, технические инциденты |
| Бизнес | Репутационный и финансовый ущерб | Потеря клиентов, затраты на реагирование, юридические риски |
Владелец сайта несет ответственность за то, что происходит с данными пользователей на его платформе. Даже если атака технически реализована через браузер клиента, источником проблемы является небезопасный код приложения.
Виды XSS-уязвимостей
Все XSS-уязвимости объединяет одна механика: вредоносный скрипт попадает на страницу и исполняется браузером. Но способ доставки и хранения вредоносного кода различается. Именно по этому признаку принято выделять три основных типа XSS.
| Тип | Payload хранится | Жертва | Масштаб угрозы |
| Stored XSS | На сервере / в БД | Все посетители страницы | Высокий |
| Reflected XSS | Нигде, отражается в ответе | Конкретный пользователь | Средний |
| DOM-based XSS | Только в клиентском коде | Конкретный пользователь | Средний / высокий |
Stored XSS
Stored XSS (также называют Persistent XSS или постоянная XSS) — это вид атаки, при котором вредоносный скрипт сохраняется на сервере или в базе данных и затем отображается другим пользователям.
- Как это работает:
Злоумышленник вводит payload в поле, данные которого сохраняются: комментарий, отзыв, имя профиля, описание товара. - Сайт сохраняет данные без проверки.
- Другие пользователи открывают страницу с этим контентом.
- Браузер каждого из них получает страницу со скриптом и исполняет его.
Почему это особенно опасно: Один payload может затронуть неограниченное число пользователей. Злоумышленнику не нужно взаимодействовать с каждой жертвой отдельно.
Где чаще всего встречается:
- Разделы комментариев и отзывов
- Форумы и сообщества
- Профили пользователей
- Панели администратора
- Системы тикетов и обращений в поддержку
- Описания товаров в e-commerce
Пример сценария: злоумышленник оставляет отзыв на товар со скриптом. Тысячи покупателей, открывающих страницу товара, получают исполненный вредоносный код в своем браузере.
Reflected XSS
Reflected XSS (отраженная XSS) — это тип атаки, при котором вредоносный payload не сохраняется на сервере, а сразу "отражается" в HTTP-запросе и попадает на страницу.
Как это работает:
- Злоумышленник формирует специальную ссылку с payload в параметре URL.
- Жертва переходит по этой ссылке — например, из письма, мессенджера или другого сайта.
- Сервер возвращает страницу, в которую вставлен payload из параметра запроса.
- Браузер жертвы исполняет скрипт.
Ключевая особенность: Reflected XSS требует, чтобы жертва сама перешла по подготовленной ссылке. Именно поэтому эта атака часто сочетается с социальной инженерией: злоумышленник маскирует ссылку под легитимную и отправляет ее жертве.
Где чаще всего встречается:
- Страницы результатов поиска
- Сообщения об ошибках
- Страницы с параметрами из URL
- Формы с предзаполненными полями
Пример сценария: злоумышленник отправляет пользователю ссылку на знакомый сайт с вредоносным параметром в URL. Пользователь доверяет домену и переходит. Страница загружается как обычно, но вместе с ней исполняется скрипт.
Чем опасна XSS-уязвимость
XSS — это не абстрактный технический баг. Это реальный вектор атаки с измеримыми последствиями для пользователей и бизнеса. Выполненный скрипт может читать данные страницы, отправлять их злоумышленнику, выполнять действия от имени пользователя и полностью подменять интерфейс.
Что может сделать злоумышленник через XSS:
- Получить доступ к сессионным данным и токенам
- Выполнить действия от имени пользователя
- Считать данные с текущей страницы
- Перехватить вводимые данные форм
- Подменить элементы интерфейса
- Перенаправить пользователя на вредоносный ресурс
- Загрузить дополнительные скрипты
- Использовать браузер жертвы для атак на другие ресурсы
Кража сессий и учетных данных
Один из наиболее известных сценариев эксплуатации XSS — получение доступа к сессионным данным пользователя.
Как это происходит: Исполненный скрипт может читать данные, доступные в контексте страницы: токены, идентификаторы сессий, данные форм, информацию из localStorage и sessionStorage. Эти данные отправляются злоумышленнику, который получает возможность действовать от имени жертвы.
Что оказывается под угрозой:
- Сессионные токены и идентификаторы
- Данные форм авторизации
- Токены CSRF
- Данные localStorage и sessionStorage
- Содержимое текущей страницы
Важно: атрибут HttpOnly для cookie закрывает доступ к ним через JavaScript, что снижает часть рисков. Но XSS не ограничивается только кражей cookie. Злоумышленник может читать данные страницы, перехватывать ввод форм и выполнять действия от имени пользователя даже без доступа к cookie.
Подмена контента и фишинг
XSS позволяет злоумышленнику изменить то, что видит пользователь на странице сайта: подменить форму входа, добавить фальшивое уведомление, встроить поддельную кнопку оплаты или полностью заменить интерфейс.
Чем это опаснее обычного фишинга? Классический фишинг использует поддельный домен, который внимательный пользователь может распознать. При XSS подмена происходит на реальном домене, которому пользователь доверяет. Адресная строка браузера показывает знакомый URL — это усыпляет бдительность.
Типичные сценарии подмены:
| Что подменяется | Цель злоумышленника |
| Форма входа | Кража логина и пароля |
| Форма оплаты | Перехват платежных данных |
| Уведомление или баннер | Социальная инженерия |
| Кнопка действия | Выполнение нежелательного действия |
| Контент страницы | Дезинформация, манипуляция |
| Редирект | Перенаправление на вредоносный ресурс |
Пример сценария: злоумышленник через XSS подменяет форму входа в личный кабинет интернет-магазина. Пользователь видит привычный интерфейс на знакомом домене, вводит логин и пароль — данные уходят злоумышленнику, а не на сервер магазина.
Подмена контента и фишинг
XSS позволяет злоумышленнику изменить то, что видит пользователь на странице сайта: подменить форму входа, добавить фальшивое уведомление, встроить поддельную кнопку оплаты или полностью заменить интерфейс.
Чем это опаснее обычного фишинга? Классический фишинг использует поддельный домен, который внимательный пользователь может распознать. При XSS подмена происходит на реальном домене, которому пользователь доверяет. Адресная строка браузера показывает знакомый URL — это усыпляет бдительность.
Типичные сценарии подмены:
| Что подменяется | Цель злоумышленника |
| Форма входа | Кража логина и пароля |
| Форма оплаты | Перехват платежных данных |
| Уведомление или баннер | Социальная инженерия |
| Кнопка действия | Выполнение нежелательного действия |
| Контент страницы | Дезинформация, манипуляция |
| Редирект | Перенаправление на вредоносный ресурс |
Пример сценария: злоумышленник через XSS подменяет форму входа в личный кабинет интернет-магазина. Пользователь видит привычный интерфейс на знакомом домене, вводит логин и пароль — данные уходят злоумышленнику, а не на сервер магазина.
Где чаще всего встречается XSS
XSS — не привилегия устаревших или плохо сделанных сайтов. Уязвимость возникает там, где пользовательские данные принимаются, обрабатываются и выводятся обратно — а это есть практически в каждом современном веб-приложении. Разница лишь в том, насколько безопасно реализована эта цепочка.
Формы, поиск, комментарии и личные кабинеты
Любой интерфейсный элемент, который принимает ввод от пользователя и затем отображает его, является потенциальной точкой риска.
Типичные зоны риска:
- Формы регистрации и авторизации
- Поля имени, фамилии, описания профиля
- Строка поиска и фильтры каталога
- Комментарии к товарам, статьям, постам
- Отзывы и рейтинги
- Формы обратной связи и заявок
- Чат и система тикетов поддержки
- Поля адреса доставки и заметок к заказу
- Личный кабинет с редактируемыми данными
Где чаще всего встречается XSS
XSS — не привилегия устаревших или плохо сделанных сайтов. Уязвимость возникает там, где пользовательские данные принимаются, обрабатываются и выводятся обратно — а это есть практически в каждом современном веб-приложении. Разница лишь в том, насколько безопасно реализована эта цепочка.
Формы, поиск, комментарии и личные кабинеты
Любой интерфейсный элемент, который принимает ввод от пользователя и затем отображает его, является потенциальной точкой риска.
Типичные зоны риска:
- Формы регистрации и авторизации
- Поля имени, фамилии, описания профиля
- Строка поиска и фильтры каталога
- Комментарии к товарам, статьям, постам
- Отзывы и рейтинги
- Формы обратной связи и заявок
- Чат и система тикетов поддержки
- Поля адреса доставки и заметок к заказу
- Личный кабинет с редактируемыми данными
JavaScript-интерфейсы и SPA-приложения
Современные frontend-приложения на React, Vue, Angular и других фреймворках не защищены от XSS автоматически. Фреймворки предоставляют встроенные механизмы защиты, но они работают только при правильном использовании. Небезопасные практики разработки открывают путь к DOM-based XSS даже в современных приложениях.
Типичные ошибки в SPA-приложениях:
- Использование dangerouslySetInnerHTML в React без sanitization
- Прямая вставка данных через innerHTML в обход фреймворка
- Небезопасная работа с v-html во Vue без проверки данных
- Использование bypassSecurityTrustHtml в Angular
- Вставка данных из URL, hash или параметров запроса без экранирования
- Подключение сторонних скриптов и виджетов без проверки
- Небезопасная обработка данных из postMessage
| Характеристика | Классический сайт | SPA-приложение |
| Где формируется HTML | На сервере | В браузере |
| Видимость payload серверу | Высокая | Низкая |
| Встроенная защита | Зависит от бэкенда | Зависит от фреймворка |
| Основной риск | Stored / Reflected XSS | DOM-based XSS |
| Сложность обнаружения | Средняя | Высокая |
Важно для команд разработки: использование React, Vue или Angular не означает автоматическую защиту от XSS. Фреймворк защищает только при соблюдении безопасных практик работы с данными.
Пример XSS-атаки
Чтобы лучше понять механику XSS, полезно рассмотреть конкретный сценарий. Ниже — упрощенный образовательный пример, который показывает логику атаки без рабочих эксплойтов.
Простой сценарий атаки без сложного кода
Исходная ситуация: Интернет-магазин позволяет покупателям оставлять отзывы о товарах. Отзывы сохраняются в базе данных и отображаются на странице товара для всех посетителей.
Шаг 1. Злоумышленник находит уязвимое поле
Он проверяет, как сайт обрабатывает пользовательский ввод. Поле отзыва принимает произвольный текст и выводит его на страницу без обработки.
Шаг 2. Злоумышленник вводит вредоносную вставку
Вместо обычного текста он вводит фрагмент, содержащий скрипт. Сайт принимает его как обычный отзыв и сохраняет в базе данных.
Шаг 3. Страница отображается другим пользователям
Любой посетитель, открывающий страницу товара, получает HTML с сохраненным скриптом.
Шаг 4. Браузер исполняет скрипт
Браузер посетителя не различает авторский код сайта и внедренный скрипт. Он исполняет всё, что получил в составе страницы.
Шаг 5. Данные уходят злоумышленнику
Скрипт выполняет заложенную злоумышленником логику: читает данные, отправляет их на внешний сервер, подменяет интерфейс или выполняет действия от имени пользователя.
Что происходит после выполнения скрипта
После того как скрипт исполнен в браузере жертвы, злоумышленник получает возможность реализовать широкий спектр сценариев — в зависимости от того, какую логику он заложил в payload.
Возможные действия после исполнения скрипта:
- Чтение и отправка данных текущей страницы на внешний сервер
- Перехват данных, вводимых пользователем в формы
- Чтение содержимого localStorage и sessionStorage
- Выполнение запросов от имени пользователя
- Подмена элементов интерфейса
- Перенаправление пользователя на вредоносный ресурс
- Загрузка и исполнение дополнительных скриптов
- Использование браузера жертвы как инструмента для атак на другие ресурсы
Насколько быстро это происходит? Исполнение скрипта и передача данных злоумышленнику занимают доли секунды. Пользователь чаще всего не замечает ничего подозрительного: страница выглядит и работает как обычно.
Для бизнеса это означает: факт компрометации может долгое время оставаться незамеченным — особенно при Stored XSS, когда payload активен на странице до момента его обнаружения и удаления.
Как защититься от XSS
Защита от XSS не строится на одной мере. Это комбинация безопасных практик разработки, корректной обработки данных, политик браузера и регулярного тестирования. Каждый уровень защиты снижает риск или ограничивает последствия.
Многоуровневая модель защиты:
Уровень 1: Безопасная разработка
- Валидация ввода
- Контекстное экранирование вывода
Уровень 2: Защитные политики браузера
- Content Security Policy (CSP)
- Security headers
Уровень 3: Защита сессий и токенов
- HttpOnly
- Secure, SameSite
Уровень 4: Регулярное тестирование
- Ручной аудит
- Автоматизированное сканирование
Валидация и фильтрация пользовательского ввода
Валидация входных данных — первый рубеж защиты. Приложение должно проверять, соответствуют ли полученные данные ожидаемому формату, и отклонять или обрабатывать те, что не соответствуют.
Что включает валидация ввода:
- Проверка типа данных: строка, число, дата, email
- Проверка допустимой длины
- Проверка допустимых символов и формата
- Отклонение или нейтрализация недопустимых значений
Подходы к фильтрации:
| Подход | Описание | Ограничения |
| Whitelist (разрешающий список) | Принимать только то, что явно разрешено | Требует четкого определения допустимых значений |
| Blacklist (запрещающий список) | Блокировать известные опасные паттерны | Легко обойти через обфускацию и кодировки |
| Sanitization | Очищать данные от потенциально опасных элементов | Не заменяет экранирование при выводе |
Важно: валидация и фильтрация ввода снижают риск, но не являются достаточной защитой от XSS сами по себе. Основная мера защиты — безопасный вывод данных в правильном контексте.
Типичная ошибка, олагаться только на фильтрацию ввода и считать задачу решенной. Злоумышленник может использовать нестандартные кодировки, разбивку строк и другие техники обхода фильтров. Поэтому фильтрация ввода должна дополняться экранированием вывода.
Экранирование данных при выводе
Это наиболее важная и базовая мера защиты от XSS. Любые данные, полученные от пользователя или из внешних источников, должны быть экранированы перед вставкой в страницу — в соответствии с контекстом вывода.
Что такое контекстное экранирование? Один и тот же символ может быть опасным в одном контексте и безопасным в другом. Поэтому экранирование должно учитывать, куда именно вставляются данные.
| Контекст вывода | Что нужно экранировать | Пример опасного символа |
| HTML-контент | Специальные HTML-символы | <, >, &, ", ' |
| HTML-атрибут | Символы, нарушающие атрибут | ", ', пробел |
| JavaScript | Символы, нарушающие строку | \, ", ', перенос строки |
| URL | Символы, нарушающие структуру URL | <, >, ", пробел |
| CSS | Символы, нарушающие CSS-выражение | (, ), ", ' |
Практические рекомендации:
- Использовать встроенные механизмы экранирования фреймворка или шаблонизатора
- Не отключать автоматическое экранирование в шаблонизаторах без крайней необходимости
- При необходимости ручной вставки HTML использовать проверенные библиотеки sanitization
- Никогда не вставлять непроверенные данные напрямую в JavaScript-код
- Проверять каждый контекст вывода отдельно — логика экранирования для HTML и для JavaScript различается
Распространенные ошибки при работе с выводом:
| Ошибка | Последствие |
| Вставка данных в HTML без экранирования | Классический XSS через HTML-контент |
| Вставка данных в атрибуты без кавычек | Нарушение структуры атрибута, XSS |
| Вставка данных в JavaScript как строки без экранирования | Выход из строкового контекста, исполнение кода |
| Использование innerHTML вместо textContent | DOM-based XSS |
| Отключение автоэскейпинга в шаблонизаторе | Полная потеря защиты на уровне шаблона |
Ключевой принцип: относитесь к любым внешним данным как к потенциально опасным и всегда экранируйте их в соответствии с контекстом вывода.
Экранирование данных при выводе
Это наиболее важная и базовая мера защиты от XSS. Любые данные, полученные от пользователя или из внешних источников, должны быть экранированы перед вставкой в страницу — в соответствии с контекстом вывода.
Что такое контекстное экранирование? Один и тот же символ может быть опасным в одном контексте и безопасным в другом. Поэтому экранирование должно учитывать, куда именно вставляются данные.
| Контекст вывода | Что нужно экранировать | Пример опасного символа |
| HTML-контент | Специальные HTML-символы | <, >, &, ", ' |
| HTML-атрибут | Символы, нарушающие атрибут | ", ', пробел |
| JavaScript | Символы, нарушающие строку | \, ", ', перенос строки |
| URL | Символы, нарушающие структуру URL | <, >, ", пробел |
| CSS | Символы, нарушающие CSS-выражение | (, ), ", ' |
Практические рекомендации:
- Использовать встроенные механизмы экранирования фреймворка или шаблонизатора
- Не отключать автоматическое экранирование в шаблонизаторах без крайней необходимости
- При необходимости ручной вставки HTML использовать проверенные библиотеки sanitization
- Никогда не вставлять непроверенные данные напрямую в JavaScript-код
- Проверять каждый контекст вывода отдельно — логика экранирования для HTML и для JavaScript различается
Распространенные ошибки при работе с выводом:
| Ошибка | Последствие |
| Вставка данных в HTML без экранирования | Классический XSS через HTML-контент |
| Вставка данных в атрибуты без кавычек | Нарушение структуры атрибута, XSS |
| Вставка данных в JavaScript как строки без экранирования | Выход из строкового контекста, исполнение кода |
| Использование innerHTML вместо textContent | DOM-based XSS |
| Отключение автоэскейпинга в шаблонизаторе | Полная потеря защиты на уровне шаблона |
Ключевой принцип: относитесь к любым внешним данным как к потенциально опасным и всегда экранируйте их в соответствии с контекстом вывода.
Безопасная работа с cookie и сессиями
Грамотная настройка cookie и управление сессиями помогают ограничить ущерб в случае успешной эксплуатации XSS.
Ключевые атрибуты безопасности cookie:
| Атрибут | Что делает | Польза |
| HttpOnly | Запрещает доступ к cookie через JavaScript | Защищает сессионные cookie от чтения скриптом |
| Secure | Передает cookie только по HTTPS | Защищает от перехвата в сети |
| SameSite=Strict | Запрещает отправку cookie в кросс-сайтовых запросах | Снижает риск CSRF, косвенно ограничивает XSS |
| SameSite=Lax | Частичное ограничение кросс-сайтовых запросов | Баланс безопасности и функциональности |
Дополнительные меры по управлению сессиями:
- Устанавливать разумный срок жизни сессии
- Инвалидировать сессию при выходе из аккаунта
- Привязывать сессию к дополнительным параметрам: User-Agent, IP
- Использовать ротацию токенов при чувствительных операциях
- Реализовывать обнаружение аномальных сессий
Важно понимать: атрибут HttpOnly защищает cookie от прямого чтения через JavaScript, но не устраняет XSS-уязвимость. Злоумышленник может использовать исполненный скрипт для других целей — перехвата форм, подмены интерфейса, выполнения запросов от имени пользователя.
Регулярное тестирование безопасности
Даже при соблюдении всех практик безопасной разработки уязвимости могут появляться: после обновлений, новых интеграций, смены библиотек, рефакторинга или ошибок в кастомном коде. Регулярное тестирование безопасности — это способ находить XSS до того, как это сделает злоумышленник.
Когда проводить тестирование:
- Перед запуском нового проекта или крупного релиза
- После значительных изменений в frontend-логике
- После обновления CMS, фреймворка или ключевых зависимостей
- После добавления новых форм, модулей и пользовательских сценариев
- После интеграции сторонних виджетов и скриптов
- При подключении нового платежного модуля или личного кабинета
- На регулярной основе — как часть процесса управления безопасностью
Ключевой принцип: безопасность — это процесс, а не состояние. Одноразовая проверка не гарантирует защиту при последующих изменениях продукта.
Чем XSS отличается от CSRF и SQL-инъекций
XSS часто упоминается вместе с другими популярными веб-уязвимостями. Важно понимать различия: у каждой своя механика, свои последствия и свои меры защиты.
Общая сравнительная таблица:
| Характеристика | XSS | CSRF | SQL Injection |
| Цель атаки | Браузер пользователя | Действия пользователя | База данных сервера |
| Где исполняется | В браузере жертвы | На сервере | На сервере |
| Что внедряется | JavaScript-код | Нежелательный запрос | SQL-код |
| Кто страдает | Пользователь и бизнес | Пользователь и бизнес | Сервер и данные |
| Основная защита | Экранирование вывода, CSP | CSRF-токены, SameSite | Параметризованные запросы |
Разница между XSS и CSRF
XSS — злоумышленник внедряет и исполняет вредоносный скрипт в браузере пользователя в контексте доверенного сайта.
CSRF (Cross-Site Request Forgery) — злоумышленник заставляет браузер авторизованного пользователя отправить нежелательный запрос на сервер. Пользователь даже не подозревает, что от его имени выполняется какое-то действие.
Ключевое различие:
| Параметр | XSS | CSRF |
| Что делает злоумышленник | Внедряет и исполняет код | Заставляет браузер отправить запрос |
| Нужен ли скрипт на странице | Да | Нет |
| Откуда исходит угроза | Уязвимый сайт | Внешний сайт злоумышленника |
| Защита | Экранирование, CSP | CSRF-токены, SameSite cookie |
| Цель | Данные и действия пользователя | Действия от имени пользователя |
Простая аналогия:
XSS — злоумышленник проник в ваш офис и подменил документы на столе
CSRF — злоумышленник снаружи заставил вашего сотрудника подписать нужный ему документ
Важная связь: успешная XSS-атака может помочь злоумышленнику обойти CSRF-защиту, поскольку исполненный скрипт имеет доступ к CSRF-токенам на странице.
Разница между XSS и SQL Injection
XSS направлен на браузер и интерфейс: злоумышленник воздействует на то, что видит и получает пользователь.
SQL Injection направлен на базу данных сервера: злоумышленник внедряет SQL-код в запрос к базе данных и получает возможность читать, изменять или удалять данные.
Ключевое различие:
| Параметр | XSS | SQL Injection |
| Цель атаки | Браузер пользователя | База данных сервера |
| Что внедряется | JavaScript | SQL-код |
| Где исполняется | В браузере клиента | На сервере |
| Что под угрозой | Данные пользователя, сессия | Вся база данных |
| Основная защита | Экранирование вывода | Параметризованные запросы |
Простая аналогия:
XSS — злоумышленник подменил витрину магазина: покупатели видят то, что нужно злоумышленнику
SQL Injection — злоумышленник проник на склад и получил доступ ко всем товарам и документам
Общее у XSS и SQL Injection: обе уязвимости возникают из-за небезопасной обработки пользовательских данных. Разница — в том, куда эти данные попадают: в HTML-страницу или в SQL-запрос.