Авторка: Kateryna Ivanenko, Invicti Brand Manager
Межсайтовый скриптинг (XSS) – это класс недостатков, позволяющих злоумышленникам выполнять вредоносный JavaScript в браузере цели. Это происходит, когда ненадежные данные включаются в веб-страницы без надлежащей обработки, что предоставляет возможности для захвата сессий пользователей, дефейса или последующих атак.
Фундаментальной причиной XSS является неправильная нейтрализация ненадежных входных данных при генерации веб-страницы или манипуляций DOM (CWE-79). Варианты XSS являются разными выражениями одной и той же основной проблемы, но в этом есть много нюансов.
Три типа XSS и причины их возникновения
Сохраненный XSS
Входящие данные, контролируемые злоумышленником, сохраняются приложением (например, в базе данных, CMS или комментарии) и позже отображаются на страницах других пользователей. Первопричиной обычно является смешение ненадежных данных с HTML-ответами без кодирования или очистки вывода.
Отображенный XSS
Ненадежные данные (например, из формы) сразу отображаются в ответе. Это часто возникает, когда шаблоны на стороне сервера включают параметры запроса без кодирования на основе контекста.
XSS на основе DOM
JavaScript на стороне клиента считывает данные, контролируемые злоумышленником (например, location.search или document.referrer), и записывает их в приемники (sinks), такие, как innerHTML, document.write или eval() без каких-либо безопасных практик. Дефект существует только в браузере, что затрудняет его обнаружение.
Основные причины, почему разработчики все еще допускают XSS
1) Смешивание данных и кода без кодирования на основе контекста
XSS процветает, когда программы интерполируют ненадежные данные непосредственно в HTML, атрибуты, JavaScript, CSS или URL-адреса, не используя правильную кодировку для этого контекста. Подхода “экранирование всего” недостаточно; его правила должны отличаться в зависимости от контекста. Неприменение правильного кодировщика является одной из главных причин, почему XSS продолжает существовать.
2) Опасные API и приемники на стороне клиента
Современный фронтенд часто манипулирует DOM при выполнении веб-сайта. Использование приемников, таких как innerHTML, outerHTML, insertAdjacentHTML, document.write или установка атрибутов обработчика событий on* с неочищенными строками, внедряет HTML/JS непосредственно в документ. Учебные материалы по безопасности постоянно обозначают их как риск, когда они поступают с данными, контролируемыми злоумышленником.
3) Доверие к источникам URL/DOM без проверки
Код на стороне клиента часто использует значения из источников, на которые оказывает влияние злоумышленник (настройки URL, идентификаторы фрагментов, document.referrer). Передача этих источников непосредственно в контексты HTML или скриптов без проверки или безопасного API дает проявиться XSS на основе DOM.
4) Недостаточная или неправильно примененная проверка входных данных
Хотя исходная кодировка является основной практикой, отсутствие надежной проверки белого списка для данных, которые должны стать HTML, увеличивает риск. Разработчики могут попробовать использовать фильтры на основе черных списков, которые не справляются с обфускацией и новыми методами полезной нагрузки, позволяя опасным токенам проскальзывать в контексты страниц.
5) Рендеринг пользовательского HTML без проверенного санитайзера
Такие функции, как комментарии, контент CMS или профили пользователей могут преднамеренно разрешать разметку (markup). Использование устаревших или кастомных санитайзеров – это распространенный путь к XSS. Если HTML должен быть принят, ему нужен активно поддерживаемый санитайзер и строгие политики в отношении разрешенных тегов/атрибутов/схем URL-адресов.
6) Внедрение шаблонов (templates) и опасные практики
Шаблоны на стороне сервера или клиента, работающие с входными данными пользователя без безопасных практик, могут привести к выполнению кода или XSS на странице.
7) Полагание исключительно на CSP
Политика безопасности контента (CSP) – это дополнительный уровень защиты, а не замена контекстно-зависимого кодирования. Слабый CSP создает ложное чувство безопасности, а также строгие CSP имеют ограничения.
8) Сторонние скрипты и риски цепочки поставки
Если виджеты, аналитика, реклама и другие посторонние скрипты небезопасно обрабатывают данные, контролируемые злоумышленником, или если цепочка поставки скомпрометирована, они могут дать проявиться XSS независимо от качества собственного кода сайта.
9) Устаревший код и фреймворки
Старые базы кода и библиотеки часто не имеют современных стандартных настроек (например, шаблонов автоматического экранирования). Без рефакторинга устаревшие шаблоны, такие как объединение строк HTML или встроенные атрибуты событий, сохраняются, постоянно внедряя уязвимость XSS.
10) Отсутствие тестирования безопасности
Даже с учетом вышеупомянутых практик единственный способ точно проверить, является ли веб-сайт уязвимым к XSS – это провести тестирование безопасности. Кроме того, многие инструменты дают советы по вы правления и полезные ресурсы в тикетах, помогающих разработчикам со временем внедрять безопасные практики написания кода.
Для этой цели можно использовать разные инструменты.
- DAST: безопасная имитация действий хакера, которая обнаруживает уязвимости веб-приложения во время его выполнения.
- SAST: статический анализ, находящий проблемы безопасности в коде «как в тексте».
Лучший способ сканировать веб-сайт – это использовать оба подхода, поскольку DAST находит больше реальных уязвимостей благодаря тестированию во время выполнения, а SAST способен сканировать всю базу кода и может быть интегрирован на более ранних стадиях CI/CD (DAST можно внедрять на более поздних этапах).
Если вы хотите бесплатно протестировать Invicti (DAST) на основе Acunetix и Netsparker с функцией подтверждения уязвимостей, а также Mend.io (SAST, SCA, Container Security), оставьте свою контактную информацию в форме ниже:
Запрос на бесплатное тестирование Invicti/Mend.io
Оставьте контакты и мы с вами свяжемся
