Первоначально в статье планировалось рассмотрение инструментов безопасности CRM-системы 1С-Битрикс. Но, в ходе исследования возникли некоторые нюансы, связанные с этой безопасностью. Если верить статистике вопросов пользователей, данная тема является достаточно актуальной.
Разработчики системы заявляют о высокой степени защиты Битрикс, но пользователи сталкиваются с некоторыми проблемами, которые необходимо решить во избежание негативных последствий.
Рассмотрим суть проблемы, а именно - слабые места Bitrix, которые требуют усиленной защиты любого ресурса eCommerce.
Важно! Решения, о которых будет идти речь, будут полезны для Битрикс-разработчиков. Для их внедрения необходимо понимать специфику построения CRM. Если не уверены в собственных силах, рекомендуем обратиться к профильным специалистам. Малейшая неточность в содержании кода может привести к серьезным последствиям и неоправданным расходам.
XSS-атака
Если верить результатам исследования Bitrix Hub, XSS-атаки (кросс-скриптинг) является самой глобальной проблемой, которой подвергаются веб-проекты 1С-Битрикс: Управление сайтом. Речь идет о присутствии в коде интернет-ресурса скриптов, которые предоставляют хакерам доступ к выполнению потенциально вредоносных операций путем использования вызовов переменных.
С чем связана проблема?
Как правило, такой сценарий возникает при отсутствии либо недостаточно надежной фильтрации параметров, считываемых скриптами. Другими словами, браузер принимает пользовательские данные в чистом виде (без предварительной фильтрации).
Какие могут быть последствия?
XSS-атака может повлечь изменение вида страниц HTML незащищенного ресурса в контексте браузера целевого посетителя, утечку данных COOKIE, последующее внедрение в сессию пользователя. То есть, злоумышленник может получить доступ к его учетной записи.
С такой проблемой сталкиваются не только сайты Битрикс, поскольку она связана не так с самой системой, как с низким качеством пользовательского кода. Управление сайтом рекомендуется доверять только проверенным специалистам, поскольку затраты по устранению проблемы и последствий могут быть внушительными.
Как решить?
Защитить ресурс от несанкционированной атаки кибермошенников рекомендуется использовать: htmlspecialchars. Для ограничения тегов с динамическими значениями - двойные кавычки. По необходимости добавлять протокол http при настройке конфигураций для тегов href/src.
Цели кросс-скриптинга
Этот метод позволяет хакеру получить доступ к cookies пользователя при помощи интегрированного скрипта для отбора нужных данных. Эти куки используются при последующих атаках и взломах.
Атака не производится на пользователя напрямую. Для этого используются слабые места сайта, который содержит вредоносный JavaScript. В браузере он замаскирован под органичную часть веб-ресурса.
XSS-взлом не несет прямой опасности для сервера, но если злоумышленник получит администраторские cookies, он без труда получит доступ к административной части.
Искать уязвимость нужно в формах связи сайта. О наличии потенциальной угрозы достаточно ввести в форму следующий запрос:
<script>alert("cookie: "+document.cookie)</script>
Примечательно, что базовая установка 1С-Битрикс с готовыми решениями исключает вероятность возникновения подобной проблемы. Как правило, она появляется вследствие доработок и внедрения дополнительных функциональных возможностей, если при написании кода не соблюдены стандарты Bitrix и правила безопасности.
Эту же строку можно внести как GET-параметр для страниц, генерирующих их (например, на страницах пагинации каталогов либо в фильтрах онлайн магазинов).
http(s)://{ваш_домен}/catalog?p=2 (вместо цифры 2)
Если страница содержит уязвимость, скрипт будет выполнен.
Чтобы обеспечить защиту о таких факторов, необходимо правильно настроить фильтры для входящей и исходящей информации по критериям: способ установки экрана для символов и преобразование специальных символов в формат HTML. Для работы с php предусмотрены специальные функции: htmlspecialchars()/htmlentities()/strip_tags().
Приведем несколько примеров:
$name = htmlspecialchars($_POST['name'], ENT_QUOTES);
$name = strip_tags($_POST['name']).
При управлении Битриксом можно также использовать метод CDatabase::ForSql.
Например:
$name = CDatabase::ForSql($_POST['name'])
Кодировка страниц должна быть указана четко:
Header("Content-Type: text/html; charset=utf-8")
Еще один способ решения: установка запрета на передачу кавычек и скобок через формы (эти символы нужно внести в черный список). Но такое действие может привести к блокировке реальных запросов, если в них содержатся запрещенные знаки.
С этой уязвимостью сталкиваются пользователи любой CMS. Она не является типичной именно для Bitrix.
Здесь стоит добавить список других распространенных проблем, характерных для любой системы:
- получение к данным методом подбора;
- логические несоответствия в содержании кода;
- осуществление системных команд;
- исправление имени файла;
- инъекции SQL;
- подделывание запросов CSRF;
- фишинг и др.
Перенаправления: click.php/rk.php/redirect.php
С проблемой открытых перенаправлений сталкиваются многие пользователи Bitrix. На официальном форуме разработчиков данная тема начала активно обговариваться еще в 2014 году, но не теряет актуальности и сейчас.
В чем суть уязвимости?
Хостинг-провайдер присылает сообщение, в котором указано о значительном повышении нагрузки на MySQL.
Такая проблема возникла вследствие большого количества запросов (30,000 за 4 дня для одного пользователя). Запросы выглядели так:
/bitrix/rk.php?=goto=http...
За goto чаще всего следовали подозрительные сайты.
Такое же явление фиксировалось в аналитических системах, где ссылки (как внутренние, так и внешние) отображались в виде таких url.
Такая конструкция и есть открытым перенаправлением (open redirect). Он позволяет мошенникам устанавливать произвольную URL-ссылку, чтобы пользователь был перенаправлен на вредоносный ресурс.
Если рассматривать эту уязвимость для Битрикс, ее чаще всего вызывают три системных файла:
Например:
{домен_жертва}/bitrix/rk.php
?id=17&site_id=s1
&event1=banner&event2=click
&goto= {домен_цель}/
Кто это делает и к чему это может привести?
Первая цель – создание трастовых ссылок. Несколько лет назад такой инструмент был на пике популярности для повышения индекса цитирования при продвижении.
Справка: трастовые сайты - это те, которые рассматриваются алгоритмами поисковиков Google и Yandex как доверенные и надежные. Такие сайты имеют высокий рейтинг, поэтому отражаются в ответ на релевантные поисковые запросы в списке первых. Но такое положение часто является результатом искусственной накрутки рейтинга.
Более того, многие оптимизаторы используют стратегию уязвимости в открытую.
Руководства по индексации ссылок, их массовой рассылки находятся в открытом доступе. То есть, применить такую тактику может каждый желающий. Агрессивные оптимизаторы предлагают услуги по увеличению запросов на уязвимом сайте.
Все эти факторы и являются причиной неоправданно высокой нагрузки на сайт.
Приведем наглядный пример:
Это данные за 2017 год, но многие редиректы продолжают успешное функционирование.
Вопросы о редиректах стали активно обсуждаться аудиторией Битрикс только в 2018 году, а причиной этому стала массовость проблемы.
Вторая цель – фишинг. Ссылки, ведущие на сайты злоумышленников, часто встречаются в имейл рассылках, мессенджерах. При переходе на них хакеры получают доступ к контактной информации, платежным данным и т. д.
Еще одна цель – спам, в результате которого падает репутация сайта в поисковиках. Огромное количество ссылок на подозрительные ресурсы рассматривается алгоритмами поисковиков отрицательно. Восстановить позиции сайта после спамерской активности - длительный и трудоемкий процесс, поэтому проблему лучше предупредить.
Как это работает?
Это связано с системными файлами Битрикс, которые формируют статистику по кликам и переходам на рекламные баннеры и ссылки. Использование веб-ресурса как прокладку для подозрительных перенаправлений присутствует в коробочной версии.
Как решить?
Если верить отзывам пользователей, проблема встречается часто. На форуме есть несколько обсуждений, но системное решение пока отсутствует.
Разработчики рекомендуют установить максимальную безопасность в настройках проактивной защиты, настроить проверку заголовков HTTP для редиректов.
Тем не менее, ни один из приведенных путей решения не гарантирует стопроцентной защиты от фишинга. Это же касается и сторонних инструментов. При повторном возникновении уязвимости рекомендуется выполнить удаление системных файлов.
Это решение может показаться нелепым, но оно действительно работает. После этого действия администратор не сможет следить за статистикой кликов по баннерным ссылкам и редиректам.
Файлы rk.php/click.php работают на системном модуле advertising (реклама и баннеры). Если же этот модуль не используется, его можно, и даже нужно удалить. Удаление файлов произойдет автоматически.
На форуме разработчиков есть еще одно решение для файла .htaccess:
Это не универсальный метод решения, но он полезный для тех, кто не пользуется редиректами и указанными файлами.
Есть более узконаправленный код:
Но он также не принимает во внимание click.php файл.
restore.php
Уязвимость обнаружилась в ходе проверки на проникновение. Рассмотрим ее суть вкратце.
Набор открытых портов свидетельствовал об установке виртуальной машины Битрикс на публичный IP.
В ответ на переход по ip_addr:80 браузер открывал страницу исходной настройки системы и ссылку с предложением восстановления копии. После клика по ней запускался модуль restore.php с предложением загрузки резервной копии.
Такой сценарий можно объяснить незавершенной процедурой настройки ресурса и виртуальной системы VMBitrix со стороны администратора. Такая безобидная ошибка может привести к взлому.
restore.php выполняет функцию проверки и загрузки файлов, развертывания резервных копий. Хакер может воспользоваться модулем, чтобы получить доступ не к бекапу, а к файлу phpinfo.php. По результатам анализа стало ясно, что файловая проверка не сработала, а скрипт с компьютера выгрузился в веб-приложение.
Аналогичный сценарий решили повторить в лаборатории при помощи виртуальной машины Битрикс 7.2.
При попытке загрузки скрипта с помощью функции скачивания бекапа с удаленного источника, система запустила проверку.
restore.php содержит соответствующий код:
Все же первое условия удалось обойти. Тест проводили со скриптом cmd.php. В cli были переданы идентифицирующие символы (содержимое cmd.php файла).
Новый файл cmd_boom.php:
echo -e "x1fx8bn$(cat cmd.php)" > cmd_boom.php
Его табличный вид:
После выгрузки файла, его ссылку передали restore.php, после чего началась бар-загрузка. Далее последовало уведомление:
Несмотря на это, файл не удалился из корня, и готов к запуску.
После выбора опции Пропустить, была предпринята повторная попытка. На этот раз появилась опция удаления локальной резервной копии вместе со служебными скриптами. Удаление всех файлов выполнилось после нажатия.
Из домашней директории удаляются скрипты restore.php/bitrixsetup.php, а также файл cmd_boom.php. С файлом нельзя выполнить никаких действий: при не восстановленной резервной копии установить новые невозможно.
Теоретически можно изменить имя файла cmd.php на index.php, либо убрать его в поддиректорию.
Сообщение в техподдержку Bitrix было безрезультатным. Специалисты ответили, что искать слабые места в restore.php бессмысленно, поскольку функция скрипта заключается в загрузке php-файлов на ресурс.
Необходимость завершения установки и настройки вполне логична. Но, проблема является довольно распространенной. По результатам быстрой поверхностной проверки, сайтов с ВМ было более 6 сотен.
Массовость проблемы должна заставить создателей найти пути решения для повышения защиты в рамках выявленного участка. Сейчас пользователям нужно быть на чеку, не размещать ВМ до размещения проекта на сервер. Также важно выполнять регулярную проверку всех общедоступных страниц и ресурсов.
Произвольная регистрация
Уязвимость, которая была выявлена около года назад. В начале 2020 года разработчики начали получать сообщения с информацией о том, что пользователи массово регистрируются, обходят капчу, после чего начинается рассылка спама.
Этот фактор связан с массовым внедрением ботов на сайты Битрикс. Если обратиться к журналу событий, можно посмотреть адрес регистрации: /auth/?register=yes. Дело в том, что на таких ресурсах нет раздела /auth/ млм форма для регистрации отсутствует вообще.
Примечательно, что подобная ситуация фиксировалась на проектах, где регистрации не предусмотрено (лендинги, визитки). Боты внедрялись и на сайты, где процедура регистрации проводится при помощи main.register либо кода на API-Bitrix, написанного вручную с рекапчей, правилами валидации и списком полей для обязательного заполнения.
С чем связана проблема?
Все дело в устаревших компонентах:
- auth.registration;
- auth.authorize;
- auth.forgotpasswd;
- auth.changepasswd.
Они отображаются на страницах со значением true (константа NEED_AUTH):
define("NEED_AUTH", true)
Нюанс состоит в том, что даже при отсутствии установленной константы, устаревшие компоненты срабатывают в ответ на соответствующий запрос (POST). Это значит, что любая страница сайта, даже без формы для регистрации, может получить запрос от пользователя для прохождения регистрации.
Сотрудник Postman составил универсальный запрос для проведения исследования:
Запрос сработал даже на сайтах, где не предусмотрено регистрации, с обходом капчи. То есть, злоумышленники имеют возможность наладить процесс для использования ресурса в своих интересах.
Как решить?
Эту уязвимость можно решить несколькими путями:
1. Если используется самописная регистрация, рекомендуется войти в настройки основного модуля (вкладка Авторизация), снять галочку возле опции самостоятельной регистрации для пользователей. Здесь же установить использование капчи. Это сократит активность ботов. Метод не подойдет для ресурсов с смс регистрацией.
2. Проверять поля новых пользователей после регистрации с помощью инструмента для обработки событий (OnBeforeUserAdd). Можно отказаться от дублирования валидации в коде, в котором возможна процедура регистрации.
3. Установить корректные настройки для компонентов system.auth.
Служба поддержки Битрикс знает о данной проблеме, но разработчики не могут предложить ничего, кроме установки капчи. Возможно, решение проблемы - дело времени. Единственное, что остается - полагаться на собственные силы.
Инструменты для проверки сайта
Если вам необходима качественная проверка скриптов и кодов веб-проекта, обратитесь к нашим специалистам. Мы поможем выявить слабые места, а также определить недочеты в производительности, найти потенциальные ошибки в функционировании инструментов ресурса. Комплексный подход позволит найти решения для оптимизации работы сайта и его дальнейшего процветания.
Примите во внимание: если ваш проект попал в поле зрение злоумышленников, они могут воспользоваться комплексом инструментов для взлома. Чтобы не потерять ценную информацию, не забывайте делать резервное копирование, а также контролируйте качество кодов, особенно самописных.
Подведем итог
Несмотря на множество слабых мест, Битрикс предоставляет возможности для их устранения. Эта CMS обладает всеми необходимыми инструментами для повышения безопасности сайта от хакерских атак. Для серьезных проектов эта система считается наиболее надежной.
Не забывайте о:
- своевременной актуализации CMS (установке последних релизов);
- качестве разработок и доработок (коды и скрипты должны быть написаны в соответствии с канонами CMS).
В базовой системе CMS риски практически отсутствуют. Большинство проблем связаны с неквалифицированным вмешательством, неправильным подходом к программированию страниц, опций, шаблонов.
Вопросы безопасности в веб-пространстве сейчас особенно актуальны. Чем выше популярность выбранной CMS, тем выше риски хакерских атак. От этого никто не застрахован.
Рекомендации, которые помогут обеспечить защиту вашего проекта:
- своевременное обновление CMS (устаревшие компоненты могут нанести серьезный удар);
- сотрудничество с квалифицированными специалистами (ошибки, связанные с человеческим фактором, могут повысить уязвимость ресурса);
- регулярное создание бекапов (резервное копирование поможет предотвратить утери важной информации);
- своевременное выявление и устранение выявленных проблем;
- периодичная проверка сайта на предмет защиты (не реже одного раза в три месяца).
Остались вопросы? Мы поможем найти ответ!