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

DOM-based XSS

DOM-based XSS (основанный на объектной модели документа) отличается тем, что уязвимость возникает на стороне клиента, в коде JavaScript, который динамически обрабатывает данные из источника (source) и передаёт их в приёмник (sink), способный выполнить код. Сервер может не участвовать в атаке — вредоносный код встраивается в DOM-дерево через URL-фрагмент (hash), параметры URL или данные из localStorage. Пример: JavaScript-код на странице считывает window.location.hash и вставляет его в innerHTML элемента без проверки. Если в URL указан #<img src=x onerror=alert(1)>, браузер выполнит скрипт.

Механизм атаки

Вне зависимости от типа, XSS-атака следует общему сценарию:

1. Обнаружение точки внедрения: злоумышленник находит поле ввода, параметр URL или другой источник данных, который передаётся в веб-страницу без должной санитизации (очистки).
2. Формирование полезной нагрузки: создаётся строка, содержащая HTML-теги и JavaScript-код, который будет выполнен в браузере жертвы. Полезная нагрузка может быть замаскирована с помощью кодирования (Unicode, hex, base64) для обхода фильтров.
3. Доставка полезной нагрузки: для отражённого XSS — через ссылку или перенаправление; для хранимого — через отправку данных на сервер; для DOM-based — через URL или другие клиентские источники.
4. Выполнение кода: браузер жертвы получает HTML-страницу, содержащую вредоносный скрипт, и интерпретирует его как часть легитимного контента сайта.
5. Реализация целей атаки: кража cookie-файлов, перехват сессионных токенов, подмена содержимого страницы, перенаправление на фишинговый сайт, установка кейлоггера, выполнение действий от имени пользователя (например, перевод денег, смена пароля).

Примеры уязвимых конструкций

Наиболее распространённые места, где возникают XSS-уязвимости:

• Вставка пользовательского ввода в HTML-контекст: <div> + innerHTML + непроверенные данные.
• Вставка в атрибуты HTML-тегов: <img src=" + данные + "> — если данные содержат кавычки, можно выйти из атрибута.
• Вставка в JavaScript-контекст: eval("var x = " + данные) или document.write(данные).
• Вставка в URL: location.href = "http://"; + данные — данные могут содержать javascript:alert(1).
• Вставка в CSS: element.style.background = "url(" + данные + ")" — данные могут содержать выражение, выполняющее JavaScript в старых браузерах.

Защита от межсайтового скриптинга

Методы защиты делятся на превентивные (на этапе разработки) и реактивные (на этапе эксплуатации).

Экранирование (Escaping)

Преобразование специальных символов HTML в их безопасные эквиваленты (сущности). Например, символ < заменяется на <, > на >, " на ", & на &. Экранирование должно применяться в зависимости от контекста вывода (HTML-тело, атрибут, JavaScript, CSS, URL). Библиотеки шаблонизаторов (например, Twig, Jinja2, React JSX) автоматически экранируют вывод по умолчанию.

Санитизация (Sanitization)

Удаление или преобразование потенциально опасных элементов из пользовательского ввода. Используется, когда необходимо разрешить пользователю вводить HTML-разметку (например, в редакторах форматированного текста). Санитизация выполняется с помощью специализированных библиотек (например, DOMPurify, HTML Purifier), которые удаляют теги <script>, обработчики событий (onclick, onerror), опасные атрибуты (href="javascript:...") и фреймы.

Content Security Policy (CSP)

Политика безопасности контента — механизм HTTP-заголовков, позволяющий веб-сайту указать браузеру, какие источники скриптов, стилей и других ресурсов разрешены. CSP может полностью блокировать выполнение инлайновых скриптов (скриптов, встроенных в HTML) и ограничить загрузку внешних скриптов только доверенными доменами. Пример заголовка: Content-Security-Policy: script-src 'self' https://trusted.cdn.com`. CSP является эффективной защитой от большинства XSS-атак, но не отменяет необходимость экранирования и санитизации.