Безпека WordPress: типові відкриті місця і як їх закрити

Чому сайти на WordPress стільки показують

WordPress популярний і добре задокументований, тому автоматизовані інструменти точно знають, які адреси запитувати на кожному такому сайті. Багато з цих адрес за замовчуванням відповідають. Саме по собі це не вразливість, але дає нападникам фору: логіни, версії, а часом і файли, яким узагалі не місце в публічному доступі.

Розділи нижче впорядковано приблизно від найнебезпечнішого до найменш шкідливого. У кожному - як перевірити свій сайт і як виправити проблему. Замість your-site.example підставте свою адресу.

Відкриті резервні копії та копії конфігу

Копію wp-config.php із закінченням .bak, .old, .save чи ~ PHP не виконує. Вебсервер віддає її як звичайний текст - разом із паролем до бази даних і секретними ключами. Те саме стосується backup.zip чи dump.sql, залишених у корені сайту.

Як перевірити: відкрийте https://your-site.example/wp-config.php.bak і схожі назви. Будь-яка відповідь, крім 404 або 403, потребує уваги. А ще краще - перегляньте корінь сайту у файловому менеджері панелі хостингу.

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

Публічний debug.log

Коли увімкнено WP_DEBUG_LOG, WordPress за замовчуванням пише помилки у файл wp-content/debug.log. На багатьох серверах його може завантажити будь-хто. У ньому бувають шляхи до файлів, запити до бази даних, а іноді й токени чи паролі з повідомлень про помилки.

Як перевірити: відкрийте https://your-site.example/wp-content/debug.log.

Як виправити: на робочому сайті вимкніть журнал (define('WP_DEBUG_LOG', false); у wp-config.php) або вкажіть шлях поза коренем сайту, заблокуйте файли *.log у wp-content і змініть усі секрети, які потрапили в старий журнал. Довідник WordPress радить користуватися інструментами налагодження на локальній чи тестовій копії, а не на робочому сайті.

xmlrpc.php

xmlrpc.php - старий інтерфейс для віддаленої роботи із сайтом. Довідник WordPress називає його частою ціллю для підбору паролів, особливо через метод system.multicall, який дає змогу вмістити багато спроб входу в один запит.

Як перевірити: відкрийте https://your-site.example/xmlrpc.php. Повідомлення «XML-RPC server accepts POST requests only.» означає, що інтерфейс увімкнено.

Як виправити: якщо ви ним не користуєтеся, заблокуйте його у вебсервері або плагіном безпеки. Він потрібен Jetpack і мобільним застосункам WordPress; якщо без нього не обійтися, обмежте частоту запитів і захистіть його правилами фаєрвола.

Перелік авторів

На багатьох сайтах WordPress адреса /?author=1 перенаправляє на /author/<імʼя>/. Це імʼя - slug автора в адресі, який за замовчуванням утворюється з логіна. REST API за адресою /wp-json/wp/v2/users теж може показати список авторів зі slug.

Логіни за задумом не є секретом, але коли їх відомо, нападнику лишається вгадати тільки пароль.

Як виправити: заблокуйте запити ?author=N правилом перенаправлення або плагіном безпеки, обмежте доступ до списку користувачів у REST API для незалогінених відвідувачів, зробіть логіни адміністраторів відмінними від публічних імен і увімкніть двофакторну автентифікацію та обмеження спроб входу.

Витік версій

WordPress додає до сторінок тег generator на кшталт <meta name="generator" content="WordPress 6.x">, а в кожній інсталяції є readme.html і license.txt. У плагінів є файли readme.txt, де рядок «Stable tag» зазвичай називає версію плагіна, а посилання на ресурси часто закінчуються на ?ver= з номером версії.

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

Як виправити: приберіть тег generator (add_filter('the_generator', '__return_empty_string'); у дочірній темі або невеликому плагіні) і заблокуйте у вебсервері readme.html, license.txt та readme.txt плагінів, бо WordPress відновлює файли ядра після кожного оновлення.

Застаріле ядро, плагіни й теми

Це найважливіше. Вразливості старих плагінів і тем публікують, і будь-хто, зокрема автоматизовані інструменти, може знайти їх для тих версій, які показує ваш сайт.

• Оновлюйте ядро, плагіни й теми, попередньо зробивши резервну копію, і не вимикайте автоматичні малі оновлення ядра.
• Видаляйте плагіни й теми, якими не користуєтеся, а не просто деактивуйте.
• Замініть плагіни, які більше не підтримуються розробниками.
• Тримайте і PHP на підтримуваній гілці; ось як перевірити версію PHP.

Що ZNIMOK виявляє на WordPress

Коли перевірка розпізнає WordPress, вона робить звичайні GET-запити й аналізує відповіді:

Перевірка не підбирає паролі, не надсилає XML-RPC-викликів і не запитує список користувачів через REST API. Виявлена версія - привід перевірити, а не доказ вразливості сайту. Запустіть перевірку безпеки WordPress, щоб побачити, що з цього показує ваш сайт.