Як захистити WordPress від user enumeration і визначення логінів

Що таке user enumeration у WordPress

User enumeration — це клас атак, під час яких автоматизований скрипт перевіряє, які логіни або імена авторів існують на сайті. Найчастіше зловмисник не атакує весь сайт навмання, а спочатку збирає список потенційних користувачів, адміністраторів і редакторів.

Для цього використовуються URL на кшталт /author/admin/, запити /?author=1, /?author=2 та послідовні ідентифікатори записів. Якщо WordPress або сервер перенаправляє такий запит на сторінку автора, у заголовку Location чи в URL може з’явитися логін.

Додатковим джерелом інформації є форма входу. Повідомлення на кшталт «користувача не існує» або «пароль неправильний» дозволяють відрізнити реальний обліковий запис від вигаданого. Це не є самостійною вразливістю, але спрощує підбір пароля.

• author-архіви та посилання на сторінки авторів;
• параметр ?author=1 та подібні запити з іншими ID;
• REST API, якщо публічно повертається список користувачів;
• RSS, sitemap або шаблони, де показується login чи user_nicename;
• різні повідомлення під час невдалого входу.

Закрийте author-архіви та запити ?author=

Якщо сайт не використовує публічні сторінки авторів, їх краще перенаправляти на головну або повертати 404. Це прибирає один із найпоширеніших способів отримання логінів.

Перевіряйте не лише URL /author/admin/, а й числові запити. У деяких конфігураціях WordPress спочатку обробляє ?author=1, а потім виконує canonical redirect на сторінку автора. Тому важливо тестувати фактичну відповідь сервера, а не тільки вигляд сторінки в браузері.

Нижче наведений приклад для сайту, де архіви авторів не потрібні. Код краще додати в site-specific plugin або mu-plugin, а не безпосередньо у файл теми: після зміни теми правило не зникне. Для початку використовуйте тимчасове перенаправлення 302, перевірте сайт, а потім за потреби змініть його на постійне.

• Не перенаправляйте авторські сторінки, якщо вони є частиною структури блогу або потрібні для SEO.
• Перевірте, чи не ламаються посилання в sitemap, RSS, хлібних крихтах і шаблонах Elementor.
• Перенаправлення на головну не повинно замінювати правильну авторизацію доступу до адмінпанелі.

add_action('template_redirect', function () {
    if (is_author() || get_query_var('author')) {
        wp_safe_redirect(home_url('/'), 302);
        exit;
    }
});

Коли краще повертати 404

Якщо авторські архіви гарантовано не використовуються, логічніше відповідати статусом 404, а не створювати ланцюжок перенаправлень. Реалізація залежить від теми, кешування та серверної конфігурації, тому її варто перевірити окремо. Просте перенаправлення на головну технічно легше, але воно не повідомляє пошуковим системам, що сторінка більше не існує.

• Не створюйте нескінченне перенаправлення, якщо головна сторінка також використовує авторські query-параметри.
• Після зміни очистіть кеш WordPress, CDN і reverse proxy, якщо вони є.

Не показуйте логін у профілі та публічних матеріалах

У WordPress логін користувача та його публічне ім’я — різні значення. Для записів, коментарів і профілю використовуйте нейтральне Display name: ім’я, назву команди або псевдонім. Не варто виводити на сайті значення, яке збігається з login.

Змінювати логін безпосередньо в базі даних небезпечно: це може пошкодити зв’язки, інтеграції, авторство записів або роботу сторонніх плагінів. Якщо старий логін уже відомий і його потрібно замінити, безпечніше створити нового користувача з правильними даними, передати йому контент і видалити або заблокувати старий обліковий запис після перевірки.

Особливу увагу приділіть адміністраторам. Не використовуйте очевидні логіни admin, administrator, webmaster або назву домену. Публічне ім’я автора може бути зрозумілим читачам, але не повинно збігатися з технічним логіном для входу.

• Перевірте авторів старих записів, сторінки команди, коментарі та віджети.
• Не вставляйте login у URL профілю без реальної потреби.
• Не передавайте імена користувачів у JavaScript, HTML-коментарях або відкритих API-відповідях.
• Для кожного сайту використовуйте окремі логіни адміністраторів.

