Bitrix Hub
Битрикс-Хостинг
Новости
Контакты
Наиболее массовая уязвимость для хакеров в 1С Битрикс
В этой статье мы коснемся самого распространенного способа хакинга сайта на 1С Битрикс. В нашей работе по поддержке веб-проектов на Битрикс мы видим не только последствия хакерских действий, но и успешно отражаем атаки на проекты клиентов.
Перейдем к технической части.
Как появляются проблемы безопасности?
Традиционно, сайты 1С Битрикс – это не те мебельные сайты по-умолчанию, которые запускаются после установки дистрибутива, а что-то более сложное. Веб-студии продают лицензии Битрикс, чтобы заработать на дополнительных доработках, дизайне, программировании и так далее. В погоне за длинным рублем клиента, о вопросах безопасности и не вспоминают. Когда веб-проект пилят по очереди фрилансеры-разработчики друг за другом, которых привлекает веб-студия, то качество кода, стабильность и безопасностью отходят на второй, третий, четвертый план. Главное – это кэш, а с поддержкой – «пусть хостер заморачивается». Такая постановка вопроса содержит в себе букет будущих проблем, расцветающий сразу после окончания гарантийных обязательств веб-студии или фрилансера. Зачастую попытки найти студию, запустившую сайт у клиента не получается совсем. Красивые слова, показ распечатанных дипломов и сертификатов 1С Битрикс начисто усыпляют бдительность клиента, а проблему он начинает видеть только в момент, когда сайт хакнули и хостинг компания заблокировала его по причине нарушения условия пользования хостингом.
Кодинг часто необходим для доработки функционала или написания своих модулей и скриптов для решения узкого круга задач клиента. Когда веб-студия экономит на разработчиках (кодерах), не говоря уже о тим-лидере, то получается, что получается. Плохого качества код имеет массу язвимостей, а общая монстрообразная структура продукта 1С Битрикс не способствует легкости решения задач безопасности.
Вернувшись назад, к моменту создания сайта или интернет-магазина, проакцентируем, что наиболее важными вопросами к разработчикам всегда являются моменты стабильности и безопасности. Для ответственных проектов в рамках тестирования проводится этап поиска уязвимостей, а также аудит безопасности.
Самая массовая проблема безопасности в Битриксе
Топ уязвимостей Битрикса возглавляет кросс-скриптинг, т.е. XSS-атаки, когда в коде веб-проекта есть скрипты, дающие возможность хакерам успешно использовать вызовы переменных и выполнять вредоносные операции. Это обусловлено отсутствием или недостаточно надежной фильтрацией параметров, передаваемыми скриптам. Обычно это связанно с авторизацией и регистрацией пользователей на сайте или в интернет магазине и операциями ввода-вывода с БД (MySQL).
Существует два типа XSS уязвимостей — пассивная и активная. Они различаются тем, что при пассивной в фишинговых письмах подставляют ссылку, чтобы потом жертва выполнила POST/GET запрос, а вот активная направлена на то, чтобы получить доступ к данным сайта.
При активной XSS атаке хакеру достаточно внедрить код в базу или какой-нибудь файл на сервере. Таким образом, все посетители сайта автоматически становятся жертвами. Он может быть интегрирован, например, с помощью внедрения SQL-кода (SQL Injection). Поэтому, не стоит доверять данным, хранящимся в БД, даже если при вставке они были обработаны.
Что такое кросс-скриптинг и зачем он нужен?
Основная цель межсайтового скриптинга – кража cookies пользователей при помощи встроенного на сервере скрипта с дальнейшей выборкой необходимых данных и использованием их для последующих атак и взломов. Злоумышленник осуществляет атаку пользователей не напрямую, а с использованием уязвимостей веб-сайта, который посещают жертвы, и внедряет специальный JavaScript. В браузере у пользователей этот код отображается как единая часть сайта. При этом посещаемый ресурс по факту является соучастником XSS-атаки.
Если сравнивать с SQL-инъекциями, то XSS безопасен для сервера, но несет угрозу для пользователей зараженного ресурса или страницы. Однако, если к злоумышленнику попадут cookies администратора, можно получить доступ к панели управления сайтом и его содержимому.
Запуск вредоносного кода JavaScript возможен только в браузере жертвы, поэтому сайт, на который зайдет пользователь, должен иметь уязвимость к XSS. Для совершения атаки злоумышленник изначально проверяет ресурсы на наличие уязвимостей через XSS, используя автоматизированные скрипты или ручной режим поиска. Обычно это стандартные формы, которые могут отправлять и принимать запросы (комментарии, поиск, обратная связь).
Проводится полный сбор страниц с формами ввода, и каждая сканируется на наличие уязвимостей. Например, у нас есть страница «Поиск» на сайте. Для проверки уязвимости XSS достаточно ввести запрос:
Если на экране появится уведомление, значит вы обнаружили брешь в безопасности. В противном случае система отобразит вам страницу с результатами поиска. Битрикс работает над этой проблемой и при установке из коробки без каких-либо доработок этой CMS вы будете относительно защищены. Но, если вы начинаете расширение функционала за счет установки сторонних модулей и плагинов, то вероятность иметь уязвимость кросс-скриптинга сильно возрастают.
Еще один возможный вариант уязвимости – использование адресов под страницы, которые обрабатывают любые GET-запросы. Например, у нас есть страница сайта с каталогом, задающая страницу параметром: http://www.onewebsite.ru/catalog?p=8
В адресной строке вместо параметра (в нашем случае это «8») добавляем скрипт:
в результате чего получаем ссылку уже такого вида:
Таким образом, если страница имеет уязвимость перед XSS атакой, то мы увидим, что наш скрипт выполняется.
Далее уже дело техники подобрать необходимый для выполнения код и выполнить его, особенно интересно становится при выполнении кода для записи или чтения в/из базы данных. Воспользовавшись XSS можно собрать из базы всех ваших пользователей, их приватную информацию, пароли. А администратор – это такой же пользователь, таким образом, следующие шаги, которые делают хакеры, весьма очевидны.
Зачастую к нам обращаются клиенты, которые не только потеряли всю пользовательскую информацию в своих интернет-магазинах на Битрикс, но и стали жертвами мошенников, использую одни и те же пары логин-пароль для авторизации в платежных системах.
Безопасность начинается с первой строки кода и не заканчивается никогда, в противном случае, халатное отношение грозит огромными финансовыми обременениями и потерей бизнеса.
Как найти потенциальную уязвимость в моем Битриксе?
Для поиска уязвимостей на сайтах существует сканеры. Ими можно периодически проверять ваш веб-проект. Это особенно актуально для проектов на Битрикс.
Чтобы выполнить быструю проверку сайта на наличие уязвимостей XSS можно воспользоваться специализированными сервисами, которые в автоматическом режиме проведут сканирование страницы. В обязательном порядке нужно проверять все URL, где возможна отправка данных со стороны пользователя (формы комментариев, обратная связь, поиск).
В качестве примера можете использовать xss-scanner.com, но не стоит ограничиваться лишь одним инструментом. Их есть значительное множество, некоторые имеют бесплатные и платные расширенные версии.
Защита от уязвимости Битрикса
Наш технический отдел дает некоторые базовые рекомендации по предотвращению взломов 1С Битрикс с использованием XSS-атак:
1. Главное! Если на вашем сайте включена обработка данных из форм, то должно строго выполняться кодирование всех запросов.
2. Иногда кодирование применить проблематично. Что делать? Окей, заменяйте его валидацией ввода, а лучше даже дополняйте (дополнительно к кодированию).
3. Обрабатывать пользовательские данные в коде можно ТОЛЬКО на стороне клиента и никогда не на стороне сервера.
4. Регулярно обновляйте программное обеспечение Битрикс и всех установленных модулей и плагинов. После обновления проводите аудит на уязвимость XSS.
5. Внимательно относитесь к устанавливаемым плагинам и модулям Битрикс, особенно, скачанным со сторонних сайтов. Помните, что серые плагины из непроверенных источников могут содержать уязвимости преднамеренно зашитые в код, либо дыре, оставленной по невнимательности.
XSS атака
XSS (межсайтовый скриптинг) – одна из разновидностей атак на веб-системы, которая подразумевает внедрение вредоносного кода на определенную страницу сайта и взаимодействие этого кода с удаленным сервером злоумышленников при открытии страницы пользователем.
Термин с английского расшифровывается как Cross-Site Scripting, но при этом получил аббревиатуру XSS, чтобы не было путаницы с CSS (каскадные таблицы стилей).
Как работает межсайтовый скриптинг
Основная цель межсайтового скриптинга – кража cookies пользователей при помощи встроенного на сервере скрипта с дальнейшей выборкой необходимых данных и использованием их для последующих атак и взломов. Злоумышленник осуществляет атаку пользователей не напрямую, а с использованием уязвимостей веб-сайта, который посещают жертвы, и внедряет специальный JavaScript. В браузере у пользователей этот код отображается как единая часть сайта. При этом посещаемый ресурс по факту является соучастником XSS-атаки.
Если сравнивать с SQL-инъекциями, то XSS безопасен для сервера, но несет угрозу для пользователей зараженного ресурса или страницы. Однако, если к злоумышленнику попадут cookies администратора, можно получить доступ к панели управления сайтом и его содержимому.
Методика атаки через XSS
Запуск вредоносного кода JavaScript возможен только в браузере жертвы, поэтому сайт, на который зайдет пользователь, должен иметь уязвимость к XSS. Для совершения атаки злоумышленник изначально проверяет ресурсы на наличие уязвимостей через XSS, используя автоматизированные скрипты или ручной режим поиска. Обычно это стандартные формы, которые могут отправлять и принимать запросы (комментарии, поиск, обратная связь).
Проводится полный сбор страниц с формами ввода, и каждая сканируется на наличие уязвимостей. Например, у нас есть страница «Поиск» на сайте. Для проверки уязвимости XSS достаточно ввести запрос:
Если на экране появится уведомление, значит вы обнаружили брешь в безопасности. В противном случае система отобразит вам страницу с результатами поиска. Основные популярные CMS уже давно лишились подобных проблем, но из-за возможности расширения функционала за счет модулей и плагинов, создаваемых сторонними разработчиками, шансы на использование уязвимостей XSS возрастают в разы, особенно в Joomla, DLE, Bitrix, WordPress. Чаще всего XSS-уязвимости проверяются в браузере Internet Explorer.
Еще один возможный вариант поиска – использование страниц, которые обрабатывают GET-запросы. Допустим, у нас есть ссылка вида: http://site.ru/catalog?p=8
В адресной строке вместо идентификатора (8) добавляем скрипт – «>, в результате чего получаем ссылку такого вида: http://site.ru/catalog?p=»>.
Если страница имеет уязвимости XSS, на экране появится уведомление такого же плана, как и в первом случае.
Для поиска «дыр» на сайте существует огромное количество готовых скриптов и запросов, и если ни один из них не подходит, значит ресурс надежно защищен от подобных атак.
Общая классификация XSS
Четкой классификации для межсайтового скриптинга не существует, но экспертами по всему миру выделено три основных типа.
Хранимые XSS (постоянные). Один из самых опасных типов уязвимостей, так как позволяет злоумышленнику получить доступ к серверу и уже с него управлять вредоносным кодом (удалять, модифицировать). Каждый раз при обращении к сайту выполняется заранее загруженный код, работающий в автоматическом режиме. В основном таким уязвимостям подвержены форумы, порталы, блоги, где присутствует возможность комментирования в HTML без ограничений. Вредоносные скрипты с легкостью могут быть встроены как в текст, так и в картинки, рисунки.
Отраженные XSS (непостоянные). В этом случае вредоносная строчка выступает в роли запроса жертвы к зараженному веб-сайту. Работает этот принцип по следующей схеме:
DOM-модели. В этом варианте возможно использование как хранимых XSS, так и отраженных. Суть заключается в следующем:
Виды XSS по способу взаимодействия
Так как основная цель злоумышленника – запустить вредоносный скрипт на компьютере жертвы, существует еще и два основных типа XSS-атак по способу взаимодействия.
Пассивные. От жертвы требуется определенное действие, чтобы вызвать обработчик событий и запустить вредоносный скрипт в установленной форме. Для этого используется социальная инженерия, например отправка электронного письма с призывом перейти по ссылке и нажать на определенную область на сайте. Как только пользователь наведет на нужный объект и кликнет по нему, запустится вредоносный скрипт. Если же жертва бездействует, код не будет активирован.
Активные. Злоумышленнику не нужно заманивать жертву по специальным ссылкам, так как код встраивается в базах данных или в каком-нибудь исполняемом файле на сервере. От пользователя не требуется никакой активности. У форм ввода, как правило, установлен специальный обработчик событий, автоматически активирующийся при попадании на эту страничку. В итоге все пользователи, перешедшие по этой ссылке, станут жертвами злоумышленника.
Как проверить сайт на наличие уязвимостей XSS и защитить его
Для быстрой проверки сайта на наличие уязвимостей XSS можно воспользоваться специализированными сервисами, которые в автоматическом режиме проведут сканирование страницы. В обязательном порядке нужно проверять все URL, где возможна отправка данных со стороны пользователя (формы комментариев, обратная связь, поиск). В качестве примера можете использовать http://xss-scanner.com, но не стоит ограничиваться лишь одним инструментом.
Например, для быстрой фильтрации и автоматической замены спецсимволов вы можете использовать следующий код на сайте:
Несколько советов по предотвращению использования XSS на вашем сайте:
Топ-4 актуальных уязвимости 1С-Битрикс
Хотели написать статью об инструментах безопасности «1С-Битрикс», но постепенно «зарылись» в проблемах с этой самой безопасностью. И как оказалось, тема эта весьма актуальная. Несмотря на общепризнанный высокий уровень защищенности «Битрикс» и сегодня находятся «прорехи», которые могут причинить серьезные неприятности.
Поэтому предлагаем подробнее остановиться именно на постановке проблемы. Тем более, что именно наличие уязвимостей, как нельзя лучше говорит о необходимости высокой защиты вашего eCommerce-ресурса. А к анализу методов достижения высокого уровня безопасности разработчиками «1С-Битрикс» вернемся позже.
Не рекомендуется внедрять представленные в статье меры, если вы не являетесь Битрикс-разработчиком и не понимаете, что делаете. Все рекомендации собраны в сети, и мы не даем гарантию, что код корректно сработает на вашем сайте, не навредив. Доверьте безопасность своего проекта профессионалам.
Содержание:
XSS-атака
Под данным Bitrix Hub кросс-скриптинг (межсайтовый скриптинг, XSS-атаки) возглавляет топ уязвимостей проектов на «1С-Битрикс: Управление сайтом». Проблема актуальна, когда в коде интернет-проекта присутствуют скрипты, предоставляющие злоумышленнику возможность использовать вызовы переменных и выполнять вредоносные операции. Главная причина такого положения вещей – отсутствие или недостаточно надежная фильтрация параметров, передаваемых скриптам. Проще говоря, проблема появляется, когда данные, принимаемые от пользователя, выводятся в браузер без необходимой фильтрации.
Специалист по информационной безопасности компании «1С-Битрикс» М. Низамутдинов разъясняет: XSS-атака может быть использована для изменения вида HTML-страниц уязвимого ресурса в контексте браузера целевого пользователя, похищения COOKIE данных браузера целевого пользователя, с последующим внедрением в его сессию, под его учетной записью.
Стоит также отметить, что эта уязвимость не является специфической проблемой для «1С-Битрикс», а возникает ввиду некачественного пользовательского кода. И чем больше фрилансеров, студий и штатных программистов работают с сайтом, тем выше вероятность стать обладателем подобной «дыры».
В качестве средства защиты от подобных посягательств представитель компании-разработчика рекомендует: «Использовать htmlspecialchars. Параметры тегов с динамическими значениями ограничивать двойными кавычками. Принудительно добавлять протокол (http), где это необходимо, для значений параметров тегов, таких как href или src».
Ты опытный PHP-программист и работаешь с 1С-Битрикс?
Зачем используется кросс-скриптинг
Основная цель – кража cookies пользователей с помощью встроенного скрипта для выборки необходимых данных и использованием их для последующих атак и взломов. Атака осуществляется не напрямую на пользователя, а через уязвимости веб-ресурса, на который внедрен вредоносный JavaScript. Кстати, в браузере он виден, как органичная часть сайта.
Несмотря на то, что XSS-атака напрямую не несет угрозу серверу, если к злоумышленнику попадут cookies администратора, он сможет получить доступ к административной части сайта.
Уязвимость ищется, как правило, в формах связи на сайте. Чтобы понять, что она есть, достаточно передать в форму запрос вида:
Стоит напомнить, что при базовой установке «1С-Битрикс» и готовых решений, вы не столкнетесь с подобной проблемой. Она может появиться лишь ввиду доработок и внедрения дополнительного функционала при условии, что код написан не по канонам «Битрикс» и без соблюдения правил безопасности.
Альтернативно ту же строчку скрипта можно добавить в качестве GET-параметра на страницах, генерирующие таковые. Например, в каталоге, на страницах пагинации или в фильтрах интернет-магазинов.
http(s)://<ваш_домен>/catalog?p=2 (вместо цифры 2).
Если на странице уязвимость есть, скрипт выполнится.
Важнейшим правилом для защиты сайта от таких уязвимостей является фильтрация получаемых и передаваемых данных по способу установки экранов для символов и преобразования специальных символов в HTML-сущности. Для php это осуществляется с применением функций htmlspecialchars(), htmlentities(), strip_tags(), например:
$name = htmlentities($_POST[‘name’], ENT_QUOTES, «UTF-8»);
$name = htmlspecialchars($_POST[‘name’], ENT_QUOTES).
При работе с «Битриксом» этот список можно еще дополнить методом CDatabase::ForSql. Пример:
Важно явно указывать кодировку страниц сайта:
Header(«Content-Type: text/html; charset=utf-8»);
Альтернативно можно запретить передавать в формах кавычки и скобки, занеся их в черный список. Но при этом могут появиться проблемы, так как будут блокироваться реальные запросы, содержащие «запрещенные» символы.
В общем, несмотря на многочисленные публикации в вебе, мы не можем назвать эту уязвимость присущей именно CMS «Битрикс» и указываем ее лишь по причине распространенности.
Кроме XSS-атак, к уязвимостям сайтов не специфическим для «1С-Битрикс» относят:
Подробнее можно посмотреть в документации, мы же не будем на них останавливаться, а рассмотрим более специализированные для «Битрикс» прорехи в безопасности.
Перенаправления – click.php, rk.php и redirect.php
Уязвимость открытых перенаправлений на «1С-Битрикс» известна довольно давно. На форуме разработчиков она активно обсуждается с 2014 года.
Суть проблемы заключалась в следующем:
От хостинг-провайдера приходит сообщение о том, что существенно растет нагрузка на MySQL.
Скриншот с форума разработчиков «Битрикс».
Причиной этому служило множество запросов (один пользователь отметил 30000 за 4 дня) с конструкцией вида:
При этом, после goto указывались, как правило, низкокачественные и мошеннические сайты.
Альтернативно проблема обнаруживается в системах аналитики, где видны внутренние и внешние ссылки именно по наличию таких URLов.
Это конструкция open redirect.
Open Redirect (открытое перенаправление) – это редирект, позволяющий использовать произвольный URL для конечной цели перенаправления.
Собственно, проблема открытого редиректа характерна не только для «1С-Битрикс». Конкретно же на «Битриксе» уязвимость связана с тремя системными файлами:
Кому и зачем это нужно?
Первый вариант – получение трастовых ссылок. В 2014 году умельцы так поднимали индекс цитирования (ТИЦ) продвигаемых ресурсов.
В посте в открытом доступе почти 50 ссылок такой конструкции на трастовые домены, в том числе госорганов и банков. А в конце поста автор предлагает запросить у него бесплатно базу на 400+ доменов с выявленной уязвимостью. Кстати, оптимизатор не скрывает, что пользуется уязвимостью:
Даны подробные инструкции, как индексировать ссылки, рассылать их по твиттер-аккаунтам.
Но еще интереснее, что автор предлагает в разы увеличить запросы на сайты-жертвы:
Добавим к этому автопрогоны по разным аддурилкам и базам, вот и получаем ту злополучную нагрузку на базу, о которой писал хостер.
Думаете, что 2014 год был давно? Тогда вот более свежий пример из 2017 года:
И вишенкой на торте: даже при беглой проверке мы нашли ссылки, которые продолжают работать и доблестно редиректить на сайты злоумышленников.
В 2018-2019 году темы по этой проблеме на форуме «1С-Битрикс» только набирали оборотов и свидетельствовали о ее массовости.
Второй вариант – фишинг. В почтовой рассылке, в сообщениях соцсетей и мессенджерах в такие ссылки маскируются мошеннические страницы, собирающие пользовательские (персональные, платежные) данные.
Третий вариант – спам для понижения авторитета сайта. Наличие огромного количества ссылок на низкокачественные ресурсы – негативный сигнал для поисковой системы о качестве сайта-донора.
Все дело в системных файлах «1С-Битрикс», используемых CMS для сбора статистики кликов и перенаправлений по рекламным баннерам и ссылкам. Возможность использовать сайт в качестве прокладки для сомнительных редиректов заложена «из коробки».
Как ни печально, проблема сохраняет актуальность. Несколько тем на форуме разработчиков, к сожалению, пока не привели к ее системному решению со стороны создателей CMS.
На запросы пользователей поддержка предлагает установить максимальный уровень безопасности в Проактивной защите, настроить редиректы с проверкой HTTP-заголовков.
Однако, как показывает практика, ни штатная «Защита редиректов от фишинга», ни многие другие средства не приносят необходимого результата. На повторное обращение техподдержка предложила удалить системные файлы.
Несмотря на абсурдность решения, оно, кстати, работает. Но при этом администратор ресурса теряет возможность отслеживать статистику кликов по баннерам и редиректов.
Файлы click.php и rk.php использует модуль «Битрикса» Реклама, баннеры (advertising). Если вы этот модуль не используете – без колебаний удаляйте его, соответственно и файлы эти удалятся.
Но несмотря на то, что этот способ помог некоторым участникам, стоит отметить его неуниверсальный характер. Он работает лишь в том случае, если в функционале сайта не используются редиректы и указанные файлы.
Более специализированный вариант кода:
Однако и он не учитывает наличие файла click.php.
restore.php
Проблема была выявлена при тестировании проекта на проникновение. Ее подробно описали на Хабре. Мы же кратко изложим суть.
На публичном IP была установлена виртуальная машина «Битрикс», что стало понятно по набору открытых портов.
При переходе по адресу ip_addr:80 в браузере открывалась страница первичной настройки CMS «1С-Битрикс» со ссылкой «Восстановить копию». Клик по ней запускает переход к модулю restore.php и в окне появляется предложение загрузить резервную копию:
Ситуация объясняется скорее всего человеческим фактором: вероятно, что администратор не завершил процедуру настройки вебсайта и Виртуальной машины VMBitrix. Но несмотря на то, что проблема связана с отсутствием контроля или ошибкой специалиста, она может стать причиной взлома.
restore.php осуществляет проверку и загрузку файлов, разворачивание резервных копий проекта. А это значит, что злоумышленник может загрузить посредством модуля не бекап, а файл phpinfo.php. Проведенный анализ показал, что проверка файлов «Битрикс» не сработала и скрипт с локального компьютера загрузился в корень веб-приложения.
Чтобы повторить в лабораторных условиях, была локально развернута «1С-Битрикс: Виртуальная машина» версии 7.2.
Попытка загрузить скрипт через опцию «Скачать резервную копию с дальнего сайта» не увенчалась успехом. Сработала проверка. В restore.php есть код с соответствующим условием:
Однако, обойти первое условие оказалось возможным. Для тестов взяли скрипт cmd.php. В cli системы передали символы-идентификаторов с содержимым файла cmd.php в новый файл под именем cmd_boom.php:
В hex-таблице он стал выглядеть так:
Файл был выгружен в репозиторий, и ссылка на него «скормлена» restore.php. Появился прогресс-бар загрузки и со временем – сообщение об ошибке:
Был ли удален файл?
Нет! Он остается в корне и запускается.
В форме с ошибкой нажали кнопку «Пропустить», затем – «Попробовать снова». В результате вывелась страница с кнопкой «Удалить локальную резервную копию и служебные скрипты». После клика на нее все файлы удалились.
Домашняя директория очищается от скриптов restore.php, bitrixsetup.php и файла cmd_boom.php. Сделать с сайтом ничего нельзя: резервная копия сайта не восстановлена, к установке нового не перейти.
В теории скрипт cmd.php можно скрыть в поддиректорию или же переименовать в index.php.
Обращение в техподдержку «Битрикс» не дало результатов. Точнее, ответ был таков, что поиск уязвимостей в restore.php не имеет смысла, так как скрипт предусмотрен для загрузки php-файлов на сайт.
С одной стороны понятно, нужно заканчивать установку и настройку. С другой – проблема не одиночна, а носит массовый характер. Быстрая поверхностная проверка выявила 600+ сайтов с опубликованными ВМ:
А если копнуть глубже? Надеемся, что этот факт заставит разработчиков задуматься над вопросом повышения безопасности на выявленном участке. А пока остается лишь быть предельно внимательным и не публиковать ВМ до того, как проект будет развернут на сервере, а также внимательно следить за всеми общедоступными страницами и ресурсами.
Бесконтрольная регистрация пользователей
Это довольно свежая проблема, выявленная в 2020 году. В январе-феврале начали мелькать сообщения владельцев сайтов и разработчиков о массовой регистрации с обходом капчи и последующей рассылкой спама при помощи уведомлений об успешной регистрации на проекте.
«В течение последней недели наблюдаются массовые регистрации ботов на сайтах под управлением СУ Битрикс. Судя по записям в журнале событий регистрация происходит по адресу /auth/?register=yes Так вот, на этих сайтах раздел /auth/ либо отсутствует, либо там нет формы регистрации. Кто-нибудь сталкивался с подобной проблемой?»
Интересно, что с ситуацией сталкивались даже на сайтах, где регистрация вообще не предусмотрена, например, на лендингах и визитках. Появлялись пользователи и на проектах, где регистрация реализована через компонент main.register либо на самописном коде на API-Битрикс, где есть и reCaptcha, и правила валидации, и набор обязательных полей.
Главной причиной проблемы выступают старые компоненты:
На страницах они появляются со значением true константы NEED_AUTH:
Но есть нюанс. Даже если константа не установлена компоненты благополучно отрабатывают, если подается «правильный» POST-запрос. Получается, что на любую страницу сайта, на котором даже не предусмотрена регистрация, можно подать запрос и получить успешно зарегистрированного пользователя.
Разработчик и автор блога CodeBlog Панов Алексей провел исследование, составив универсальный запрос для регистрации из Postman:
Как указывалось, запрос успешно сработал и на ресурсах без регистрации (лендинги), и на интернет-магазинах, «обойдя капчу в форме регистрации».
Очевидно, что при желании не составит труда автоматизировать процесс.
Хорошая новость в том, что способ защититься от атаки есть.
Совершать необходимые проверки полей нового пользователя в обработчике события OnBeforeUserAdd. Так можно не дублировать валидацию в коде, где возможна регистрация.
Настроить указанные компоненты system.auth.* надлежащим образом. Подробно об этом можно посмотреть в статье на Хабре.
В техподдержке «Битрикс» проблема известна, но они лишь «разводят руками», просто предлагая устанавливать капчу. Остается надеяться, что со временем уязвимость будет устранена. А пока рассчитываем только на собственные силы.
Где проверить сайт на уязвимости
Мы готовы провести аудит качества кода вашего сайта или интернет-магазина. При этом выявляются не только уязвимости, но и прорехи в производительности, вероятные ошибки в работе основных инструментов сайта, проблемы со скоростью загрузки.
И не забывайте: если ваш сайт по какой-то причине был выбран злоумышленниками в качестве цели, вполне возможен комплексный подход ко взлому. Делайте бекапы и следите за качеством кода и подрядчиков, с которыми вы сотрудничаете для его написания.
В качестве резюме (оптимистическое)
«1С-Битрикс» позволяет отбросить множество рисков. CMS на самом деле содержит реально работающие инструменты, которые помогу повысить уровень защиты вашего сайта от нежелательных атак. Поэтому мы рекомендуем создавать серьезные проекты именно на «Битрикс».
При этом по-настоящему важно:
поддерживать актуальность CMS – вовремя обновлять до последней версии;
обеспечивать высокое качество разработки или доработок вашего сайта исполнителями.
Ведь сама по себе пустая CMS практически не несет рисков. Проблемы могут начаться при неквалифицированном вмешательстве, когда происходит программирование страниц, функционала, шаблонов.
Тема о проблемах безопасности в вебе всегда будет актуальна. И чем популярнее CMS, тем больше вариантов разнообразных атак на нее. Но не стоит постоянно думать только об этом. Достаточно соблюдать несколько простых правил, чтобы не переживать о своем сайте:
Ну, а где искать профи в Битрикс, Вы теперь точно знаете!
Кроме помеченных в статье источников, при подготовке материала использовались: