Wiki · Вредоносные технологии

XSS атака

5 мин чтенияАвтор: Станислав БарановСоавторы: Евгений Баев

XSS атака (Cross-Site Scripting, межсайтовый скриптинг) – это внедрение чужого JavaScript-кода в страницу сайта, который затем выполняется в браузерах посетителей. Сам сервер при этом может остаться нетронутым: удар приходится по тем, кто открыл страницу.

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

Хранимая, отражённая и DOM-based XSS

Вид	Где живёт скрипт	Типичное место
Хранимая	в базе сайта, показывается всем	отзывы, комментарии, имя в профиле, сообщения в чате
Отражённая	в ссылке, сайт возвращает его в ответе	страница поиска «Вы искали: …», сообщения об ошибках
DOM-based	в браузере, его вставляет JavaScript самой страницы	скрипты, которые берут данные из адреса и вставляют в страницу

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

Схема видов XSS атаки: хранимая в отзывах и профиле, отражённая через страницу поиска и ссылку, DOM-based через JavaScript страницы — Три вида XSS

Что скрипт делает в браузере посетителя и администратора

Кража сессии. Скрипт читает cookies и отправляет их злоумышленнику, а тот входит в аккаунт без пароля.
Действия от имени пользователя. Если скрипт сработал у администратора, он может создать нового админа или поменять настройки.
Подмена содержимого: поддельная форма оплаты, другой номер телефона, ссылка на фишинговый сайт.
Спам и перенаправления. Посетителей уводят на чужие сайты, а поисковики могут пометить сайт как опасный.

HTTPS от этого не спасает: он шифрует канал, а внедрённый скрипт выполнится и на защищённой странице.

Экранирование, CSP и флаги cookies

Главное правило: всё, что пришло от посетителя, при выводе превращается в текст, а не в код. Это называется экранированием: угловые скобки и кавычки заменяются безопасными обозначениями, и браузер показывает их как буквы. Вырезать слово script на входе вместо этого бесполезно. В 1С-Битрикс для этого есть функция htmlspecialcharsbx:

<?php
// Плохо: строка поиска выводится как есть
echo $_GET['q'];
// Хорошо: перед выводом данные экранируются
echo htmlspecialcharsbx($_GET['q']);

Экранируйте вывод с учётом места: текст страницы, атрибут тега, код JavaScript и адрес ссылки экранируют по-разному.
Если посетителям разрешена разметка, например в редакторе отзывов, пропускайте её через санитайзер с белым списком тегов.
Включите заголовок Content-Security-Policy. Он разрешает браузеру запускать скрипты только с перечисленных доменов.
Ставьте сессионным cookies флаги HttpOnly, Secure и SameSite. С HttpOnly скрипт на странице не прочитает cookie сессии. Подробнее в статье Файлы cookies.
Добавьте WAF. В 1С-Битрикс эту роль выполняет «Проактивный фильтр», он отсекает типовые попытки внедрить скрипт.

Схема хранимой XSS: без экранирования скрипт из отзыва выполняется в браузере посетителя, с экранированием выводится как безопасный текст — Как экранирование останавливает XSS

Упрощённый пример заголовка CSP:

Content-Security-Policy: default-src 'self'; script-src 'self' https://mc.yandex.ru

Счётчики, виджеты чатов и онлайн-оплата подгружают скрипты со своих доменов. Их придётся перечислить, иначе CSP их заблокирует. Поэтому политику сначала включают в режиме отчётов (заголовок Content-Security-Policy-Report-Only), смотрят, что она заблокировала бы, и только потом включают всерьёз.

Как проверить сайт на XSS

Составьте список мест, где сайт показывает то, что ввёл посетитель: поиск, отзывы, комментарии, профиль, сообщения об ошибках форм. Не забудьте админку, где менеджер читает те же отзывы. Для каждого проверьте в шаблоне, что вывод экранирован. В 1С-Битрикс проверьте отчёт «Сканера безопасности» и «Журнал вторжений». Заголовки CSP и флаги cookies видны во вкладке Network инструментов разработчика, а в базе отзывов и комментариев стоит поискать теги script.

Самописные шаблоны и компоненты проверяйте в первую очередь. Ядро CMS экранирует данные в стандартных компонентах, а в доработках об этом часто забывают.

Чек-лист проверки сайта на XSS: поиск, отзывы и комментарии, профиль, ошибки форм, админка, заголовки CSP и флаги cookies — Где проверить сайт на XSS

Признаки, что уязвимость уже используют

Посетители жалуются, что сайт перебрасывает их на чужие страницы, а у вас всё открывается нормально.
В отзывах или комментариях есть пустые записи или записи с набором странных символов.
В админке появились пользователи или настройки, которых никто не создавал.
Браузер или антивирус предупреждает об опасном содержимом на страницах сайта.

В этом случае действуют как при взломе: находят и удаляют внедрённый код, закрывают уязвимость в шаблоне, завершают все сессии и меняют пароли.

Почему после включения Content-Security-Policy перестала работать Метрика?

Политика не разрешила домен, с которого грузится счётчик, и браузер его заблокировал. Добавьте домены Метрики в правила CSP и заодно проверьте чат, виджет оплаты и карты. Новую политику безопаснее сначала прогнать в режиме отчётов и посмотреть, на что она жалуется.

Что значит запись о попытке атаки через XSS в журнале сайта?

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

Чем опасна XSS для сайта без личного кабинета?

Ровно так же: скрипту не нужен вход, он работает в браузере любого посетителя. Может подменить телефон, увести людей на чужой сайт, а сработав у менеджера в админке, открыть управление сайтом.

Что в 1С-Битрикс уже экранирует вывод, а что проверять самим?

Стандартные компоненты выводят данные экранированными, а «Проактивный фильтр» отсекает типовые попытки внедрения. На разработчике остаются самописные шаблоны, переделанные компоненты и обработчики форм: там htmlspecialcharsbx вызывают явно при каждом выводе пользовательских данных. Именно в таких доработках дыры и находят, когда про экранирование забыли.

Какие флаги нужны cookie сессии и от чего каждый защищает?

HttpOnly, Secure и SameSite. Первый не даёт скрипту на странице прочитать cookie, второй разрешает передавать её только по HTTPS, третий ограничивает отправку cookie с запросами, которые пришли с чужих сайтов. Саму уязвимость флаги не закрывают, но увести сессию становится заметно сложнее.

Проверить сайт на XSS и настроить заголовки безопасности поможет услуга информационная безопасность сайтов. Исправить уязвимые шаблоны можно в доработке существующего сайта.