4 самых опасных уязвимости сайта на 1С:Битрикс

Безопасность вашего сайта на 1С:Битрикс - это ключевой аспект, который требует постоянного внимания. Несмотря на широко признанно высокий уровень безопасности в системе «Битрикс», сегодня мы все еще сталкиваемся с потенциальными уязвимостями, которые могут привести к серьезным негативным последствиям.

В этой статье мы рассмотрим 4 наиболее опасных уязвимости, которые могут стать серьезной проблемой для вашего проекта. Защитите свой проект от потенциальных угроз, ознакомившись с нашей статьей!

XSS-атака

Bitrix Hub выявил, что одной из самых распространенных уязвимостей в проектах, работающих на платформе «1С-Битрикс: Управление сайтом», является атака на кросс-скриптинг (XSS-атаки). Эта проблема остается актуальной и поднимается на первое место в списке уязвимостей.

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

---

«Атака XSS используется для изменения внешнего вида html-страниц уязвимого ресурса в контексте браузера целевого пользователя, для кражи данных cookie его браузера и последующего их злоупотребления, в том числе внедрения в его сессию под чужой учетной записью».

Марсель Низамутдинов, эксперт по информационной безопасности в компании «1С-Битрикс»

---

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

Зачем используется кросс-скриптинг

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

Принципиальная схема межсайтового скриптинга

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

Поиск уязвимостей типа XSS обычно начинается с анализа форм связи на сайте. Злоумышленники пытаются внедрить вредоносные скрипты, чтобы выявить и эксплуатировать уязвимости. Для определения наличия уязвимости достаточно передать в форму запрос следующего вида:

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

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

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

http(s)://{ваш_домен}/catalog?p=2 (вместо цифры 2).

Если на веб-странице существует уязвимость, вредоносный скрипт может быть выполнен, что создает потенциальную угрозу безопасности. Одним из важнейших правил для обеспечения защиты сайта от подобных уязвимостей является фильтрация данных, получаемых и передаваемых через различные способы, путем применения экранирования символов и преобразования специальных символов в HTML-сущности. Например, для PHP это можно осуществить с помощью функций таких как htmlspecialchars(), htmlentities(), strip_tags(), например:

$name = strip_tags($_POST['name']);

$name = htmlentities($_POST['name'], ENT_QUOTES, "UTF-8");

$name = htmlspecialchars($_POST['name'], ENT_QUOTES).

При работе с CMS Bitrix этот список возможно дополнить методом CDatabase::ForSql. Пример:

$name = CDatabase::ForSql($_POST['name']).

Важно точно указывать кодировку страниц сайта:

Header("Content-Type: text/html; charset=utf-8");

Как альтернативу можно рассмотреть запрет передачи символов кавычек и скобок в данных, передаваемых через формы, добавив их в черный список. Однако, при этом существует риск блокирования законных запросов, которые могут содержать эти "запрещенные" символы. Поэтому при использовании такого метода необходимо быть внимательным, чтобы избежать ложных срабатываний.

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

Другие типы атак

Кроме атак типа XSS, к неспецифичным уязвимостям сайтов, которые не являются особенными для «1С-Битрикс», можно отнести следующие:

1. SQL-инъекции - атаки, направленные на выполнение SQL-команд через веб-формы или другие входные данные.
2. Внедрение в имя файла - использование манипуляций с именами файлов для проведения вредоносных действий.
3. Выполнение системных команд - попытки выполнить команды на сервере через веб-приложение.
4. Подбор реквизитов доступа - атаки на логины и пароли для получения несанкционированного доступа.
5. Логические ошибки в коде - уязвимости, связанные с некорректной обработкой данных и логикой в программном коде.
6. Межсайтовая подделка запроса CSRF - атаки, при которых злоумышленник может провести действия от имени авторизованного пользователя без его согласия.
7. Фишинг - попытки обмануть пользователей и получить их конфиденциальную информацию.
8. Социальная инженерия - использование манипуляций и манипулирования людьми для получения информации или доступа к системам.

Как защитить сайт

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

• Используйте функцию htmlspecialchars для экранирования специальных символов. Это поможет предотвратить внедрение вредоносного кода на страницы сайта.
• Ограничивайте параметры тегов с динамическими значениями двойными кавычками. Этот подход поможет предотвратить попытки злоумышленников внедрить код через атрибуты тегов.
• Обязательно добавляйте протокол (например, http) к значениям параметров тегов, таких как href или src, где это необходимо. Это поможет избежать потенциальных атак, связанных с отсутствием протокола в URL-адресах.

Перенаправления – click.php, rk.php и redirect.php

Уязвимость, связанная с открытыми перенаправлениями в CMS «1С-Битрикс», известна уже давно. Суть проблемы заключается в следующем:

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

Причиной тому стало множество запросов (один пользователь отметил 30 тысяч за 4 дня) с конструкцией вида:

/bitrix/rk.php?=goto=http…

Часто после ключевого слова "goto" следовали ссылки на веб-сайты низкого качества и сайты, связанные с мошенничеством.

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

Этот вид уязвимости известен как «open redirect».

Open Redirect (открытое перенаправление) – это редирект, позволяющий использовать произвольный URL для конечной цели перенаправления.

На «Битриксе» уязвимость связана с тремя системными файлами:

• click.php;
• rk.php;
• redirect.php.

Примеры ссылок:

{домен_жертва}/bitrix/click.php
?anything=here&goto={домен_цель}/

{домен_жертва}/bitrix/rk.php
?id=17&site_id=s1
&event1=banner&event2=click
&goto= {домен_цель}/

