В блоге Make WordPress Core появилось новое предложение, описывающее Secrets API, который запланирован к выпуску в WordPress 7.2. С помощью этого API в WP впервые появится нативный способ хранения учетных данных в зашифрованном виде.
Предложение было опубликовано контрибьютором Эриком Манном, который недавно присоединился к Automattic. Манн сказал, что создал прототип плагина 6 месяцев назад после обсуждения шифрования токенов для плагина Two Factor. Он вызвался самостоятельно реализовать этот проект для версии 7.2.
Как объяснил Манн, проблема заключается в том, что в WordPress в настоящее время нет концепции секрета. Каждый плагин, которому нужен API-ключ, записывает его в таблицу опций в открытом виде, поскольку это единственный вариант. В итоге учетные данные оказываются в дампах БД, в бэкапах и клонах тестовых площадок. Плагины, такие как Site Kit и WooCommerce, за эти годы разработали свои собственные системы шифрования, но единого стандарта пока нет.
«Было терпимо, когда средний сайт хранил ключ Mailchimp и секрет reCAPTCHA, — говорит Манн. – Однако интеграция ИИ-сервисов многократно увеличила количество учетных данных, и их потеря оборачивается теперь существенными затратами. Радиус поражения увеличился, в то время как механизм хранения остался прежним».
Проблемы безопасности, связанные с хранением API-ключей в виде обычного текста, стали горячей темой после выхода WordPress 7.0 с экраном AI Connectors в мае. Представитель команды безопасности WordPress Джон Блэкборн ранее уже указывал на этот архитектурный недостаток в Trac.
Манн предлагает внедрить в ядро небольшой набор функций — wp_set_secret(), wp_get_secret(), wp_delete_secret() – с шифрованием, которое нельзя отключить.
По умолчанию зашифрованные секреты будут храниться в существующей таблице опций в виде шифротекста. Хостинги смогут заменить ее своим собственным бэкендом хранения или системой управления ключами с помощью дополнительного модуля. API также поможет владельцам сайтов и хостингам отвечать на базовые вопросы: какие учетные данные существуют на сайте, какой код их использует и когда они были в последний раз обновлены.
Манн в своем предложении указал, чего API делать не будет. Любой код, выполняемый внутри процесса WordPress, по-прежнему может вызывать wp_get_secret(), поэтому нововведение не защищает от атак с выполнением кода. Но Манн утверждает, что гораздо более распространенной утечкой данных является кража БД, а не выполнение кода.
В описании релиза 7.2 основное внимание уделяется слою хранения данных, и создание административного интерфейса пока не планируется. Манн сказал, что сначала он хочет настроить семантику извлечения и хранения данных, а экран настроек появится уже в релизе 7.3. Поддержка WP-CLI для API будет включена с первого дня.
Предложение связано с уже ведущейся работой над WordPress AI. Джефф Пол, которому Манн выразил благодарность за то, что тот подтолкнул его к созданию прототипа, заявил в комментариях к предложению, что этот прототип стал основой эксперимента по шифрованию ключей в плагине AI.
Первые отзывы на предложение пока положительные. Инженер WordPress VIP Джейк Спурлок опубликовал в X, что API необходим, поскольку сообщество WP все больше полагается на агентские рабочие процессы.
Брайан Хаас, руководитель отдела веб-разработки и ecommerce в digicube AG, прокомментировал: «Полностью поддерживаю предложение. Я бы очень хотел увидеть его реализацию в Two Factor». Разработчик emrl сказал, что его команда недавно независимо спроектировала аналогичный продукт, используя библиотеку defuse/php-encryption, и назвал предложение «отличным».
Основатель GravityKit Зак Кац назвал это предложение давно назревшим в чате Post Status Slack, указав на давнюю проблему, когда плагины безопасности, автоматически меняющие соли WordPress, нарушают функционирование сохраненных лицензионных ключей его плагина.
Наиболее существенные замечания по дизайну поступили от старшего разработчика Pantheon Криса Рейнольдса, который в комментариях задал практический вопрос, касающийся хостинг-провайдеров с внешними хранилищами секретов.
«Наши секреты доступны в формате read-only из приложения; запись осуществляется через наш CLI-инструмент, Terminus или консоль», — сказал Рейнольдс, добавив, что в настоящее время API не позволяет узнать то, что бэкенд хранилища доступен для чтения, но не для записи. Он также отметил, что хранилища на уровне платформы обрабатывают свое собственное шифрование, откуда следует, что обязательный слой шифрования API будет дважды шифровать секреты и сделает их непрозрачными за пределами WP.
Манн планирует сначала выпустить функциональный плагин, чтобы участники проекта могли протестировать API до того, как что-нибудь из него появится в ядре. Он собирает отзывы по этому предложению; в конце сентября появится патч.
Бета-период для WordPress 7.2 стартует 20-22 октября. Манн сказал, что если API не будет готов к этому времени, то его отложат до версии 7.3.
