Як відкликати 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-скрипти, де вони можуть залишитися в історії команд.
• Не вважайте відкликання завершенням інциденту без перевірки логів.