Наиболее массовая уязвимость для хакеров в 1С Битрикс

В этой статье мы коснемся самого распространенного способа хакинга сайта на 1С Битрикс. В нашей работе по поддержке веб-проектов на Битрикс мы видим не только последствия хакерских действий, но и успешно отражаем атаки на проекты клиентов.

Перейдем к технической части.

Как появляются проблемы безопасности?

Традиционно, сайты 1С Битрикс – это не те мебельные сайты по-умолчанию, которые запускаются после установки дистрибутива, а что-то более сложное. Веб-студии продают лицензии Битрикс, чтобы заработать на дополнительных доработках, дизайне, программировании и так далее. В погоне за длинным рублем клиента, о вопросах безопасности и не вспоминают. Когда веб-проект пилят по очереди фрилансеры-разработчики друг за другом, которых привлекает веб-студия, то качество кода, стабильность и безопасностью отходят на второй, третий, четвертый план. Главное – это кэш, а с поддержкой – «пусть хостер заморачивается». Такая постановка вопроса содержит в себе букет будущих проблем, расцветающий сразу после окончания гарантийных обязательств веб-студии или фрилансера. Зачастую попытки найти студию, запустившую сайт у клиента не получается совсем. Красивые слова, показ распечатанных дипломов и сертификатов 1С Битрикс начисто усыпляют бдительность клиента, а проблему он начинает видеть только в момент, когда сайт хакнули и хостинг компания заблокировала его по причине нарушения условия пользования хостингом.

Кодинг часто необходим для доработки функционала или написания своих модулей и скриптов для решения узкого круга задач клиента. Когда веб-студия экономит на разработчиках (кодерах), не говоря уже о тим-лидере, то получается, что получается. Плохого качества код имеет массу язвимостей, а общая монстрообразная структура продукта 1С Битрикс не способствует легкости решения задач безопасности.

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

Самая массовая проблема безопасности в Битриксе

Топ уязвимостей Битрикса возглавляет кросс-скриптинг, т.е. XSS-атаки, когда в коде веб-проекта есть скрипты, дающие возможность хакерам успешно использовать вызовы переменных и выполнять вредоносные операции. Это обусловлено отсутствием или недостаточно надежной фильтрацией параметров, передаваемыми скриптам. Обычно это связанно с авторизацией и регистрацией пользователей на сайте или в интернет магазине и операциями ввода-вывода с БД (MySQL).

Существует два типа XSS уязвимостей — пассивная и активная. Они различаются тем, что при пассивной в фишинговых письмах подставляют ссылку, чтобы потом жертва выполнила POST/GET запрос, а вот активная направлена на то, чтобы получить доступ к данным сайта.

При активной XSS атаке хакеру достаточно внедрить код в базу или какой-нибудь файл на сервере. Таким образом, все посетители сайта автоматически становятся жертвами. Он может быть интегрирован, например, с помощью внедрения SQL-кода (SQL Injection). Поэтому, не стоит доверять данным, хранящимся в БД, даже если при вставке они были обработаны.

Что такое кросс-скриптинг и зачем он нужен?

Основная цель межсайтового скриптинга – кража cookies пользователей при помощи встроенного на сервере скрипта с дальнейшей выборкой необходимых данных и использованием их для последующих атак и взломов. Злоумышленник осуществляет атаку пользователей не напрямую, а с использованием уязвимостей веб-сайта, который посещают жертвы, и внедряет специальный JavaScript. В браузере у пользователей этот код отображается как единая часть сайта. При этом посещаемый ресурс по факту является соучастником XSS-атаки.

Если сравнивать с SQL-инъекциями, то XSS безопасен для сервера, но несет угрозу для пользователей зараженного ресурса или страницы. Однако, если к злоумышленнику попадут cookies администратора, можно получить доступ к панели управления сайтом и его содержимому.

Запуск вредоносного кода JavaScript возможен только в браузере жертвы, поэтому сайт, на который зайдет пользователь, должен иметь уязвимость к XSS. Для совершения атаки злоумышленник изначально проверяет ресурсы на наличие уязвимостей через XSS, используя автоматизированные скрипты или ручной режим поиска. Обычно это стандартные формы, которые могут отправлять и принимать запросы (комментарии, поиск, обратная связь).