Зробіть повідомлення входу однаковим

Форма wp-login.php або власна форма входу може розкривати, чи існує вказаний користувач. Для захисту використовуйте єдине нейтральне повідомлення незалежно від причини помилки: неправильний логін, пароль або неіснуючий обліковий запис.

Стандартний фільтр WordPress змінює текст помилки на сторінці входу. Це приклад для класичної форми wp-login.php; Elementor-форма або плагін членства можуть мати власні повідомлення, які потрібно налаштувати окремо.

• Не повідомляйте користувачу, що саме було неправильним — логін чи пароль.
• Переконайтеся, що повідомлення не відрізняється за HTTP-відповіддю, часом обробки або HTML-кодом.
• Не приховуйте повідомлення про блокування CAPTCHA чи 2FA: користувачу потрібно розуміти, яку додаткову дію виконати.

add_filter('login_errors', function () {
    return 'Невірні облікові дані.';
});

Перевірте REST API та інші публічні джерела

У частині конфігурацій запит до REST API може повернути список користувачів, наприклад через endpoint /wp-json/wp/v2/users. Навіть якщо author-архіви закриті, цей endpoint здатен розкрити імена, аватари та посилання на профілі.

Перед блокуванням REST API визначте, чи використовують його мобільний застосунок, редактор, інтеграції, WooCommerce або власний фронтенд. Повне відключення API може зламати функції сайту. Краще обмежувати саме публічний доступ до користувачів і тестувати це на копії сайту.

Перегляньте також RSS, sitemap, JSON-LD, коментарі, результати пошуку та шаблони Elementor. Плагін або власний код можуть виводити ім’я автора навіть після вимкнення стандартного архіву.

• Перевірте /wp-json/wp/v2/users у режимі без авторизації.
• Не відкривайте API ширше, ніж потрібно для роботи сайту.
• Не ховайте дані лише через CSS: вони все одно залишаться в HTML.
• Після змін перевірте кешовані відповіді CDN і серверного кешу.

Як перевірити сайт на user enumeration

Перевірку виконуйте в режимі інкогніто або без сесії адміністратора. Дивіться не лише на вміст сторінки, а й на HTTP-код, заголовок Location, фінальний URL і текст відповіді.

Для базової перевірки достатньо кількох запитів. Команди можна виконувати з комп’ютера, де доступна утиліта curl.

• Відкрийте /?author=1, /?author=2 та кілька наступних значень.
• Перевірте /author/admin/, /author/administrator/ та відомі старі імена авторів.
• Перегляньте /wp-json/wp/v2/users без входу в адмінпанель.
• Спробуйте увійти з реальним і вигаданим логіном та порівняйте повідомлення.
• Перевірте, чи не розкривають імена XML-RPC, RSS, sitemap або сторінки пошуку.

curl -I https://example.com/?author=1
curl -I https://example.com/author/admin/
curl -s https://example.com/wp-json/wp/v2/users
curl -s -X POST https://example.com/wp-login.php -d 'log=unknown-user&pwd=wrong-password'

Що ще потрібно для захисту входу

Приховування логінів зменшує обсяг інформації для автоматизованої атаки, але не зупиняє підбір паролів. Імена користувачів можуть бути отримані з витоків, фішингу, старих листів або інших сайтів.

Для повноцінного hardening налаштуйте багатофакторну автентифікацію для адміністраторів, rate limiting і блокування підозрілих запитів. Використовуйте унікальні довгі паролі, своєчасно оновлюйте WordPress, тему, плагіни та Elementor, видаляйте невикористовувані розширення.

На рівні сервера або WAF можна обмежити часті запити до wp-login.php та XML-RPC, але правила не повинні блокувати легітимних користувачів, вебхуки чи інтеграції. Перед змінами зробіть резервну копію і перевірте журнал помилок.

• Увімкніть 2FA щонайменше для адміністраторів і редакторів.
• Застосуйте обмеження частоти запитів до форми входу.
• Використовуйте окремі облікові записи, а не спільний admin.
• Налаштуйте сповіщення про невдалі входи та підозрілу активність.
• Регулярно перевіряйте резервні копії та можливість відновлення.