XSS-уязвимость (межсайтовый скриптинг) - это возможность внедрить на страницу сайта чужой скрипт через любое поле, куда посетитель вводит текст: комментарий, отзыв, имя в форме заказа. Если сайт выводит введённое без очистки, скрипт исполняется в браузере каждого, кто открыл страницу, - от обычного покупателя до администратора. Так воруют сессии админки, подменяют платёжные реквизиты и уводят данные из форм. Защита - экранирование всего пользовательского контента при выводе.
Как обычный комментарий превращается в атаку
Сценарий из практики. На сайте есть форма отзывов, текст которых выводится на странице товара как есть. Злоумышленник оставляет «отзыв», внутри которого вместо текста - тег со скриптом. Теперь у каждого открывшего страницу этот скрипт выполняется в браузере: тихо, без визуальных следов. Когда страницу открывает администратор из админки модерации - скрипт крадёт его сессионную куку, и злоумышленник входит в админку без логина и пароля. Дальше - шеллы, редиректы и все прелести взлома, которые мы разбирали в статье как понять, что сайт взломан.
Какие бывают XSS-уязвимости
| Тип | Как работает | Кто под ударом |
|---|---|---|
| Хранимая XSS | Скрипт сохраняется в базе (отзыв, комментарий, поле профиля) и исполняется у всех, кто открыл страницу | Все посетители и админы; самый опасный тип |
| Отражённая XSS | Скрипт передаётся в ссылке (например, в параметре поиска) и исполняется при переходе по ней | Тот, кто кликнул подготовленную ссылку из письма или мессенджера |
| DOM-XSS | Уязвим javascript самой страницы: скрипт исполняется без участия сервера | Посетители; не видна в серверных логах, ловится только аудитом фронтенда |
Отражённую и DOM-разновидности часто недооценивают: мол, жертву ещё нужно заставить кликнуть по ссылке. На практике это решается фишинговым письмом «ваш заказ изменён» со ссылкой на настоящий сайт: фильтры пропускают, получатель кликает не глядя, ведь домен подлинный - вредоносную нагрузку несёт только параметр в адресе. Связка «XSS плюс социальная инженерия» - стандартный рабочий приём, а не экзотика.
Чем XSS-уязвимость грозит владельцу сайта
- Угон админских сессий - вход в админку без пароля, дальше полный контроль над сайтом
- Кража данных покупателей - скрипт-кейлоггер снимает всё, что вводится в формы: телефоны, адреса, карты
- Подмена контента - реквизиты, ссылки и кнопки меняются на лету только у посетителей, владелец ничего не видит
- Распространение вредоносного кода - с вашего сайта атакуют посетителей; антивирусы и поисковики заносят домен в чёрные списки
- Фишинг от вашего имени - поддельные формы входа и оплаты на настоящем домене, против которых бессильна проверка адресной строки
Масштаб ущерба зависит от посещаемости заражённой страницы: скрипт в карточке ходового товара за неделю отработает на тысячах посетителей. Для магазина с онлайн-оплатой XSS - прямой финансовый риск: подмена платёжных данных всплывает только после жалоб покупателей, когда деньги уже ушли не туда.
Найдём и закроем XSS-дыры на сайте
Проверим формы, отзывы, поиск и самописные компоненты, добавим экранирование и заголовки безопасности. Отчёт: что было уязвимо и что исправлено.
Как защитить сайт от XSS: практический минимум
- Экранируйте выводВсё, что ввёл пользователь, при выводе на страницу должно превращаться в безопасный текст. В Битрикс для этого есть штатные методы очистки и HTML-фильтр - в самописном коде их часто «забывают».
- Фильтруйте вводБелый список тегов для полей, где нужно форматирование, и полный запрет HTML там, где достаточно текста. Модерация отзывов до публикации - тоже фильтр.
- Включите проактивный фильтрWAF Битрикс перехватывает типовые XSS-пробы на входе - страховка от массовых сканирований ботами.
- Добавьте заголовки безопасностиContent-Security-Policy ограничивает, откуда странице можно загружать и исполнять скрипты: даже внедрённый код упрётся в запрет. Плюс флаги HttpOnly для кук - украсть сессию скриптом станет на порядок сложнее.
- Проверяйте после каждой доработкиКаждая новая форма и вывод пользовательских данных - потенциальная точка входа. Правило «вывел данные - экранируй» должно быть в чек-листе приёмки любой доработки.
Частые вопросы об XSS
У нас нет комментариев на сайте. Значит, XSS не грозит?
Чем XSS отличается от SQL-инъекции?
Защищает ли Битрикс от XSS из коробки?
Сколько стоит закрыть XSS-уязвимости на сайте?
XSS - атака незаметная: сайт выглядит здоровым, пока с него утекают сессии и данные клиентов. Надёжный способ спать спокойно - разовый аудит пользовательского ввода и вывода плюс дисциплина в новых доработках. Первое сделаем в рамках доработки сайтов, второе обеспечит абонентская поддержка: Alavir работает с Битрикс с 2013 года, за плечами 450+ проектов. Консультация бесплатная.












