Устранение уязвимостей сайта 1С-Битрикс

Устранение уязвимостей сайта 1С-Битрикс

Устранение уязвимостей — не разовая задача. Это процесс: найти, классифицировать, исправить, проверить регрессию, закрыть вектор повторного появления. Большинство инцидентов на Битрикс-сайтах происходит не из-за уязвимостей в ядре, а из-за устаревших кастомных компонентов, неправильных прав на файлы и захардкоженных учётных данных.

Классификация уязвимостей в Битрикс-проектах

XSS (межсайтовый скриптинг) — самая распространённая. Источник: вывод данных из $_GET/$_POST без экранирования в кастомных компонентах и шаблонах. Проверка:

// Уязвимо:
echo $_GET['search'];

// Правильно:
echo htmlspecialchars($_GET['search'], ENT_QUOTES, 'UTF-8');
// Или через Битрикс D7:
echo \Bitrix\Main\Text\HtmlFilter::encode($_GET['search']);

Рефлективный XSS в URL страницы поиска — типичный вектор. Проверяйте все параметры URL, которые выводятся в шаблоне.

SQL-инъекции — устарели при использовании D7 ORM, но живы в старых компонентах с $DB->Query():

// Уязвимо:
$DB->Query("SELECT * FROM b_user WHERE LOGIN = '" . $_POST['login'] . "'");

// Правильно:
$DB->Query("SELECT * FROM b_user WHERE LOGIN = '" . $DB->ForSql($_POST['login']) . "'");

PHP-инъекции через загрузку файлов — отсутствие проверки расширений при загрузке через кастомные формы. Файл shell.php.jpg может быть переименован и выполнен.

IDOR (небезопасные прямые ссылки на объекты) — запросы вида /order/?ID=12345 без проверки принадлежности заказа текущему пользователю. В стандартных компонентах Битрикс это закрыто, в кастомных — часто нет.

Устранение заражения

Если сайт уже заражён — последовательность действий:

1. Изоляция: перевести в режим обслуживания или закрыть внешний доступ
2. Поиск вредоносного кода:

find /var/www -name "*.php" -exec grep -l "base64_decode\|eval\|system\|exec" {} \;

3. Анализ дат изменения: файлы, изменённые после даты последнего деплоя — подозреваемые
4. Сравнение с чистым дистрибутивом: скачайте чистую версию Битрикс и сравните файлы ядра через diff -r
5. Смена всех учётных данных: пароли администраторов, ключи API, пароль БД, FTP-доступ
6. Обновление ядра и модулей до актуальных версий

Таблица b_security_log — проверьте события до момента заражения. Часто видно IP, с которого эксплуатировалась уязвимость.

Закрытие векторов

Права на файлы — после очистки:

find /var/www/html -type d -exec chmod 755 {} \;
find /var/www/html -type f -exec chmod 644 {} \;
chmod 440 /var/www/html/bitrix/.settings.php
chmod 440 /var/www/html/bitrix/php_interface/dbconn.php

Блокировка выполнения PHP в upload/:

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

Обновление зависимостей — если проект использует Composer, проверьте composer audit на известные CVE в зависимостях.

Случай из практики

Крупный интернет-магазин, редакция «Бизнес Плюс». Симптом: периодически появляются редиректы на сторонние сайты, но только для поисковых ботов (User-Agent). Сканер Битрикс — чисто. Анализ файлов по дате изменения выявил модифицированный /bitrix/modules/main/include/prolog.php — в него был инжектирован код с проверкой User-Agent и редиректом. Дополнительно: backdoor в /bitrix/components/bitrix/main.include/component.php. Вектор входа — скомпрометированный FTP-пароль хостинга (пароль от 2019 года, утёкший через другой сервис).

Исправление: восстановление файлов ядра из эталонного дистрибутива, смена всех паролей, включение двухфакторной аутентификации для FTP и SSH, настройка SFTP с ключевой аутентификацией вместо паролей.

Превентивные меры после устранения

• Мониторинг целостности файлов: настройте inotifywait или используйте модуль «Контроль целостности» в Битрикс
• WAF: включите и настройте проактивный фильтр в активный режим
• Регулярные обновления: подпишитесь на рассылку security-обновлений Битрикс
• Ограничение доступа: FTP/SSH только с конкретных IP, деплой через CI/CD без постоянного FTP-доступа

Сроки выполнения

Сроки зависят от степени заражения, объёма кастомного кода и наличия резервных копий до заражения.