XSS — одна из самых распространённых веб-уязвимостей. Она возникает, когда сайт позволяет внедрить вредоносный JavaScript в страницу, которую откроют другие пользователи. Итог — кража сессий, подмена интерфейса, фишинг, выполнение действий от имени жертвы.
Какие бывают виды XSS 👇
Stored XSS
Вредоносный код сохраняется на сервере: в комментариях, профиле, сообщениях, CMS-полях. Каждый посетитель страницы получает этот скрипт в браузер. Это самый опасный вариант из-за массового воздействия.Reflected XSS
Скрипт передаётся в запросе — например, через URL-параметр или форму поиска — и сразу отражается в ответе сервера. Обычно используется в фишинговых ссылках.DOM-based XSS
Уязвимость находится на стороне клиента. Скрипт попадает в опасные JavaScript-конструкции вродеinnerHTML,document.write,eval, и браузер сам создаёт уязвимый DOM.
Как эксплуатируют XSS ⚠️
Типичные сценарии атаки:
- кража cookie и токенов, если нет флагов
HttpOnly - подмена формы входа и сбор логинов/паролей
- выполнение действий от имени пользователя в админке
- внедрение кейлоггеров и редиректов
- обход доверия внутри корпоративных панелей
Важно: современный XSS — это не только alert(1). Реальные атаки строятся вокруг токенов, SPA-интерфейсов, API и слабой клиентской логики.
Пример опасной практики
Если приложение вставляет пользовательский ввод в HTML без экранирования, например в комментарии или имя профиля, злоумышленник может внедрить тег с обработчиком события. Браузер выполнит код при открытии страницы.
Как защититься от XSS 🛡️
Экранировать вывод по контексту
HTML, атрибуты, JavaScript, URL и CSS требуют разного экранирования. Универсальной “очистки” не существует.Фильтровать и валидировать ввод
Разрешительные списки безопаснее запретов. Проверяйте формат, длину, тип данных.Не использовать опасные DOM API
ИзбегайтеinnerHTML,outerHTML,document.write,eval,setTimeout(string). ПредпочтительныtextContent,createElement, безопасные шаблонизаторы.Включить CSP (Content Security Policy)
CSP ограничивает выполнение встроенных скриптов и загрузку внешнего JS. Это не замена экранированию, а сильный дополнительный слой защиты.Использовать HttpOnly, Secure, SameSite для cookie
Даже при XSS это снижает риск кражи сессионных данных.Санитизировать HTML, если он действительно нужен
Например, через проверенные библиотеки вроде DOMPurify, а не самописные regex-фильтры.Обновлять фронтенд и CMS
Многие XSS приходят через плагины, WYSIWYG-редакторы и устаревшие зависимости.
Как искать XSS при аудите 🧪
- анализировать все точки ввода и отражения данных
- проверять параметры URL, формы, заголовки, JSON
- тестировать DOM-manipulation в DevTools
- смотреть, как шаблоны рендерят данные
- использовать Burp Suite, CSP Evaluator, SAST/DAST-инструменты
Главный вывод
XSS — это не “мелкий баг фронта”, а полноценный вектор захвата пользовательской сессии и компрометации бизнеса. Надёжная защита строится на безопасной обработке данных, корректном рендеринге, CSP и дисциплине разработки. 🚀
Подборку полезных каналов про IT — разработку, безопасность и инфраструктуру — стоит посмотреть ниже.