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

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

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

Для меня редактор — человек, который меняет заголовок, описание, фотографию и другие согласованные данные. Администратор инфоблока определяет устройство хранилища и его поведение. В Битрикс эти действия различаются: element_edit означает изменение элемента, iblock_edit — изменение параметров инфоблока. Поэтому фраза «ему разрешено редактировать инфоблок» для согласования доступа слишком расплывчата. Нужно назвать операции, конкретный инфоблок и рабочую задачу. [Операции доступа к инфоблокам](https://dev.1c-bitrix.ru/api_help/iblock/classes/ciblock/getpermission.php).

Опасная организационная привычка выглядит безобидно: сотрудник не видит нужную кнопку, ему копируют права более опытного коллеги. Потом добавляют группу для импорта, затем временный доступ подрядчика. У роли остаётся прежнее название, а полномочия уже другие. Я начинаю проверку с итоговых прав конкретной учётной записи, включая все группы и наследование. Удалить разрешение из одной группы недостаточно, если другая продолжает его предоставлять. [Модель прав Bitrix Framework](https://docs.1c-bitrix.ru/pages/security/access-control.html).

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

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

Конкретный пример — PT-2025-28, он же BDU:2025-08666. Positive Technologies описывает выполнение произвольного кода при создании нового элемента пользователем, имеющим право редактировать свойства инфоблока. Уязвимы версии модуля iblock до 24.300.100; производитель подтвердил проблему. Оценка CVSS 4.0 — 8,9, причём вектор содержит PR:H: требуются высокие привилегии. Это хорошо показывает ошибку в терминологии: сотрудника могут считать непривилегированным, хотя выданные ему возможности уже привилегированные. [Бюллетень PT-2025-28](https://ptsecurity.com/research/threatscape/PT-2025-28/).

Вендор называет дефект Local File Inclusion при изменении свойств инфоблока. Речь о подключении серверного файла, которое при соответствующих условиях приводит к исполнению кода. Архитектурный контекст понятен из документации: настройки инфоблока содержат пути к пользовательской форме редактирования и обработчику полей перед сохранением. Эти возможности предназначены разработчикам. Однако открытые бюллетени не раскрывают точное поле эксплуатации, поэтому я не выдаю описание штатных настроек за проверенный маршрут атаки. [Карточка уязвимости](https://www.1c-bitrix.ru/vul/25346824/), [настройки инфоблока](https://dev.1c-bitrix.ru/user_help/content/iblock/iblock_edit.php).

Исправление вышло 23 апреля 2025 года в iblock 24.300.100. В истории версии указано усиление проверок доступа при редактировании настроек и проверки путей при импорте. На обновлённый сайт нельзя автоматически переносить вывод «iblock_edit равняется RCE»: это утверждение требует отдельного доказательства. Но и оставлять лишние технические полномочия после обновления я не вижу смысла. Проверять нужно версию установленного iblock и фактическое завершение обновлений; номер Главного модуля не заменяет эту проверку. [История версий iblock](https://dev.1c-bitrix.ru/docs/versions.php?lang=ru&module=iblock).

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

Для описанной роли я выбираю расширенное управление правами и собственный уровень с понятным составом операций. Сначала включаю этот режим на тестовой копии и проверяю наследование. Системный уровень не пытаюсь переписать под редакцию: создаю пользовательский через «Настройки → Пользователи → Уровни доступа», затем назначаю его нужной группе на нужном инфоблоке. Переход режима требует проверки действующих назначений, включая исключения для разделов и элементов. [Создание уровня доступа](https://dev.1c-bitrix.ru/user_help/settings/users/task_edit.php).

Список ниже — мой исходный набор ограничений. Для обычной работы оставляю element_read, section_read, element_edit; создание разрешаю через section_element_bind в согласованных разделах, показ в административной части — через iblock_admin_display. Создание и изменение разделов добавляю только тем, кто действительно управляет рубрикатором. Это не универсальная роль на все сайты: карточка торгового каталога, документооборот и пользовательские компоненты могут требовать дополнительных проверок. [Назначение операций](https://dev.1c-bitrix.ru/api_help/iblock/classes/ciblock/getpermission.php).

Удаление элементов, изменение цен и публикация без согласования — самостоятельные бизнес-риски. Я не называю их разрешениями на PHP и не запрещаю автоматически. Зато право менять PHP-код рассматриваю отдельно от инфоблоков: операция edit_php относится к Главному модулю и даёт весьма широкие возможности. Документация даже связывает с ней возможность авторизации под другим пользователем. Редактору такое полномочие не нужно для загрузки картинки или правки текста. [Документация управления пользователями](https://dev.1c-bitrix.ru/user_help/settings/users/user_admin.php).

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

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

Сначала я выясняю, что именно называют импортом: CSV элементов, перенос структуры через XML, обмен с 1С или сторонний загрузчик Excel. Это разные механизмы. Для импорта через модуль «Торговый каталог» документация выделяет уровень «Управление импортом/экспортом». У компонента обмена с 1С есть GROUP_PERMISSIONS — список групп, которым разрешена загрузка. Эти настройки дают отправную точку, но не гарантируют достаточность прав для любого профиля и любой версии. [Импорт товаров](https://dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=34&LESSON_ID=4515), [параметры обмена с 1С](https://dev.1c-bitrix.ru/user_help/components/content/1c_exchange/catalog_import_1c.php).

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

Само создание служебной учётной записи проблему не решает. Если пользователь может менять выполняемое PHP-выражение, путь к обработчику или произвольный серверный файл в её задании, он по-прежнему управляет исполнением. Более того, пользовательские шаблоны импорта каталога штатно являются PHP-скриптами. Поэтому код преобразований храню в репозитории, изменения провожу через проверку разработчиком, а оператору оставляю только согласованные параметры данных. [Устройство шаблонов импорта](https://dev.1c-bitrix.ru/api_help/catalog/templates_import.php).

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

Практический разбор: модельный стенд ООО «Вектор»

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

Окружение: Debian 12, Nginx 1.22, PHP-FPM 8.3 и MariaDB 10.11 с обновлениями безопасности выбранных веток. Вендор описывает эти ветки Debian, Nginx и MariaDB, а для PHP 8.3 — подключение дополнительного репозитория. Историческое состояние для разбора — iblock 24.300.0; целевое контрольное — 26.0.0, опубликованное 8 июня 2026 года. Остальные модули обновляются согласованно через штатный механизм. Старое состояние допустимо только в изолированной лаборатории. PHP 8.3 получает исправления безопасности до конца 2027 года; совместимость проектных модулей проверяется отдельно. [Окружение Debian](https://dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=32&LESSON_ID=31042), [версии iblock](https://dev.1c-bitrix.ru/docs/versions.php?lang=ru&module=iblock), [поддержка PHP](https://www.php.net/supported-versions.php).

Исходная ошибка модели — общая группа всех пяти контентных пользователей с iblock_edit и управлением правами. Я заменяю её редакторским уровнем, оператору добавляю доступ к ограниченному загрузчику. Настройки моего загрузчика фиксирую так: IBLOCK_ID=17, ключ сопоставления XML_ID, разрешённые поля NAME и PREVIEW_TEXT, максимум 20 МиБ и 20 000 строк, один одновременно выполняемый импорт, отсутствие в файле не вызывает удаление. Это спецификация собственного обработчика, не набор штатных флагов Битрикс. Создание новых карточек разрешено; изменение схемы и запуск пользовательского PHP отсутствуют.

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

• Редактор: создать карточку, исправить текст, загрузить разрешённую картинку; изменение параметров инфоблока и прав отклоняется.
• Оператор: загрузить файл фиксированного формата и получить отчёт; выбрать другой инфоблок или PHP-обработчик нельзя.
• Администратор: изменить схему по заявке; после изменения повторно проверить импорт и действующие роли.
• Проверка файлов: после обновления отдельно прогнать изображения. В iblock 24.300.200 от 29.04.2025 исправлялась ошибка импорта файлов через административный CSV — это реальная причина включить их в регрессионный набор. [История исправлений](https://dev.1c-bitrix.ru/docs/versions.php?lang=ru&module=iblock).

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

Для такого стенда выделяю сайту отдельного пользователя ОС и отдельный пул PHP-FPM. В существующем пуле задаю следующий фрагмент конфигурации: user = vector-web group = vector-web security.limit_extensions = .php Пользователя и разрешения файлов предварительно создаёт администратор. Последняя настройка ограничивает расширение основного скрипта, передаваемого FPM; она не запрещает приложению подключать другие файлы через include. Выдавать её за исправление LFI было бы ошибкой. [Настройки PHP-FPM](https://www.php.net/manual/en/install.fpm.configuration.php).

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

Запрет исполнения PHP в загрузках полезен, но относится к прямой обработке файлов веб-сервером. Он не отменяет код, который уже выполняется внутри приложения. Аналогично disable_functions не является полноценной песочницей: отключение shell_exec не отнимает у PHP доступ к разрешённым данным. Приоритет у меня такой: исправления, роли, защита кода от записи, разграничение сайтов. Тонкую настройку дополнительных ограничений делаю после этого, проверяя импорт и фоновые задания. [Ограничения директив PHP](https://www.php.net/manual/en/ini.core.php#ini.disable-functions).

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

Я принимаю такую настройку через два набора проверок: разрешённые действия работают, запрещённые отклоняются сервером. Исчезнувшая кнопка ничего не доказывает. На тестовой копии нужны прямые обращения к соответствующим обработчикам под непривилегированными аккаунтами, включая подмену целевого инфоблока в собственном загрузчике. Для проверки границ доступа не нужен веб-шелл: достаточно подтвердить отказ в изменении технических параметров и отсутствие изменений в данных. В расширенном режиме разработчик использует проверки UserHasRightTo, а не устаревший CIBlock::GetPermission. [Ограничения старого метода](https://dev.1c-bitrix.ru/api_help/iblock/classes/ciblock/getpermission.php).

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

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

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