Битрикс падает не от нулевых дней, а от накопленных ошибок в конфигурации и модели доверия, которую создают администраторы https://seberd.ru/5471
Платформа 1С-Битрикс работает на множестве корпоративных сайтов в России. Она проверена временем, имеет коммерческую лицензию и поддержку разработчиков. При этом реальные инциденты показывают иную картину. Сайты становятся недоступны не из-за сложных эксплойтов, а из-за базовых ошибок в настройках и непонимания того, как система взаимодействует с внешним трафиком. Уязвимость часто формируется не в коде ядра, а в логике разграничения прав, которую неявно выстраивают сами специалисты по сопровождению.
Я работаю с информационной безопасностью и регулярно сталкиваюсь с последствиями таких конфигурационных просчётов. Ниже разбираю типовые векторы атак на Битрикс и практические шаги по их устранению.
Какие векторы атак используют против сайтов на Битрикс
Атаки на платформу обычно строятся по трём направлениям. Их редко рассматривают вместе, хотя в реальных инцидентах они часто комбинируются.
Первый вектор — эксплуатация компонентов и модулей. Платформа модульная, каждый дополнительный модуль или кастомный компонент увеличивает поверхность атаки. Официальный маркетплейс содержит сотни решений, и перед публикацией они проходят лишь базовую проверку. В боевой среде оказываются модули с недостаточной валидацией входных данных или устаревшими зависимостями.
Второй вектор — конфигурационные ошибки и наследие старых версий. Многие проекты начинались на ядре версии 16-17 и мигрировали с накопленным техническим долгом. В настройках .htaccess или параметрах главного модуля остаются артефакты прошлых конфигураций, которые конфликтуют с текущими требованиями безопасности.
Третий вектор — логика бизнес-процессов в публичной части. Форма обратной связи может не только отправлять письмо, но и записывать данные в инфоблок с правами на выполнение серверного кода. Компонент голосования может принимать произвольные параметры для SQL-запроса без должной санитизации.
[√] Проверяю актуальность всех установленных модулей — устаревшие версии содержат известные уязвимости, которые автоматизируются в ботнетах
[ ] Анализирую публичные endpoints на предмет избыточных прав — обработчики, написанные для внутреннего использования, иногда остаются доступными извне
[x] Тестирую формы на возможность инъекций через поля с типом «HTML/текст» — разрешённый PHP в инфоблоках превращает пользовательский ввод в код
Какие файлы и пути проверяют злоумышленники в первую очередь
При разведке сайта на Битрикс атакующий ищет не случайные ресурсы, а конкретные точки, известные по публичным отчётам и базе инцидентов.
Административная панель по умолчанию доступна по пути /bitrix/admin/. Её можно переименовать, но многие проекты этого не делают. Сам факт доступности даёт информацию о структуре системы. Опаснее файлы, которые остаются в публичном доступе после установки или обновления — install.config.php, логи отладки, резервные копии. Они могут содержать учётные данные для подключения к базе, ключи API или трассировку внутренних ошибок.
Особое внимание к файлу .settings.php и его аналогу .settings-extra.php. В нём хранятся параметры подключения к базе и другие критичные настройки. По спецификации он должен находиться вне корня сайта, но из-за ошибок в структуре проекта или ручного копирования иногда попадает в зону видимости веб-сервера. Содержимое этого файла — готовый набор данных для компрометации сайта и базы.
Как проверить наличие чувствительных файлов в публичной зоне? Откройте терминал и выполните команду в корне сайта:
find . -maxdepth 2 -name "*.php" -o -name "*.log" -o -name "*.sql" | grep -E "(settings|install|backup|debug)"Результат покажет файлы, которые не должны быть доступны извне.
Почему стандартная загрузка файлов в Битрикс требует дополнительной проверки
Платформа предоставляет класс CFile для работы с файлами. Однако кастомные компоненты для загрузки изображений или документов часто реализуют собственную логику. Типичная ошибка — проверка типа файла только по расширению (.jpg, .png) или MIME-типу в заголовках HTTP, без анализа реального содержимого.
Это позволяет загрузить файл с расширением .jpg, содержащим серверный код, если веб-сервер настроен на выполнение кода в любом файле. Ещё один сценарий — загрузка через AJAX-обработчики без проверки авторизации или прав пользователя. В результате анонимный запрос может заполнить диск сервера или разместить веб-оболочку.
Я рекомендую проверять загружаемые файлы на уровне содержимого. Библиотеки вроде finfo или специализированные модули для анализа заголовков файлов дают более надёжный результат, чем проверка по расширению.
Как данные из публичных форм попадают в исполняемый контекст
Формы обратной связи, подписки, быстрого заказа — обязательный элемент большинства сайтов. В Битрикс их часто создают через визуальный редактор или стандартные компоненты. Проблема возникает, когда данные из формы не только отправляются на почту, но и записываются в инфоблоки или высокоуровневые сущности.
Рассмотрим механику. На сайте есть форма «Заказать звонок». Обработчик отправляет письмо менеджеру и добавляет запись в инфоблок «Заявки» через CIBlockElement::Add(). Если у инфоблока в настройках разрешено выполнение серверного кода в полях типа «HTML/текст», а в форме есть поле «Комментарий», то пользователь может передать в него код. При отображении заявки в административной части или публичном списке этот код будет выполнен.
Другой частый сценарий — модификация SQL-запроса через параметры сортировки. Компоненты списков используют параметры GET, например ?SORT_BY=DATE&SORT_ORDER=DESC. Если эти параметры подставляются в запрос без экранирования через CDBResult или Query, появляется возможность изменить логику выборки.
[√] Отключаю выполнение серверного кода в свойствах инфоблоков — это предотвращает инъекции через пользовательский ввод
[ ] Экранирую все параметры, поступающие из GET/POST, перед использованием в запросах — даже если компонент кажется безопасным
[x] Проверяю, как данные из форм отображаются далее — в админке, письмах, личных кабинетах — на предмет неконтролируемого выполнения кода
Где рвётся цепочка доверия при работе с сессиями в Битрикс
Платформа использует собственные механизмы сессий, храня идентификатор в cookie. В кастомных разработках, особенно при интеграции с внешними сервисами или создании API, программисты иногда отходят от стандартных методов.
Классическая ошибка — передача идентификатора сессии или параметра авторизации через URL. Это может произойти при реализации функционала «поделиться корзиной» или «сохранить состояние формы». Такой идентификатор попадает в логи прокси-серверов, браузеров и может быть перехвачен.
Другой момент — недостаточная инвалидация сессии после выхода. Если при выходе удаляется только cookie на клиенте, но запись о сессии остаётся активной на сервере, и эта сессия где-то кэшируется (например, в мобильном приложении через API), то её можно продолжать использовать.
Я всегда проверяю, как реализован механизм выхода в кастомных интеграциях. Удаление сессии должно происходить и на клиенте, и на сервере, с очисткой всех связанных кэшей.
Что делать с модулями, которые больше не используются
Многие проекты на Битрикс живут годами. За это время на них устанавливались и отключались различные модули — от систем оплаты и CRM до интеграций со службами доставки. Модуль может быть деактивирован в административной панели, но его файлы остаются на диске.
Если в этих файлах есть публичные обработчики (например, result.php для приёма callback от платёжного шлюза), они остаются доступными для прямого вызова. Такие обработчики часто написаны в расчёте на то, что их будет вызывать только доверенный сервис, и содержат минимальные проверки. Атакующий, найдя такой «забытый» endpoint, может использовать его для внедрения данных или вызова нештатных действий.
Как найти такие модули? В административной панели перейдите в «Настройки» → «Модули». Выпишите все сторонние модули. Для каждого проверьте, актуален ли он, используется ли в проекте. Удалите файлы неиспользуемых модулей с сервера.
[√] Удаляю файлы деактивированных модулей — деактивация в панели не убирает файлы с диска
[ ] Проверяю публичные обработчики в оставшихся модулях на наличие авторизации и валидации входных данных
[ ] Анализирую логи веб-сервера на предмет обращений к старым endpoints — это помогает найти забытые точки входа
Как построить аудит безопасности под архитектуру конкретного проекта
Стандартные сканеры уязвимостей часто плохо справляются со сложной структурой Битрикс. Поэтому проверку нужно строить от логики приложения, а не от абстрактных сигнатур.
Составьте карту публичных endpoints. Используйте инструменты вроде GoSpider или ZAP для рекурсивного обхода сайта. Особое внимание уделите путям, содержащим слова: handler, upload, api, gateway, callback, payment, result, export.
Проверьте права на выполнение кода в инфоблоках. В разделе «Контент» → «Информационные блоки» для каждого инфоблока проверьте тип каждого пользовательского свойства. Если есть свойства типа «HTML/текст», убедитесь, что в настройках снята галочка «Разрешить серверный код». Это должно быть отключено в боевой среде всегда.
Аудит файлов в корневой директории. С помощью SSH или файлового менеджера проверьте, нет ли в публичном доступе файлов с именами: .settings.php, .settings-extra.php, install.config.php, backup.sql, *.log, debug.txt. Настройте веб-сервер (Nginx/Apache) на запрет доступа ко всем файлам с расширением .php, кроме index.php и известных публичных точек входа.
Тестирование форм. Для каждой публичной формы попробуйте передать в текстовые поля строки вида или . Проверьте, экранируется ли вывод. Если форма ведёт к записи в базу, посмотрите, как эта запись отображается далее — в админке, в письме, в личном кабинете пользователя.
Анализ .htaccess и правил Nginx. Убедитесь, что в конфигурации веб-сервера запрещён прямой доступ к служебным папкам Битрикс (/bitrix/, /local/, /upload/) кроме тех подпапок, где хранятся действительно публичные ресурсы (например, /upload/iblock/ для изображений). Проверьте, что отключено раскрытие структуры каталогов при отсутствии index-файла.
Почему безопасность Битрикс требует постоянного процесса, а не разовой настройки
Ядро платформы развивается и становится более защищённым с каждым обновлением. Но безопасность готового сайта — это композит из надёжности ядра, качества кастомных разработок и грамотности администрирования. Уязвимость появляется не там, где её ждут, а на стыке этих компонентов: в модуле, который забыли обновить; в инфоблоке, созданном пять лет назад с опасными настройками; в обработчике формы, написанном в спешке перед запуском.
Регулярный аудит, построенный не на поиске известных CVE, а на понимании уникальной архитектуры вашего портала, даёт больше, чем установка очередного WAF-модуля. В конечном счёте, самое слабое звено в защите — это предположение, что раз платформа коммерческая и сложная, то она «сама всё предусмотрела». Она предусмотрела инструменты, но правильно их настроить и использовать — задача тех, кто отвечает за сайт.
Какой шаг вы сделаете первым после прочтения? Проверите ли файлы в корне сайта на наличие .settings.php? Или начнёте с аудита модулей?