Когда редактор инфоблока получает доступ к серверному коду

«Дайте редактору полный доступ к каталогу, иначе импорт не работает». Я бы остановил такую заявку и сначала выяснил, какой операции не хватает. За привычным словом «редактирование» может скрываться разрешение менять настройки, связанные с серверными PHP-файлами. Я — Семёнов Евгений Сергеевич, директор ООО «АйТи-Фреш». Покажу, где подтверждён риск RCE, какие полномочия нужно разделить и как сохранить рабочий импорт. Технические сведения проверены на 8 сентября 2026 года.

Название роли ничего не говорит о её возможностях

Для меня редактор — сотрудник, который меняет заголовок, описание, фотографию и другие согласованные данные карточки. Администратор инфоблока определяет устройство хранилища и его техническое поведение. В расширенной модели прав 1С-Битрикс этим задачам соответствуют разные операции: element_edit разрешает изменение элемента, а iblock_edit — изменение параметров инфоблока. Поэтому фраза «ему можно редактировать инфоблок» для согласования доступа слишком расплывчата. Я прошу назвать конкретные действия, конкретный инфоблок и рабочую задачу. Перечень операций опубликован в документации метода CIBlock::GetPermission.

Опасная организационная привычка выглядит безобидно: сотрудник не видит нужную кнопку, и ему копируют права более опытного коллеги. Потом к роли добавляют полномочия для импорта, временно включают подрядчика и забывают снять исключение с отдельного раздела. Название группы остаётся прежним, хотя её возможности давно изменились. Я начинаю проверку с эффективных прав конкретной учётной записи — всех групп, назначений на инфоблок, исключений для разделов и элементов. Удалить разрешение из одной группы недостаточно, если другая продолжает его предоставлять.

Такой подход следует самой модели Bitrix Framework: права пользователя складываются из максимальных прав всех групп, а разделы и элементы могут наследовать назначения от родительского объекта. При двух членствах с уровнями «Чтение» и «Запись» пользователь получает «Запись». Поэтому отрицательный результат нельзя доказывать одним снимком настройки группы. Нужно открыть состав групп пользователя, проверить режим прав инфоблока и пройти всю цепочку наследования. Это прямо описано в разделе «Права доступа».

Для IT-директора важна граница возможного ущерба. Компрометация обычного редакторского аккаунта должна ограничиваться доступными материалами и бизнес-операциями. Если через аккаунт можно добиться выполнения PHP, злоумышленник действует с полномочиями процесса приложения: потенциально читает доступную конфигурацию, обращается к базе, интеграционным секретам и файлам сайта. Это не означает автоматического получения root и не доказывает захват всей корпоративной сети. Но для утечки заказов, подмены реквизитов или остановки интернет-магазина полномочий веб-приложения часто достаточно. Поэтому роль я оцениваю по последствиям её компрометации, а не по должности владельца.

Где RCE подтверждён, а где начинается преувеличение

Конкретный пример — PT-2025-28, он же BDU:2025-08666. В бюллетене Positive Technologies указано, что проблема затрагивает модуль iblock до версии 24.300.100. Злоумышленник с правом редактирования свойств инфоблока мог выполнить произвольный код при создании нового элемента. Производитель подтвердил уязвимость. Оценка исследователя по CVSS 4.0 составляет 8,9, а базовый вектор CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H содержит метрику PR:H: для эксплуатации нужны высокие привилегии. Все эти данные приведены в PT-2025-28.

У производителя карточка называется «Local File Inclusion при изменении свойств инфоблока». В ней указаны модуль iblock, дата выявления 21 апреля 2025 года, дата исправления 23 апреля 2025 года и версия исправления 24.300.100. Уровень опасности в карточке производителя обозначен числом 8 без указания версии CVSS. Это не противоречит оценке 8,9 в бюллетене Positive Technologies: источники показывают разные представления оценки, и смешивать их в одну цифру нельзя. Первичный документ вендора — карточка 25346824.

