Что такое межсайтовый скриптинг

Межсайтовый скриптинг: неочевидные угрозы и практики защиты

«На первый взгляд XSS кажется тривиальной уязвимостью, которую легко закрыть эскейпингом. На практике это портал для целевых атак, где вредоносный скрипт становится законной частью доверенного приложения. Проблема не в одном скрипте, а в том, что современный браузер не в состоянии отличить код разработчика от внедрённого злоумышленником, когда оба приходят из одного источника».

Суть атаки и её эволюция

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

Классическое деление на хранимые, отражённые и DOM-based XSS постепенно теряет чёткость. Реальные атаки часто являются гибридными, используя комбинацию техник. Например, отражённый XSS через параметр URL может использоваться для кражи токена сессии, который затем автоматически применяется для совершения действий от имени жертвы через уязвимый API, реализуя цепную атаку.

Виды XSS: за рамками базовой классификации

Тип	Механизм инъекции	Ключевая особенность	Пример уязвимого контекста
Хранимая (Stored)	Код сохраняется на сервере (в БД, файле, кеше) и отдаётся всем пользователям страницы.	Массовый эффект. Может лежать в спящем режиме до активации.	Комментарии, профили, сообщения на форуме, названия загруженных файлов.
Отражённая (Reflected)	Код передаётся через параметры запроса (URL, POST-данные) и немедленно отображается в ответе сервера.	Требует взаимодействия жертвы (переход по ссылке). Часто используется в фишинге.	Результаты поиска, сообщения об ошибках, PDF-генераторы с подстановкой данных в URL.
DOM-based	Код не доходит до сервера. Внедрение происходит через модификацию DOM на клиенте скриптами.	Серверные меры защиты бессильны. Уязвимость в клиентской логике.	Обработчики хеша (`location.hash`), чтение `document.referrer`, динамическое обновление страницы через `innerHTML`.
Слепая (Blind)	Частный случай хранимого XSS, когда результат выполнения скрипта не виден атакующему напрямую.	Обнаружение и эксплуатация сложнее. Скрипт совершает скрытые действия (запросы к контролируемому серверу).	Функции обратной связи, тикеты в поддержку, админ-панели с отложенным просмотром данных.

Стратегии защиты: глубже базового экранирования

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

1. Валидация и санитизация ввода: «очистка по контексту»

Главная ошибка — пытаться очистить данные один раз и для всех целей. Один и тот же фрагмент текста может быть безопасным в одном контексте и опасным в другом. «Иван <script>alert()</script>» — некорректное имя, но валидный пример кода в статье.

Входная валидация: Проверка на уровне бизнес-логики. Имя не должно содержать тегов, email должен соответствовать формату. Отклоняйте некорректные данные как можно раньше.
Выходное кодирование (escaping): Преобразование данных непосредственно перед встраиванием в конкретный контекст.
- HTML Context: Замена «, `&`, `»`, `’` на HTML-сущности (`<`, `>`, `&` и т.д.).
- Attribute Context: Особое внимание кавычкам. Используйте функции типа `encodeURIComponent` для атрибутов вроде `href`.
- JavaScript Context: Кодирование для строк внутри «. Никогда не встраивайте ненадёжные данные как код.
- URL Context: Строгая проверка протокола (`http:`, `https:`). Запрет на `javascript:`.

Современные фреймворки (React, Vue, Angular) по умолчанию выполняют выходное кодирование при рендеринге данных в шаблоны. Однако это не панацея: директивы вроде `v-html` в Vue или `dangerouslySetInnerHTML` в React отключают эту защиту, требуя ручной санитизации.

// ОПАСНО: React НЕ экранирует содержимое, переданное через dangerouslySetInnerHTML
const userContent = '<img src=x onerror=stealCookies()>';
return <div dangerouslySetInnerHTML={{__html: userContent}} />;