{домен_жертва}/bitrix/redirect.php
?event1=click_to_call
&event2=&event3=
&goto={домен_цель}/

Кому и зачем это нужно?

1. Первый сценарий - получение доверительных ссылок. В 2014 году многие специалисты использовали этот метод для увеличения индекса цитирования (ТИЦ) своих веб-ресурсов.
2. Второй вариант - фишинг. Злоумышленники маскируют подобные ссылки в электронных письмах, социальных сетях и мессенджерах, чтобы перенаправлять пользователей на мошеннические страницы и собирать их личные и финансовые данные.
3. Третий сценарий - спам с целью понижения авторитета веб-сайта. Когда на сайте присутствует большое количество ссылок на низкокачественные ресурсы, это может рассматриваться поисковой системой как отрицательный сигнал о качестве этого сайта-донора.

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

Как защитить сайт

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

Поддержка рекомендует пользователям установить максимальный уровень безопасности в Проактивной защите и настроить редиректы с проверкой HTTP-заголовков.

- /bitrix/redirect.php
- /bitrix/rk.php

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

И, несмотря на абсурдность такого решения, оно, по собственному опыту, действительно работает. Однако, при этом администратор сайта теряет возможность отслеживать статистику кликов по баннерам и редиректам.

Файлы click.php и rk.php используются модулем Битрикса Реклама, баннеры (advertising). Если вы не используете данный модуль, вы можете удалить его, и, соответственно, эти файлы также будут удалены.

Некоторые пользователи форума разработчиков предложили альтернативное решение. Они добавили следующие строки в файл .htaccess:

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

Есть более специализированный вариант кода:

Однако и в этом случае не учитывается наличие файла click.php.

restore.php

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

Когда пользователь переходил по адресу ip_addr:80 в своем браузере, он видел страницу первоначальной настройки CMS "1С-Битрикс" с ссылкой "Восстановить копию". При нажатии на эту ссылку происходил переход к модулю restore.php, и на экране появлялось предложение загрузить резервную копию.

Эта ситуация, вероятно, объясняется человеческим фактором: возможно, администратор не завершил процедуру настройки веб-сайта и виртуальной машины VMBitrix. Однако, несмотря на то, что эта проблема может быть связана с отсутствием контроля или ошибкой специалиста, она потенциально может послужить причиной взлома.

Функциональность restore.php предназначена для проверки и загрузки файлов, а также разворачивания резервных копий проекта. Это означает, что злоумышленник, воспользовавшись этим модулем, может загрузить не только резервную копию, но и любой другой файл, такой как phpinfo.php. Анализ показал, что проверка файлов "Битрикс" не сработала, и скрипт с локального компьютера был загружен в корневой каталог веб-приложения.

Для воспроизведения этой проблемы в лабораторных условиях была создана локальная установка "1С-Битрикс: Виртуальная машина" версии 7.2.

Попытка загрузить скрипт через опцию "Скачать резервную копию с дальнего сайта" не привела к успеху, так как сработала проверка. В файле restore.php был обнаружен код с соответствующим условием:

Тем не менее, обход первого условия оказался выполнимым. Для проведения тестов был использован скрипт cmd.php. Путем передачи символов-идентификаторов из содержимого файла cmd.php в новый файл с именем cmd_boom.php в среде командной строки системы:

echo -e "\x1f\x8b\n$(cat 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, правила валидации и обязательные поля.

Главной причиной этой проблемы оказались устаревшие компоненты:

• system.auth.registration
• system.auth.authorize
• system.auth.forgotpasswd
• system.auth.changepasswd

На страницах они видны со значением true константы NEED_AUTH:

define("NEED_AUTH", true)

Но есть нюанс. Даже если константа не установлена компоненты благополучно отрабатывают, если подается «правильный» POST-запрос. Получается, что на любую страницу сайта, на котором даже не предусмотрена регистрация, можно подать запрос и получить успешно зарегистрированного пользователя.

Один исследователь составил универсальный запрос для регистрации из Postman:

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

Очевидно, что с достаточным желанием можно легко автоматизировать этот процесс.

Как защитить сайт

Приятная новость состоит в том, что уже существует метод защиты от таких атак.

1. Если вы используете собственную регистрацию, то в настройках главного модуля, на вкладке "Авторизация", снимите флажок напротив "Позволять пользователям регистрироваться самостоятельно" и установите его напротив "Использовать CAPTCHA при регистрации", хотя бы временно, чтобы защититься от вторжения ботов. Учтите, что этот метод не подходит, если у вас настроена регистрация через SMS.


2. Вы также можете провести необходимые проверки полей нового пользователя в обработчике события OnBeforeUserAdd, чтобы избежать дублирования валидации в коде, где предполагается регистрация.
3. Важно правильно настроить указанные компоненты системы, такие как system.auth.*, чтобы обеспечить безопасность вашего сайта.

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

Где проверить сайт на уязвимости

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

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

Ключевыми факторами для безопасности вашего сайта являются:

• Поддержание актуальности CMS - важно своевременно обновлять ее до последней версии.
• Обеспечение высокого качества разработки или доработок сайта с помощью квалифицированных исполнителей.

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

Следуя простым правилам, вы можете обеспечить безопасность своего сайта:

• Вовремя обновлять CMS.
• Доверять работу с сайтом квалифицированным специалистам.
• Делать актуальные резервные копии.
• При обнаружении проблем оперативно обращаться к разработчикам для их выявления и устранения.
• Регулярно проверять безопасность вашего ресурса (мы рекомендуем делать это раз в 2-3 месяца).

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