Терминология здесь действительно требует аккуратности. Вендор описывает LFI, а исследователь — итоговую возможность удалённого выполнения кода через внедрение в PHP-сценарий. Пользовательская документация показывает архитектурный контекст: в параметрах инфоблока есть полный путь к файлу, модифицирующему поля перед сохранением, и полный путь к файлу-обработчику формы редактирования элемента. Оба поля прямо помечены как предназначенные только для разработчиков. Но открытый бюллетень не содержит пошагового доказательства эксплуатации, поэтому я не превращаю описание штатных полей в самодельную инструкцию атаки и не утверждаю, что любое заполнение этих полей приводит к RCE. Сами параметры описаны в форме создания и редактирования инфоблока.

История версий подтверждает содержание релиза 24.300.100 от 23 апреля 2025 года: усилены проверка доступа при редактировании настроек инфоблока и проверка корректности путей к файлам при импорте. Следовательно, для уязвимых установок минимальная граница исправления — 24.300.100, но это не целевая версия для новой эксплуатации. По состоянию на дату проверки в официальной истории опубликован iblock 26.0.0 от 8 июня 2026 года. Я устанавливаю актуальные совместимые обновления, а не останавливаюсь на первом релизе, закрывающем один дефект. История доступна на странице версий модуля iblock.

После обновления я не ставлю знак равенства между iblock_edit и гарантированным RCE. Для актуальной версии такое утверждение потребовало бы отдельного доказательства. Однако лишнее право всё равно остаётся нарушением принципа минимальных привилегий: оно позволяет менять параметры хранилища, предназначенные не для редактора. Проверять нужно именно установленную версию модуля iblock и успешное завершение обновлений. Номер Главного модуля не доказывает, что нужный релиз iblock действительно установлен.

Какие разрешения я забираю у контентных ролей

Для описанной роли я использую расширенное управление правами и отдельный пользовательский уровень с понятным составом операций. Сначала включаю и проверяю этот режим на тестовой копии, потому что после перехода нужно заново просмотреть назначения на инфоблок, разделы и элементы. Системный уровень не переделываю под редакцию: в административной части на странице «Настройки → Пользователи → Уровни доступа» создаю пользовательский уровень, выбираю модуль и привязку, затем отмечаю необходимые операции. Официальная документация подтверждает, что системные уровни доступны только для просмотра, а пользовательские можно создавать и редактировать: управление уровнями доступа и форма уровня доступа.

Мой исходный набор для обычной редакторской работы — element_read, section_read и element_edit. Создание карточки разрешаю операцией section_element_bind только там, где оно действительно нужно. Для показа инфоблока в административной части используется iblock_admin_display. Если сотрудник управляет рубрикатором, отдельно рассматриваю section_edit и section_section_bind; автоматически редактору их не добавляю. Это стартовая матрица, а не универсальная роль: торговые предложения, документооборот, цены и пользовательские компоненты могут потребовать дополнительных разрешённых операций и серверных проверок.

Изменение цен — отдельная операция element_edit_price, удаление карточки — element_delete, экспорт инфоблока — iblock_export. Эти полномочия не равны доступу к PHP, но способны причинить бизнес-ущерб, поэтому их согласовывают отдельно. Публикация без проверки, массовое удаление или выгрузка каталога могут быть неприемлемы даже на полностью обновлённом сайте. Я не смешиваю эти риски с PT-2025-28: для каждого оставляю собственное основание, владельца и приёмочный тест.

Отдельно проверяю операцию Главного модуля edit_php — «Изменение PHP-кода». Для контентной роли она не нужна. Официальная страница списка пользователей сообщает, что даже действие «Авторизоваться» под другим пользователем доступно учётным записям, у которых в уровне доступа к Главному модулю есть edit_php. Это хороший индикатор широты полномочия, а не функция импорта каталога. Ссылка на первоисточник: список пользователей.

После изменения роли я обязательно проверяю дополнительные пути записи: файловый менеджер, редактирование шаблонов, командную PHP-строку, установленные модули и собственные административные страницы. Операция lpa_template_edit означает ограниченную модификацию шаблонов без PHP-кода; это не то же самое, что полноценное редактирование PHP. Одного удаления iblock_edit недостаточно, если другой инструмент позволяет записать исполняемый файл в код проекта.