// БЕЗОПАСНО: Библиотеки типа DOMPurify очистят HTML перед вставкой
import DOMPurify from 'dompurify';
const cleanContent = DOMPurify.sanitize(userContent);
return <div dangerouslySetInnerHTML={{__html: cleanContent}} />;

2. Content Security Policy (CSP): последний рубеж обороны

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

// Пример строгой политики, подходящей для приложений с высокими требованиями безопасности
Content-Security-Policy:
  default-src 'none';         // По умолчанию всё запрещено
  script-src 'self';          // Скрипты только с текущего домена
  style-src 'self' 'unsafe-inline'; // Стили со своего домена, inline-стили разрешены (часто необходимо)
  img-src 'self' data: https:; // Картинки со своего домена, data-URI и по HTTPS
  connect-src 'self';         // XHR/Fetch только к своему API
  font-src 'self';
  form-action 'self';         // Формы можно отправлять только на свои адреса
  base-uri 'self';            // Запрет на подмену базового URL
  frame-ancestors 'none';     // Запрет на встраивание в frame (защита от кликджекинга)

Ключевые директивы для блокировки XSS: `script-src` (запрещает выполнение инлайн-скриптов и скриптов с недоверенных хостов) и `base-uri` (препятствует переопределению базового пути для ресурсов). Режим `Content-Security-Policy-Report-Only` позволяет тестировать политику без блокировок, собирая отчеты о нарушениях.

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

Дополнительные HTTP-заголовки создают барьеры для эксплуатации XSS.

`X-Content-Type-Options: nosniff` — запрещает браузеру «угадывать» MIME-тип, что предотвращает выполнение скрипта, замаскированного под картинку.
`X-Frame-Options: DENY` или заголовок `frame-ancestors` в CSP — защита от встраивания страницы во фрейм, что усложняет некоторые атаки.
Атрибут `HttpOnly` для cookies — делает куки недоступными для JavaScript, что защищает сессионные токены от кражи через XSS. Это обязательное требование при работе с персональными данными.

Поиск и тестирование уязвимостей

Проактивное тестирование — обязательная часть жизненного цикла защищённого приложения.

Статический анализ (SAST): Инструменты вроде SonarQube, Semgrep ищут паттерны уязвимого кода (использование `innerHTML`, `eval()`, неправильное конкатенация строк в запросах) на этапе разработки.
Динамический анализ (DAST) и ручное тестирование: Сканеры (Burp Suite, OWASP ZAP) и фаззеры автоматически подставляют тестовые векторы во все точки ввода. Ручное тестирование фокусируется на сложных клиентским рендерере (SPA) и бизнес-логике.
- Тестовые векторы: `alert(1)`, ``, «javascript:alert(1)«.
- Проверка всех sinks (приёмников данных): `innerHTML`, `document.write()`, `location`, `eval()`, `setTimeout()` с динамической строкой.
Анализ зависимостей: Регулярная проверка сторонних библиотек (например, через `npm audit`, `OWASP Dependency-Check`) на известные уязвимости, включая XSS в компонентах.

Культура безопасности в разработке

Технические меры не работают без организационных. Внедрение принципа «Не доверяй пользовательскому вводу» должно быть частью культуры команды.

Чёткие стандарты кодирования, требующие использования безопасных API (`textContent` вместо `innerHTML`).
Обязательный security-ревью изменений, затрагивающих обработку пользовательских данных.
Регулярное обучение разработчиков на основе разборов реальных инцидентов.
Ведение карты данных приложения для понимания потоков информации и точек, где применяется кодирование.

Межсайтовый скриптинг остаётся критической угрозой не из-за технической сложности, а из-за системных пробелов: в спешке бизнес-логика часто побеждает безопасность, а защита воспринимается как одноразовая задача, а не непрерывный процесс. Уязвимость появляется в момент, когда разработчик думает не «куда эти данные вставятся», а «как бы их поскорее отобразить». Настоящая защита — это архитектура, где данные по умолчанию считаются ненадёжными, а их безопасное отображение — единственно возможный путь.