Почему в архиве платёжного плагина не должно быть ключей

Пакет плагина Paymos не несёт учётных данных. Архив, который мерчант скачивает для WooCommerce, Magento 2 или любого из шести остальных официальных плагинов, — это тот же самый архив, что скачивают все, и внутри нет ни API-ключа, ни API-секрета, ни идентификатора проекта, ни секрета вебхука, ни токена доступа, ни кода устройства. Само скачивание ничего не подключает.

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

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

Установка описана в руководстве по WooCommerce и на семи страницах рядом с ним. Здесь — слой под ними: что архив плагина в принципе способен нести, что несёт архив Paymos и как проверить тот, который выдаёт вам ваш шлюз.

Что лежит внутри пакета платёжного плагина?

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

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

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

Зачем вообще класть ключи в скачиваемый файл?

Ключи вписывают в скачиваемый файл, чтобы снять с мерчанта работу по настройке. Логика такая: магазин, которому нечего настраивать, должен был получить что-то, что уже знает, кому оно принадлежит, — иначе откуда бы взялось подключение. Довод держится ровно до вопроса, где именно эти ключи лежат.

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

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

MITRE описывает общий случай как CWE-798, Use of Hard-coded Credentials: «продукт содержит зашитые учётные данные, такие как пароль или криптографический ключ». Классический пример там — один секрет на все установки; сборка под мерчанта переворачивает это, давая каждому файлу свой, и сохраняет главное — живой секрет, лежащий в распространяемом файле.

Куда попадает архив плагина после скачивания?

Архив плагина не остаётся там, куда его скачали. Папка загрузок — первая остановка из нескольких, и ни одну из следующих не выбирали с мыслью о секрете внутри файла, потому что в эти минуты о нём никто не думает:

• Папка загрузок на ноутбуке, без шифрования, ровно столько времени, сколько её никто не разбирает.
• Ночная резервная копия сайта, а за ней каждая точка восстановления, которую эта копия породила.
• Вложение в обращение в поддержку — в ту минуту, когда мерчант отправляет «тот самый плагин» тому, кто ему помогает.
• Репозиторий сайта под контролем версий, рядом с темой оформления.
• Машина подрядчика: переслать файл — самый быстрый способ передать работу.

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

Как проверить, что присылает ваш шлюз?

Архив плагина проверяют так: распаковывают и обыскивают — до того, как он доедет до сайта. Три команды закрывают вопрос, ни одной из них не требуется согласие шлюза, и на любой машине это занимает пару минут.

# 1. распакуйте архив до того, как он попадёт в магазин
unzip -q plugin.zip -d pkg

# 2. поищите всё, что похоже на живые учётные данные
grep -rIn -iE 'api[_-]?key|secret|token|client_id|device_code' pkg

# 3. посчитайте хеш и сравните со второй загрузкой того же релиза
shasum -a 256 plugin.zip

Флаг -i во втором шаге не украшение: константу пишут и API_KEY, и ApiKey, и api_key, а поиск с учётом регистра проходит мимо двух вариантов из трёх. На публичном исходном коде плагина Paymos для WooCommerce этот шаблон даёт 65 строк с -i и 63 без него.

Читать совпадения нужно как имена полей, подписи и строки перевода, а не как находки. В том же дереве 38 из них лежат под tests/, где заготовки вида 'api_key' => 'pk_test_1234567890' стоят по замыслу. Останавливаться стоит на совпадении с настоящим значением вне тестовой папки.

Контрольная сумма закрывает то, на что поиск только намекает. Скачайте тот же релиз второй раз с другой машины и посчитайте хеш этой копии: архив, одинаковый для всех мерчантов, даст один и тот же хеш дважды, а собранный под аккаунт — не сможет.

Если в архиве пусто, откуда плагин берёт ключи?

Ключи плагин получает одним подтверждением. Поставьте релиз, нажмите в админке магазина «Подключить Paymos», подтвердите запрос во вкладке Paymos — и этот шаг выдаёт всё остальное. Полей для ручного ввода в нём нет ни одного:

• Ключи. Берётся активный платёжный ключ мерчанта, а если его нет — создаётся; тестовый и рабочий режим приходят вместе, поэтому переход на рабочий позже подключения не требует.
• Вебхук. Вебхук инвойсов регистрирует сама платформа: существующий используется повторно только при совпадении адреса, категории и проекта, а конфликтующий вебхук по тому же адресу молча не перезаписывается.
• Проект. В плагине он не выбирается вообще — привязывается тот, который открыт в панели, и второго выбора в этом сценарии нет.

Аргумент про экономию времени поэтому отвечает сам себе. Сборка под мерчанта покупает короткую настройку ценой секрета в файле; магазин, подключённый описанным способом, тоже ничего не настраивал, а файл, который он поставил, по-прежнему пуст. Экономить здесь попросту нечего.

