Чужой код в доверенном месте
XSS (Cross-Site Scripting) — уязвимость, при которой злоумышленник добивается выполнения своего JavaScript-кода в браузере жертвы в контексте настоящего сайта. Браузер доверяет скриптам страницы, поэтому такой код получает те же возможности, что и сайт: читать содержимое, отправлять запросы от имени пользователя, менять вид страницы.
Причина всегда одна: сайт выводит в HTML данные, пришедшие извне, и не превращает их в безопасный текст. Комментарий, имя профиля или параметр в адресе оказывается разобран браузером как разметка и код.
Три основных вида
Хранимый XSS: вредоносная вставка сохраняется на сервере, например в комментарии, и выполняется у каждого, кто откроет страницу. Отражённый: код передаётся в параметре ссылки, сервер возвращает его на страницу, и он срабатывает у того, кто перешёл по этой ссылке. DOM-вариант возникает целиком в браузере: клиентский скрипт берёт данные из адреса или хранилища и небезопасно вставляет их в страницу, не обращаясь к серверу.
Отражённый вариант опирается на социальную инженерию: жертву нужно заставить открыть специальную ссылку, поэтому он сочетается с фишингом.
Политика безопасности контента простыми словами
CSP — заголовок ответа, с помощью которого сайт сообщает браузеру, откуда разрешено загружать скрипты, стили и изображения и разрешено ли выполнять встроенные вставки. Если политика строгая, то даже при ошибке экранирования внедрённый скрипт не выполнится: браузер увидит, что источник не входит в список разрешённых, и заблокирует его.
Внедрять CSP нужно постепенно. Сначала включают режим отчётов, при котором нарушения только записываются, а сайт продолжает работать. Затем по отчётам исправляют встроенные скрипты и сторонние подключения и после этого переходят к блокирующему режиму. Слишком свободная политика с разрешением любых источников бесполезна, поэтому важна аккуратность. CSP не заменяет экранирование, а дополняет его как второй барьер: правильный порядок — сначала исправить причину, потом добавлять заголовок.
Что можно сделать через XSS
Читать данные страницы, подменять формы входа, отправлять действия от имени пользователя, изменять содержимое. Если cookie сессии не защищена флагом HttpOnly, скрипт может её прочитать и передать, что позволяет перехватить сессию, как объяснено на странице про сессии и токены. Даже при защищённой cookie возможны действия от имени пользователя без кражи токена.
Исход зависит от привилегий: XSS в кабинете администратора намного опаснее, чем на публичной странице без входа.
Как защищаются
Основное — экранирование вывода: специальные символы превращаются в безопасные сущности, и данные отображаются как текст. Экранировать нужно с учётом контекста: в теле HTML, в атрибутах, в JavaScript и в адресах правила различаются. Современные шаблонизаторы и фреймворки делают это по умолчанию, а опасные вставки происходят при отключении защиты.
Второй слой — политика безопасности контента (CSP), которая ограничивает источники скриптов, и флаги HttpOnly и SameSite для cookie. Валидация ввода полезна, но не заменяет экранирование вывода.
На практике полезно тестировать формы обычными «плохими» значениями: угловые скобки, кавычки, специальные символы. Если после сохранения они отображаются на странице как обычный текст, экранирование работает. Если страница ломается или меняет вид, это сигнал: необходимо проверить, как данные попадают в разметку.
Для пользователя и владельца сайта
Пользователю помогают обновлённый браузер, осторожность к длинным ссылкам с непонятными параметрами и выход из аккаунтов после работы. Расширения безопасности могут блокировать часть подобных скриптов, но полагаться на них нельзя.
Владельцу сайта стоит проверять места, где отображаются данные пользователей, включать CSP, использовать проверенные библиотеки и регулярно тестировать формы и параметры на своих стендах. Найдя чужую уязвимость, сообщайте владельцу, не пытаясь использовать её.
Тем, кто пишет свой код, полезно запомнить простой принцип: любые данные, пришедшие снаружи, считаются недоверенными, пока не преобразованы под контекст вывода. Не собирайте HTML из строк вручную, используйте методы, которые вставляют текст как текст, а не как разметку, и подключайте только проверенные библиотеки санитизации, если нужно разрешить ограниченное форматирование пользователей.