• Убрать `iblock_edit` и `iblock_delete`: параметры инфоблока и удаление хранилища целиком должны оставаться у технической роли.
• Убрать `iblock_rights_edit`, `section_rights_edit` и `element_rights_edit`: контентная роль не должна самостоятельно раздавать доступ.
• Убрать у редакторов `edit_php`, доступ к командной PHP-строке и полноценное редактирование исполняемых шаблонов.
• Закрыть запись в код сайта через файловый менеджер и дополнительные модули, сохранив загрузку разрешённых медиафайлов в предназначенные для этого поля.
• Отдельно проверить группы подрядчиков, интеграционные аккаунты, права по умолчанию и индивидуальные исключения: важны итоговые возможности учётной записи.

Как сохранить импорт, не возвращая полный доступ

Сначала я выясняю, что именно сотрудники называют импортом: ручную загрузку CSV или XML, обмен с 1С в CommerceML v2, профиль торгового каталога либо сторонний загрузчик Excel. Это разные механизмы с разными точками входа. Для ручного импорта документация требует уровень доступа к модулю «Торговый каталог» не ниже «Управление импортом/экспортом». Процедура запускается через «Магазин → Настройки → Импорт данных» с выбранным профилем. Эти требования приведены в уроке «Добавление товаров через импорт».

У стандартного компонента обмена с 1С точное имя — bitrix:catalog.import.1c. Он импортирует данные в формате CommerceML v2. Параметр GROUP_PERMISSIONS принимает список групп, которым разрешена загрузка каталога. Там же документированы ELEMENT_ACTION и SECTION_ACTION: значение N ничего не делает с отсутствующими объектами, A деактивирует их, D удаляет. Параметр FILE_SIZE_LIMIT задаётся в байтах и относится к единовременно загружаемой части файла, а не обязательно ко всему архиву. Проверенные названия и значения опубликованы в документации catalog.import.1c.

Разрешение группы в GROUP_PERMISSIONS не заменяет проектирование всей модели доступа. Компонент способен создавать инфоблок при первом импорте, обрабатывать предложения, цены, разделы и отсутствующие записи в зависимости от параметров. Я проверяю не только успешную авторизацию, но и выбранный тип инфоблока, действия над отсутствующими объектами, обработку изображений и возможность изменить параметры страницы с компонентом. Параметр SKIP_SOURCE_CHECK действительно существует и отключает проверку источника запроса; без отдельного обоснования я его не включаю.

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

Служебная учётная запись сама по себе проблему не решает. Если оператор может менять выполняемый PHP-код, путь к обработчику или произвольный серверный файл в задании, он всё ещё управляет исполнением. Штатные пользовательские шаблоны импорта торгового каталога — обычные PHP-скрипты. Они располагаются в /bitrix/php_interface/include/catalog_import/, рабочие файлы заканчиваются на _run.php, а необязательные мастера настройки — на _setup.php. Код шаблонов я храню в репозитории и меняю через проверку разработчиком. Точные пути и суффиксы указаны в документации шаблонов импорта.

У собственного обработчика проверяю авторизацию и право на целевой объект на сервере до записи данных. Для формы, работающей с cookie-сессией, проверяю CSRF-токен. Идентификатор инфоблока из браузера не считаю доверенным, а сам факт вызова API — доказательством проверки прав. Загруженному файлу сервер назначает имя; файл хранится вне публичного каталога. Изображения проверяются отдельно. Если процессу не нужны PHP-файлы, локальные пути и произвольные URL загрузки, обработчик их не принимает. В журнале сохраняю инициатора, профиль, хеш файла, число изменений и ошибки, но не пароли и не полные строки с секретами.

Практический разбор: пищевое производство «Хлебный край», 45 рабочих мест