Почему один архив годится всем мерчантам?

Один архив годится всем, потому что плагин — это код, а внутри кода аккаунта нет. Экосистемы CMS исходят ровно из этого, и правила распространения написаны вокруг такого допущения: каталоги, зеркала и страницы релизов устроены под один файл на версию, а не под индивидуальную сборку.

WordPress формулирует допущение прямо, правилом каталога: «Единственная версия плагина, которую распространяет WordPress.org, — та, что лежит в каталоге». Один артефакт на версию, отдаваемый всем, — это форма, в которой CMS ожидает получить плагин, каким бы каналом он ни пришёл.

Сборка под мерчанта ни в один такой канал не помещается. Её нельзя опубликовать как релиз, нельзя сверить с публичной версией и нельзя сравнить между версиями — просто потому, что единственной опубликованной версии, с которой сравнивают, не существует.

Paymos раздаёт свои восемь официальных плагинов публичными релизами: один пакет на платформу на релиз, и маршрут скачивания отдаёт именно этот статический файл. Каждый релиз даёт по одному архиву для WooCommerce и WHMCS, OpenCart и PrestaShop, Magento 2 и Shopware 6, CS-Cart и Easy Digital Downloads.

Что даёт пакет без секретов в обычной работе?

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

Передать файл разработчику, агентству или коллеге — значит не раскрыть ничего: архив Paymos и так есть у всех остальных. Переслать его почтой или в мессенджере можно так же спокойно — двигается не тот объект, который даёт доступ.

Ротация не требует свежего скачивания. Ключ и архив — разные объекты, поэтому после ротации всё, что нужно, — подключить магазин заново, и порядок этот один и тот же для ключа и для секрета вебхука. У секрета вебхука вдобавок есть период, в котором принимаются подписи и текущим, и предыдущим секретом.

OWASP ставит ротацию туда же: «Секреты следует регулярно ротировать, чтобы украденные учётные данные работали недолго». Ротация, которая начинается с повторного скачивания плагина, — это ротация, которую откладывают, а замена самого архива при этом остаётся операцией с кодом: секрету оттуда переезжать некуда, потому что его там не было.

Чего пустой архив не доказывает?

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

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

Второй — поведение на живом магазине. Архив — это снимок кода, поэтому чтение архива говорит, что плагин способен делать, а не что он делает, когда через него идут настоящие счета и настоящие деньги. Между снимком и работой лежит ещё вся конфигурация магазина.

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

Насколько узким должен быть сам ключ?

Ключ, попадающий в CMS, должен быть самым узким из тех, что справляются с задачей: магазин — общая машина, и папку плагинов читает любой, у кого есть админский доступ. Модель Paymos сужает его до того, как вопрос задан.

Подключение выдаёт платёжный ключ, а платёжные ключи и ключи выплат разделены, поэтому плагин оплаты никогда не держит тот, которым выводят средства. Тестовый и рабочий режим работают на разных ключах против одного и того же контракта API, поэтому ключ, на котором проверяли, — не тот, которым принимают настоящие платежи.

Ключ Paymos может нести список разрешённых IP-адресов, до 50 записей, и это привязывает его к адресам, с которых работает магазин. Копия такого ключа, предъявленная откуда-то ещё, отклоняется, поэтому ключ, вынутый из резервной копии, — уже не работающий ключ.

Аутентификация Merchant API — это подпись запроса по HMAC-SHA256, а не токен на предъявителя, поэтому секрет подписывает запрос, а не едет внутри него. Перехваченный запрос не даёт ключа для следующего, а модель ключей разобрана целиком отдельно.

Что спросить до установки платёжного плагина?

Четыре вопроса закрывают тему учётных данных в платёжном плагине. На все четыре можно ответить до того, как файл доедет до сайта, и ни одному из них не нужен доступ к чужой инфраструктуре.

1. Одинаков ли архив у всех? Посчитайте хеш своей загрузки, возьмите тот же релиз с другой машины и сравните.
2. Есть ли в архиве живое значение? Поищите в распакованных файлах строки, похожие на учётные данные; имена полей и заготовки находками не считаются.
3. Куда плагин кладёт учётные данные после подключения? Это место в документации, а не в ответе поддержки.
4. Насколько узок ключ, который он держит? Плагин оплаты с правами на вывод несёт больше, чем нужно для его работы.

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

Плагин — один из маршрутов от магазина до платёжной инфраструктуры. Другие способы принимать оплату на сайте разобраны отдельно, а интеграция через REST API — это как раз случай, когда проверять нечего, потому что архива нет. Каким бы маршрутом магазин ни пошёл, его ключ должен начинаться там, а не в файле, который уже успел попутешествовать.