Как отозвать Application Passwords в WordPress после утечки

Почему смена пароля пользователя не решает проблему

Application Passwords предназначены для аутентификации приложений через API. Они хранятся как отдельные учётные данные, связанные с конкретным пользователем, но не являются копией его основного пароля.

Поэтому смена пароля для входа в административную панель обычно не отзывает уже созданные Application Passwords. Скомпрометированный токен может по-прежнему использоваться для REST API, пока его не удалят или не отзовут отдельной командой.

Во время инцидента следует считать токен полностью скомпрометированным. Не пытайтесь ограничиться изменением названия интеграции, переименованием пользователя или установкой нового основного пароля.

• Основной пароль пользователя и Application Password — разные учётные данные.
• Один пользователь может иметь несколько токенов для разных сервисов.
• Отзыв одного токена не влияет на остальные.
• Если неизвестно, какой токен был раскрыт, безопаснее отозвать все токены этого пользователя.

Подготовьтесь к отзыву токена

Перед выполнением команд определите учётную запись, которой принадлежал токен, и убедитесь, что у вас есть доступ к WP-CLI с достаточными правами. Для работы команд требуется подключение к нужной установке WordPress и доступ к её базе данных.

Если это активный инцидент, сначала сохраните доступные журналы веб-сервера, прокси, WAF, хостинга и REST API. Преждевременная очистка логов затруднит установление того, какие запросы выполнялись от имени скомпрометированной учётной записи.

Используйте числовой ID пользователя, если он известен. Так вы снизите риск отозвать токены не той учётной записи. Проверить пользователей можно стандартными командами WP-CLI, но не публикуйте их логины и другие идентификаторы в открытых отчётах.

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

Проверьте список активных Application Passwords

Начните с просмотра токенов, связанных с пользователем. Команда покажет записи Application Passwords, включая их названия, идентификаторы и дату создания. Сам секрет токена повторно не отображается — это нормальное поведение.

Сравните названия токенов со списком реальных интеграций: CRM, CI/CD, резервного копирования, мобильного приложения или локального скрипта. Обратите внимание на неизвестные записи, токены, созданные незадолго до инцидента, и ключи, которые давно не использовались.

• Неизвестное название токена может быть признаком несанкционированного создания.
• Дата создания помогает сопоставить токен с событиями в логах.
• Не удаляйте записи случайным образом, если интеграция критична для работы сайта.
• После утечки не считайте токен безопасным только потому, что его название кажется знакомым.

wp user application-passwords list USER_ID

Как отозвать один или все токены через WP-CLI

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

UUID нужно взять из результата команды list. Не путайте его с названием токена или самим секретом Application Password. После отзыва интеграция, использовавшая этот токен, потеряет доступ и потребует новый ключ.

Если токен невозможно идентифицировать, отзовите все Application Passwords пользователя. Это рекомендуемый вариант, когда ключ опубликован в открытом доступе, а журнал создания или использования токенов неполный.

• Отзыв конкретного токена сохраняет работоспособность других интеграций.
• Отзыв всех токенов потребует последующего выпуска новых ключей для каждого легитимного сервиса.
• После команды revoke проверьте результат повторной командой list.
• В производственном окружении предупредите владельцев интеграций о возможном прекращении доступа.

wp user application-passwords revoke USER_ID UUID

# Если неизвестно, какой именно токен скомпрометирован:
wp user application-passwords revoke USER_ID --all

# Повторная проверка списка:
wp user application-passwords list USER_ID

Создайте новый токен для конкретной интеграции

После отзыва создайте новый Application Password только для того сервиса, которому он необходим. Не используйте один токен одновременно для CI/CD, резервного копирования и сторонней автоматизации: отдельные ключи упрощают аудит и последующий отзыв.

Называйте токены понятно, например «staging-deploy», «crm-sync» или «backup-server». Название не является секретом и помогает понять назначение записи во время следующей проверки.

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

• Создавайте отдельный токен для каждой интеграции.
• Храните секрет в менеджере секретов или защищённых переменных окружения.
• Ограничьте права самого пользователя WordPress в соответствии с его задачей.
• Не передавайте Application Password в URL, скриншотах, issue или обычных чатах.
• После замены токена проверьте работу интеграции и её журналы.

wp user application-passwords create USER_ID "integration-name"

Проверьте, использовался ли токен злоумышленником

Отзыв останавливает дальнейшее использование конкретного токена, но не отменяет уже выполненные действия. После локализации инцидента просмотрите журналы веб-сервера, reverse proxy, WAF, хостинга и средств мониторинга.

Ищите запросы к `/wp-json/`, необычные HTTP-методы, массовые запросы к записям, пользователям и настройкам, а также активность в нетипичное время или с незнакомых IP-адресов. Сам факт запроса к REST API ещё не доказывает злоупотребление, поэтому сопоставляйте URL, время, пользователя, IP, user-agent и результат ответа.

Отдельно проверьте действия учётной записи: создание пользователей, изменение ролей, редактирование плагинов и тем, изменение контента, настроек и запланированных задач. Если токен принадлежал администратору, проверка должна охватывать всю установку, а не только одну конечную точку API.

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

Типичные ошибки при работе с Application Passwords

Самая распространённая ошибка — изменить только основной пароль пользователя. Это не отзывает отдельные Application Passwords, поэтому утечка остаётся актуальной.

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

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

Не передавайте токены в качестве параметров URL. Они могут попасть в историю браузера, журналы прокси, системы аналитики и заголовок Referer. Также не храните их в JavaScript, доступном посетителям сайта.

• Не полагайтесь только на смену основного пароля.
• Не храните токены в открытом Git-репозитории.
• Не используйте общий административный токен для всех сервисов.
• Не вставляйте секреты непосредственно в shell-скрипты, где они могут остаться в истории команд.
• Не считайте отзыв завершением инцидента без проверки логов.