Проводится полный сбор страниц с формами ввода, и каждая сканируется на наличие уязвимостей. Например, у нас есть страница «Поиск» на сайте. Для проверки уязвимости XSS достаточно ввести запрос:

<script>alert("cookie: "+document.cookie)</script>

Если на экране появится уведомление, значит вы обнаружили брешь в безопасности. В противном случае система отобразит вам страницу с результатами поиска. Битрикс работает над этой проблемой и при установке из коробки без каких-либо доработок этой CMS вы будете относительно защищены. Но, если вы начинаете расширение функционала за счет установки сторонних модулей и плагинов, то вероятность иметь уязвимость кросс-скриптинга сильно возрастают.

Еще один возможный вариант уязвимости – использование адресов под страницы, которые обрабатывают любые GET-запросы. Например, у нас есть страница сайта с каталогом, задающая страницу параметром: http://www.onewebsite.ru/catalog?p=8

В адресной строке вместо параметра (в нашем случае это «8») добавляем скрипт:

<script>alert("cookie: "+document.cookie)</script>

в результате чего получаем ссылку уже такого вида:

http://www.onewebsite.ru/catalog?p= "><script>alert("cookie: "+document.cookie)</script>

Таким образом, если страница имеет уязвимость перед XSS атакой, то мы увидим, что наш скрипт выполняется.

Далее уже дело техники подобрать необходимый для выполнения код и выполнить его, особенно интересно становится при выполнении кода для записи или чтения в/из базы данных. Воспользовавшись XSS можно собрать из базы всех ваших пользователей, их приватную информацию, пароли. А администратор – это такой же пользователь, таким образом, следующие шаги, которые делают хакеры, весьма очевидны.

Зачастую к нам обращаются клиенты, которые не только потеряли всю пользовательскую информацию в своих интернет-магазинах на Битрикс, но и стали жертвами мошенников, использую одни и те же пары логин-пароль для авторизации в платежных системах.

Безопасность начинается с первой строки кода и не заканчивается никогда, в противном случае, халатное отношение грозит огромными финансовыми обременениями и потерей бизнеса.

Как найти потенциальную уязвимость в моем Битриксе?

Для поиска уязвимостей на сайтах существует сканеры. Ими можно периодически проверять ваш веб-проект. Это особенно актуально для проектов на Битрикс.

Чтобы выполнить быструю проверку сайта на наличие уязвимостей XSS можно воспользоваться специализированными сервисами, которые в автоматическом режиме проведут сканирование страницы. В обязательном порядке нужно проверять все URL, где возможна отправка данных со стороны пользователя (формы комментариев, обратная связь, поиск).

В качестве примера можете использовать xss-scanner.com, но не стоит ограничиваться лишь одним инструментом. Их есть значительное множество, некоторые имеют бесплатные и платные расширенные версии.

Важно отметить, что подобные сервисы не дают полной гарантии успеха, поэтому рекомендуем проверять найденные страницы в ручном режиме и обязательно исключить все опасные спецсимволы, заменив их безопасными. Речь идет о скобках < и >, в которых и прописываются все зарезервированные языком html-запросы и теги при обращении к скрипту. Именно этим и пользуются хакеры, поэтому ваша задача исключить их с помощью системы фильтров. Это все проверяется и исправляется в коде программистами.

Защита от уязвимости Битрикса

Наш технический отдел дает некоторые базовые рекомендации по предотвращению взломов 1С Битрикс с использованием XSS-атак:

1. Главное! Если на вашем сайте включена обработка данных из форм, то должно строго выполняться кодирование всех запросов.

2. Иногда кодирование применить проблематично. Что делать? Окей, заменяйте его валидацией ввода, а лучше даже дополняйте (дополнительно к кодированию).

3. Обрабатывать пользовательские данные в коде можно ТОЛЬКО на стороне клиента и никогда не на стороне сервера.

4. Регулярно обновляйте программное обеспечение Битрикс и всех установленных модулей и плагинов. После обновления проводите аудит на уязвимость XSS.

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

Comments are closed.