Разберу учебный сценарий, а не пентест, приписанный реальному заказчику. Условный клиент — пищевое производство «Хлебный край», 45 рабочих мест. В модели четыре редактора, один оператор каталога, два администратора с отдельными техническими аккаунтами и 18 000 карточек в инфоблоке с ID 17. Для стенда закладываю 4 vCPU, 8 ГБ RAM и 80 ГБ SSD. Эти значения сохраняют исходные условия кейса и служат стартовой конфигурацией для функциональной проверки. Они не являются нормативом производительности магазина и не заменяют нагрузочное тестирование.

Окружение стенда — Debian 12, Nginx 1.22, PHP-FPM 8.3 и MariaDB 10.11.6 с обновлениями безопасности используемых веток. В официальном курсе 1С-Битрикс для Debian 12 перечислены Nginx 1.22 и MariaDB 10.11.6; штатный репозиторий этого выпуска предлагает PHP 8.2, а для PHP 8.3 документация предлагает подключать дополнительный репозиторий. Поэтому PHP 8.3 я не называю стандартным пакетом базового Debian-окружения. Источник — установка пакетов для Debian 12.

Историческое состояние для разбора — iblock 24.300.0 от 5 ноября 2024 года; оно предшествует исправлению и допустимо только в изолированной лаборатории. Контрольное состояние — iblock 26.0.0 от 8 июня 2026 года, опубликованное в истории версий на дату проверки. Между ними обязательно присутствуют 24.300.100 от 23 апреля 2025 года с усилением проверок и 24.300.200 от 29 апреля 2025 года с исправлением импорта файлов через административный CSV. Остальные модули обновляются согласованно штатным механизмом, потому что выбор одного номера iblock не гарантирует совместимость всей установки.

PHP 8.3 перешёл из активной поддержки в режим исправления критических проблем безопасности после 31 декабря 2025 года и получает такую поддержку до 31 декабря 2027 года. Это точные даты официальной таблицы поддерживаемых версий PHP. Сам календарь поддержки PHP не доказывает совместимость конкретного сайта: перед переводом стенда я проверяю ядро, решение, модули Marketplace, агенты и собственный код.

Исходная ошибка модели — общая группа всех пяти контентных пользователей с iblock_edit и управлением правами. Я заменяю её редакторским уровнем, а оператору добавляю доступ к ограниченному загрузчику. Спецификацию собственного обработчика фиксирую отдельно:

iblock_id: 17
match_key: XML_ID
allowed_fields:
  - NAME
  - PREVIEW_TEXT
max_file_size_mib: 20
max_rows: 20000
concurrent_imports: 1
delete_missing: false
allow_create: true

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

Для приёмки готовлю файл из 1 000 уникальных строк: 900 существующих карточек с изменёнными данными и 100 новых. Ожидаемый итог — 900 обновлений, 100 созданий и ноль удалений. Повторная загрузка того же файла не должна создавать дубликаты, потому что сопоставление выполняется по XML_ID. Отдельный файл с неизвестной колонкой отклоняется до записи. Ещё один отрицательный тест подменяет целевой ID 17 в запросе: обработчик должен проигнорировать клиентское значение или вернуть отказ, не затронув другой инфоблок.

Финальная матрица проверяема: у пяти контентных аккаунтов нет технических операций; оператор загружает файл фиксированного формата; два администратора управляют конфигурацией отдельными учётными записями. Это расчётный сценарий и критерии стенда, а не заявление о проведённом нагрузочном испытании. В протоколе не выдумываю длительность импорта или число запросов в секунду: эти величины появятся только после фактического прогона.

• Редактор создаёт карточку, исправляет текст и загружает разрешённую картинку; изменение параметров инфоблока и его прав отклоняется.
• Оператор загружает файл фиксированного формата и получает отчёт; выбрать другой инфоблок, новый набор полей или PHP-обработчик нельзя.
• Администратор меняет схему по заявке; после изменения команда повторно проверяет импорт и эффективные права всех ролей.
• В регрессионный набор входят изображения: в `iblock` 24.300.200 от 29 апреля 2025 года исправлялась ошибка административного CSV-импорта, при которой файлы не импортировались.
• После неуспешной или прерванной загрузки команда сверяет число записей, состояние блокировки импорта и возможность безопасного повторного запуска.

