XSS-атаки: определение, цели, защита от XSS-атак
- Цели XSS-атак
- Типы XSS-уязвимостей
- Активная и пассивная XSS-уязвимости
- Методика проведения XSS-атак
- Смягчение последствий и защита от XSS-атак
Цели XSS-атак
С какой целью может быть предпринята попытка атаки через XSS? В большинстве случаев — чтобы изменить настройки, украсть куки-файлы, внедрить блоки с ложной рекламой, заставить сервисы работать некорректно.Самая частая цель атакующего – это сookies, в которых могут оказаться ценные данные вроде пользовательских логинов, паролей, хэша. Кроме того, опасность представляют кражи открытых сессий на важных сайтах, поэтому даже если заходите на них с собственного компьютера из дома, всё равно по завершении работы обязательно нажимайте «выход». Впрочем, во избежание инцидентов сайты в большинстве своем предусматривают автоматическое закрытие сессии по истечении определенного времени. Но ограничения XMLHttpRequest на доменах от подобных атак защитить не могут.
Еще одна разновидность XSS-атак – воровство данных из заполняемых форм. Злоумышленники запускают на нужной им странице onsubmit (отслеживание событий) и получают к себе на сервер интересующую их информацию. Это что-то вроде фишинговых атак, только без создания фэйковых страниц. Всё воруется с нормального, хорошо себя зарекомендовавшего сайта.
В популярных соцсетях вроде «ВКонтакте», Twitter и прочих практикуются атаки с запуском XSS-червей. Это когда группа людей получает уязвимые ссылки, в которые заранее внедрены ложные скрипты, способные от имени другого человека делать рассылки. Параллельно личные данные и фото со страниц пользователей могут сливаться на сторонние ресурсы.
Типы XSS-уязвимостей
Различают три вида XSS-уязвимостей: с постоянным XSS (его еще называют хранимым), непостоянным (отраженным) XSS и с XSS в DOM-модели.- Постоянный XSS
То есть, если разработчики при сохранении входящей информации в базу данных сервера (или в файлы) не обеспечивают надлежащую фильтрацию и потом выдают эти данные в ответ на запросы пользователей, то образуется хранимый XSS.
- Непостоянный XSS
- XSS в DOM-модели
То есть, XSS создается прямо внутри JavaScript. В качестве примера такой XSS-атаки можно привести схему, по которой информация из URL добывается посредством location.* DOM либо с помощью XMLHttpRequest запроса. А затем на основе полученных (причем неотфильтрованных) данных формируются динамические HTML объекты.
Активная и пассивная XSS-уязвимости
Наибольшую опасность представляют активные уязвимости. После внедрения на сервер (в базу данных или в какие-то файлы) вредоносного SQL-кода зараженный сайт может представлять угрозу для любого посетителя. «Заразными» могут оказаться даже данные, пропущенные через вашу систему защиты, потому что уязвленные объекты имеют хорошую способность к интеграции.Что касается пассивной XSS-атаки, то здесь злоумышленникам приходится что-то придумывать, чтобы посредством обманных ссылок перевести вас на фейковую страницу или заставить перейти на нужный сайт. Как вариант – отслеживают, какие сайты вы посещаете чаще всего, а затем присылают письма от имени администрации этих ресурсов с целью якобы проверки настроек. Мошенники активно действуют и через форумы посредством постов либо рассылок.
Различают пассивные XSS-уязвимости с POST и GET-параметрами. Первые внедряются с применением тех или иных хитростей, а вторые – посредством кодирования или изменения (через добавление новых символов) url-строки.
Методика проведения XSS-атак
Далее о том, как именно работает XSS-атака. И начинать тут следует с определения всех её участников. Обычно агентов трое: мошенник, жертва и сайт.
Сайт выдает HTML-страницы в ответ на пользовательский запрос. Жертва – это тот самый пользователь, введший запрос в строку браузера. Злоумышленник – другой пользователь, подготовивший на сайте XSS-уязвимость, с помощью которой собирается обмануть жертву. У мошенника есть еще собственный контролируемый им сервер, созданный специально для кражи чужих ценных данных.
XSS-атака проводится следующим образом:
- Задействовав одну из форм сайта, мошенник внедряет в его базу данных вредоносную строку.
- Жертва делает поисковой запрос на страницу ресурса.
- В ответ в базе данных берется эта вредоносная строка и выдается пользователю как результат его запроса.
- Из получившегося ответа браузер жертвы формирует вредоносный скрипт, и на мошенницкий сервер идут куки-файлы обманутого пользователя.
Злоумышленник собирает все страницы с формами ввода, и они сканируются на предмет обнаружения уязвимостей. К примеру, наличие XSS-уязвимости на странице «Поиск» проверяется введением запроса <script>alert("cookie: "+document.cookie)</script>.
Выведенное на экран уведомление говорит о том, найдена опасность. Если же всё в порядке, то система выдаст результаты поиска. С современными популярными CMS подобных проблем уже не возникает, однако сторонние разработчики то и дело придумывают новые модули, дающие больше функциональных возможностей для запуска XSS-атак. Особенно это касается Joomla, DLE, Bitrix, Wordpress. Браузер, наиболее часто используемый для проверки XSS-уязвимостей — Internet Explorer.
Как еще можно искать проблемные места в безопасности? Например, с помощью страниц, обрабатывающих GET-запросы. Пусть, например, у вас есть вот такая ссылка: https://site.ru/catalog?p=8. В строке поиска нужно заменить идентификатор (8) скриптом – "><script>alert("cookie: "+document.cookie)</script>. Тогда ссылка получится уже другой: https://site.ru/catalog?p="><script>alert("cookie: "+document.cookie)</script>.
При обнаружении на странице уязвимоcти XSS система выдаст такое же уведомление, как было описано в предыдущем примере.
Вообще существует масса самых разнообразных скриптов и запросов, способных обнаружить на сайте опасную «брешь». Ресурс можно считать надежно защищенным, если ни одна из подобных проверочных атак не проходит.
Злоумышленник, обнаружив слабое место, запускает на страницу вредоносный код и возвращает его снова в пользовательский браузер, где этот код и начинает работать. Такое случается, если разработчик приложения слишком доверяет любым входным данным либо они недостаточно хорошо фильтруются.
Смягчение последствий и защита от XSS-атак
Как бороться с попытками атаки через XSS? Проверять и чистить входные данные на наличие кода, экранировать их (опять же, если в них точно нет вредоносного кода), менять структуру приложения так, чтобы возможность загрузки кода допускалась исключительно из обозначенных, надежных мест.Санитизация кода
Это, собственно, и есть исключение из кода любых подозрительных элементов. Вы можете и сами написать такую функцю-клинер, но для продакшена лучше воспользоваться готовыми надежными вариантами вроде специальной библиотеки-санитайзера DOM Purify и ей подобных. Они обнаруживают опасные коды и устраняют их.
Экранирование контента
Браузер может воспринимать некие спецсимволы как безопасные, посчитав, что это теги. Такую символику необходимо заменить. Например, запись <script>alert('XSS!');</script> после экранирования будет выглядеть так <script>alert('XSS!');</script>. Данный вариант для браузера уже не выглядит как тег либо скрипт.
В JavaScript экранирование контента осуществляется с помощью:
- encodeURI (применяется для кодировки URL);
- encodeURIComponent (применяется для кодировки части URL-flhtcf, к примеру, searchQuery);
- специальных библиотек (применяются для замены спецсимволов вроде <, >, '," и прочих).
Content Security Policy
Говоря простым языком, CSP – это «белый» список разрешенных к использованию инструментов. Именно данный подход, кстати, считается самым эффективным и надежным. Все типы источников в CSP распределены по отдельным спискам:
- script-src — тут собраны места, из которых можно брать скрипты;
- style-src — список допустимых стилей;
- img-src — места, откуда можно подгружать изображения.
Как инструмент защиты Content Security Policy работает очень мощно, причем не особо ограничивая свободу деятельности, что обеспечивается наличием широкого спектра настроек.
Вот еще несколько рекомендаций к тому, как бороться у себя на сайте с XSS-атаками:
- Непременно применяйте кодирование пользовательских вводов (если они подключены на вашем ресурсе).
- В случаях, когда нет возможности кодировать или это кажется неуместным, применяйте замену или валидацию.
- В целях безопасности данные кода должны проходить обработку и на стороне web-сервера, и на пользовательском, то есть, клиентском участке.
- Если вы работаете с популярными системами управления вроде Wordpress, Bitrix, Joomla, то обязательно регулярно запускайте обновления и для движка, и для всех дополнительных подключенных плагинов и модулей. На самих системах обычно по умолчанию есть защита от XSS-атак, чего нельзя сказать о взятых из сомнительных источников плагинах (и тогда подбор ключа к ним – не проблема для злоумышленников).

Опасность представляет еще и межсайтовый скрининг. Для сервера XSS-атаки не представляют опасности, они угрожают тем, кто заходит на зараженную страницу или сайт. Но если мошенники «захватят», например, администраторские cookies, то получат полную возможность управлять на своё усмотрение атакованным ресурсом.