fix(security): allowlist полей в процессорах покупателя и пользователя (#908)

[biz87]

Описание

Процессоры покупателя и пользователя, доступные через менеджерский connector, отдавали в ответе учётные колонки: у msCustomer — password и token, у modUser — password, cachepwd, salt, remote_key, remote_data.

Затронуты были четыре места, и три из них — за рамками исходного issue:

Процессор	Как утекало	Право
Customer\GetListCombobox	без combo возвращался полный toArray()	нет своего права
System\User\GetList	то же самое	нет своего права
Customer\GetList	getData() читает строки сырым fetchAll(), iterate() зовёт prepareArray() вместо prepareRow() — фильтровать было негде. Страница грида, то есть хеши и токены всех покупателей сразу	msorder_list
Customer\Get	cleanup() отдавал полный toArray()	msorder_view
Customer\Update	ядро само возвращает объект: UpdateProcessor::cleanup() → success('', $this->object) → modError::process() → toArray(). Пустой апдейт работал как способ прочитать хеш пароля любого покупателя	msorder_save

Все пять воспроизведены на стенде до правки.

Что сделано

Белый список вместо чёрного. В наборе это принятый подход, причём осознанный: CustomerPublicDto помечен как «fail-closed for new columns», CustomersController держит явные списки на чтение (formatCustomer()) и на запись ($allowedFields). Чёрный список fail-open: новая чувствительная колонка в ms3_customers утекла бы по умолчанию, пока кто-нибудь не вспомнит про список секретов.

Новый Services/Customer/CustomerManagerFields зеркалит formatCustomer() — то есть набор, который Vue-админка и так считает полным payload'ом покупателя. Через него проходят все четыре customer-процессора.

Секреты не доходят даже до объекта. getSelectColumns() в GetList и GetListCombobox получает список исключений ($exclude = true), поэтому хеш и токен не читаются из базы вовсе. Ограничение набора в PHP остаётся вторым рубежом — оно нужно, потому что GetList::getData() отдаёт строки сырым fetchAll().

Экстраполя покупателя едут вместе с белым списком. Колонка, зарегистрированная через msExtraField, в CustomerManagerFields::FIELDS не входит — fail-closed срезал бы её молча, а excludedColumns() ещё и не дал бы прочитать из базы. Между тем такие колонки живут в xPDO map (ExtraFields::addFieldToMap()), карту грузит плагин на OnMODXInit, и до правки эти процессоры экстраполя отдавали — то есть белый список сам по себе ломал бы работающую функциональность.

Решение то же, что в CustomerPublicDto::publicFieldKeys(): CustomerManagerFields::fieldKeys() расширяет базовый набор активными ключами из CustomerExtraFieldRegistry, а приватный NEVER_FIELDS не даёт экстраполю вернуть password или token обратно в ответ.

Чтобы не ходить в ms3_extra_fields на каждую строку грида, ключи резолвятся один раз на прогон — новый Processors/Customer/CustomerFieldAllowlistTrait (prepareRow() и prepareArray() вызываются построчно). В prepareQuery* ключи берутся отдельной строкой до getFieldMeta(): аргументы вычисляются слева направо.

System\User\GetList этого не касается — modUser не может быть хостом экстраполей, MigrationGenerator::canHostExtraField() требует класс из MiniShop3\Model\mysql\*.

System\User\GetList переведён на тот же приём: вместо списка секретов — белый список полей. Заодно перестали уходить hash_class, session_stale и remote_*.

Ветки combo не изменились — проверено на стенде, отдают прежние id + fullname и id + username + fullname.

Тип изменений

• Исправление бага (non-breaking change)
• Новая функциональность (non-breaking change)
• Breaking change (изменение, ломающее обратную совместимость)
• Рефакторинг (без изменения функциональности)
• Документация
• Другое (опишите):

Связанные Issues

Closes #908

Вопрос самих прав на эти процессоры здесь не решается и остаётся за #895: без combo ответ по-прежнему содержит PII покупателя (email, телефон, суммы заказов) и доступен любому с сессией админки. Комментарии в allowlist ProcessorPermissionsSmokeTest переписаны так, чтобы это было видно: учётные колонки закрыты, компромисс по правам стал уже, но не исчез.

Как это было протестировано?

cd core/components/minishop3
php tests/run-smoke.php          # OK smoke tests (128)
php vendor/bin/phpunit           # 860 tests, 3016 assertions, OK
cd ../../..
php core/components/minishop3/vendor/bin/phpstan analyse -c phpstan.neon --memory-limit=1G <изменённые файлы>   # No errors

tests/Unit/Processors/SecretFieldsTest.php — поведенческий, 16 тестов: обе ветки обоих combo-процессоров, строка грида вместе с actions, fail-closed на неизвестной колонке (recovery_code не проходит), состав исключений для SELECT, проброс зарегистрированного экстраполя через pick() и через excludedColumns(), запрет на возврат секретной колонки под видом экстраполя, нормализация ключей и то, что ключи резолвятся один раз на прогон, а не на строку.

Проверено, что тесты падают без фикса: при откате снятия колонок валится testCustomerRowWithoutComboHidesCredentials, при откате проброса экстраполей — три теста, включая оба процессорных (testCustomerGridRowReturnsRegisteredExtraField, testComboProcessorReturnsRegisteredExtraField).

tests/ProcessorSecretFieldsSmokeTest.php — страховка от отката при рефакторинге процессоров.

Живая проверка на MODX (runProcessor, стенд 1.14.2-beta1), до и после:

до правки:
  Customer\GetList  → !! password = $2y$10$r61P3rQtUpq…, token = 5414d64c50ad099378…
  Customer\Update   → !! password = $2y$10$IBzGqx5AL/m…, token = 49cf84e1366c1c35fe…

после правки:
  Customer\GetList             → 18 ключей (17 полей + actions), секретов нет
  Customer\Update              → 17 ключей, секретов нет, запись в базу работает
  Customer\Get                 → 17 ключей, секретов нет
  Customer\GetListCombobox     → 17 ключей, секретов нет
  Customer\GetListCombobox combo=1 → id, fullname
  System\User\GetList          → id, username, class_key, active, primary_group, sudo, createdon, fullname, email
  System\User\GetList combo=1  → id, username, fullname

Отдельно проверено, что Customer\Update по-прежнему сохраняет: поле в базе меняется, урезан только ответ.

Отдельно проверены экстраполя: завёл msExtraField с class = msCustomer (реальная колонка через xPDOManager::addField), записал значение и прогнал процессоры до и после правки.

на beta (до белого списка):
  Get / GetList / GetListCombobox / Update → экстраполе есть, но и секреты есть

белый список без проброса:
  Get / GetList / GetListCombobox / Update → секретов нет, но экстраполе пропало

текущее состояние:
  Get / GetList / GetListCombobox / Update → экстраполе есть, секретов нет
  combo-ветки                              → id + fullname, как и было
  System\User\GetList                      → экстраполей не бывает, секретов нет

• Ручное тестирование
• Автоматические тесты (composer ci:php / composer test, npm run lint:ci, composer stan / GitHub Actions CI)
• Тестирование на разных версиях PHP/MODX

Конфигурация тестирования:

• MiniShop3: 1.14.2-beta1 (ветка beta, c3c0929a)
• MODX: 3.1.2
• PHP: 8.3.25

Скриншоты (если применимо)

Не применимо: Vue не затрагивается. Админка ходит в REST (CustomersController), обращений к этим процессорам в репозитории нет — проверено грепом по src, config, vueManager/src, assets, _build, elements.

Чеклист

• Код соответствует стилю проекта
• Добавлены/обновлены комментарии в сложных местах
• Изменения не ломают существующую функциональность
• Лексиконы добавлены на двух языках (ru/en) — новых пользовательских строк нет
• PHPStan проходит без новых ошибок (composer stan / CI job PHPStan)
• ESLint проходит без ошибок (npm run lint:ci для Vue) — Vue не менялся
• Обновлён CHANGELOG.md (для значимых изменений) — запись добавляет maintainer при релизе

Дополнительные заметки

Набор CustomerManagerFields::FIELDS шире, чем formatCustomer(), на три поля: user_id, blocked_until, last_order_at. Они уже уходили этими процессорами и секретами не являются — убирать их в security-фиксе значило бы менять контракт сверх необходимого. Плюс, в отличие от formatCustomer(), набор расширяется экстраполями сайта.

Свести оба списка в один источник стоит отдельной правкой, вместе с переводом CustomersController::formatCustomer() на него — и там же решить, нужны ли экстраполя в REST-гриде админки.