Что ограничиваю на сервере

Для стенда «Хлебного края» выделяю сайту отдельного пользователя ОС и отдельный пул PHP-FPM. В существующий и уже работоспособный конфигурационный файл пула добавляю или проверяю следующий фрагмент:

user = khlebweb
group = khlebweb
security.limit_extensions = .php

Пользователя и группу заранее создаёт администратор, затем согласует владельцев и режимы файлов. Это именно фрагмент: полноценному пулу также нужны обязательные параметры listen, pm и pm.max_children, значения которых зависят от архитектуры и нагрузки. Я не подменяю ими готовую конфигурацию.

В документации PHP-FPM user обозначен как обязательный Unix-пользователь процессов пула, а group — их Unix-группа; если группа не задана, используется группа пользователя. Директива security.limit_extensions ограничивает расширения основного скрипта, который FPM разрешит разбирать. Её значение по умолчанию — .php .phar, а ограничение до .php рекомендовано для снижения риска ошибок конфигурации веб-сервера. Директива не запрещает уже выполняющемуся PHP-коду подключать доступные ему файлы и не является самостоятельным исправлением LFI. Первичный источник — PHP-FPM Configuration.

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

Входящие CSV собственного загрузчика храню, например, в /srv/khlebny-kray/import-inbox вне DOCUMENT_ROOT. Это проектный путь, а не каталог из поставки 1С-Битрикс. Веб-сервер не публикует его через alias, а обработчик читает только назначенный сервером файл. Соседние сайты работают от других пользователей ОС и с отдельными учётными данными базы. Такая изоляция уменьшает радиус поражения одной установки, хотя не ограничивает права приложения внутри собственной базы.

Запрет исполнения PHP в каталоге загрузок полезен против прямой обработки загруженного файла веб-сервером, но не отменяет код, уже исполняемый приложением. Аналогично disable_functions не является песочницей. Руководство PHP говорит, что директива принимает разделённый запятыми список внутренних функций, задаётся на системном уровне и может быть обойдена, поэтому её нельзя считать достаточной защитой общего хостинга. Отключение shell_exec не лишает PHP доступа к базе и читаемым файлам. Мой порядок такой: обновления, минимальные роли, защита кода от записи, изоляция сайтов и только затем дополнительные ограничения с обязательной регрессией импорта и фоновых заданий. Источник — описание disable_functions.

Как принять работу и не вернуть опасные права

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

В расширенном режиме старый CIBlock::GetPermission применять для проверки прав нельзя: официальная документация помечает его устаревшим и прямо сообщает, что метод не работает с расширенными правами. Для существующего элемента разработчик проверяет конкретную операцию через CIBlockElementRights::UserHasRightTo. Минимальный пример вызова выглядит так:

$canEdit = CIBlockElementRights::UserHasRightTo(
    $iblockId,
    $elementId,
    'element_edit'
);

if (!$canEdit) {
    throw new RuntimeException('Access denied');
}

Сигнатура и имя операции сверены с официальной страницей CIBlock::GetPermission. Для создания элемента и работы с разделами нужны проверки соответствующего объекта и операции; показанный вызов не является универсальной авторизацией всего импорта.

В акте я хочу видеть установленные версии модулей, состав групп, матрицу операций, результаты положительных и отрицательных тестов импорта и проверку восстановления из резервной копии. Для штатного обмена прогоняются новые товары, изменения существующих, изображения, повторный пакет и прерванная загрузка. Отдельно фиксируется поведение элементов и разделов, отсутствующих в файле: значения A и D у ELEMENT_ACTION или SECTION_ACTION способны массово деактивировать либо удалить данные без всякой атаки.

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

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

Косметику административного меню и переименование старых групп можно вынести во второй этап. Нельзя откладывать установку исправлений и проверку эффективных полномочий. IT-директору нужен простой доказуемый результат: редакторы продолжают выпускать материалы, оператор обновляет каталог, а изменение серверной логики требует отдельного технического доступа. Если подрядчик не может показать версии, операции и протокол импорта, работа ещё не принята.

Частые вопросы