Усунення вразливостей сайту 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 у залежностях.

Випадок із практики

Великий інтернет-магазин, редакція «Бізнес Плюс». Симптом: periodично з'являються редиректи на сторонні сайти, але лише для пошукових ботів (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-доступу

Терміни виконання

Терміни залежать від ступеня зараження, обсягу кастомного коду та наявності резервних копій до зараження.