User enumeration — это определение злоумышленником реальных имен пользователей сайта. WordPress может раскрывать их через author-архивы, параметр ?author=1, REST API, RSS и различные сообщения на странице входа.
Само имя пользователя не дает доступа к панели администратора, но сокращает количество неизвестных для brute-force-атаки. Поэтому стоит минимизировать публичные подсказки, не создавая при этом ложного ощущения полной защиты: отдельно необходимы 2FA, ограничение попыток входа, обновления и надежные пароли.
Что такое 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 на страницу автора. Поэтому важно тестировать фактический ответ сервера, а не только внешний вид страницы в браузере.
Пример ниже предназначен для сайта, где author-архивы не нужны. Код лучше добавить в 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
Если author-архивы гарантированно не используются, логичнее возвращать статус 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.
- Настройте уведомления о неудачных входах и подозрительной активности.
- Регулярно проверяйте резервные копии и возможность восстановления.
Частые вопросы
Достаточно ли скрыть логин, чтобы защитить WordPress?
Нет. Это лишь уменьшает объем информации, доступной злоумышленнику. Для защиты нужны уникальные пароли, 2FA, ограничение попыток входа, обновления и контроль доступа.
Нужно ли полностью отключать REST API?
Не обязательно. REST API необходим многим темам, интеграциям и плагинам. Сначала проверьте, какие endpoint использует сайт, и ограничьте только публичную выдачу пользователей, если это не нарушает функциональность.
Можно ли просто переименовать admin в базе данных?
Не рекомендуется делать это без резервной копии и понимания структуры WordPress. Прямые изменения могут повлиять на интеграции и сторонние плагины. Для замены учетной записи лучше создать нового пользователя и корректно передать ему контент.
Влияет ли Elementor на user enumeration?
Сам Elementor не является причиной этой проблемы, но его шаблоны, формы и динамические виджеты могут показывать авторов или разные сообщения об ошибках. Отдельно проверьте публичные шаблоны и форму входа, если она создана через Elementor или сторонний плагин.
Вывод
Для базовой защиты WordPress закройте author-архивы, не публикуйте технические логины, унифицируйте сообщения формы входа и проверьте REST API и другие источники данных.
После этого протестируйте сайт без авторизации и дополните hardening двухфакторной аутентификацией, rate limiting, уникальными паролями и регулярными обновлениями. User enumeration не устраняется одной настройкой, но его устранение заметно сокращает объем информации, доступной автоматизированным атакам.