🛡 Захист WordPress через пентести: посібник з харденінгу

Сайт на WordPress працює місяць, пів року, рік, а потім приходить лист від хостера: «З вашого акаунта розсилається спам». Або клієнт телефонує з криком, що головна сторінка тепер редиректить на фішинговий домен.

Стандартні чек-листи безпеки допомагають закрити базу: оновлення, складні паролі, бекапи. Але вони не показують, що саме зламається першим у вашому конкретному збиранні з трьох десятків плагінів, кастомної теми та правок у functions.php.

Пентест WordPress-сайту — це не просто «ще одна перевірка». Це осмислена атака на ваш сайт із подальшим документованим списком уразливостей, відсортованих за реальною небезпекою. А головне, з конкретними кроками, які закривають діри так, щоб вони не відкрилися після наступного оновлення.

💡 Швидкий огляд:

• Вийдіть за межі чек-листа безпеки: пентест дивиться на сайт очима атакувальника
• Знайдіть типові уразливості WordPress: від дебаг-логів у продакшені до XSS через форми
• Пройдіть повний цикл харденінгу: scope, fix, quick wins, retest, WAF-проксі
• Підготуйте сайт до пентесту правильно: стейджинг, тестові ролі, логування

Чому пентест ефективніший за чек-лист безпеки

Чек-лист — це про «зробив і забув». Вимкнув XML-RPC, встановив ліміт спроб входу, змінив префікс таблиць. Галочки проставлені, відчуття виконаного обов'язку присутнє.

Пентест перевертає картину. Він дивиться на сайт очима атакувальника, і часто знаходить те, чого в чек-листах немає. Наприклад, кастомний REST-ендпоінт, який розробник теми залишив без перевірки прав. Або два форм-плагіни, встановлені «про всяк випадок», де один не оновлювався два роки й тягне за собою вразливу бібліотеку.

Професійний пентест — це спланована процедура з фіксованим обсягом, задокументованими результатами та пріоритетними рекомендаціями. Від автоматичного сканера його відрізняє глибина: автосканер знаходить сигнатури відомих уразливостей, але сліпне на логіці користувацьких ролей, специфічній темі або самописних REST-маршрутах.

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

Три типові уразливості WordPress: як їх знаходить пентест

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

Приклад 1: небезпечна конфігурація хостингу та WordPress

Security Misconfiguration, одна з наймасовіших проблем. Зайві фічі увімкнені, стандартні обліковки не перейменовані, а повідомлення про помилки видають деталі оточення прямо в браузер. Частина проблем лежить на боці хостера, але WordPress дозволяє їх закрити.

Що бачить пентестер:

• Увімкнений лістинг директорій: будь-хто охочий переглядає вміст /wp-content/uploads/
• Дебаг-інформація у фронтенді: WP_DEBUG у true на продакшені
• Адмінка без додаткового захисту: прямий доступ до /wp-login.php без обмежень

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

Вимкнення WP_DEBUG у wp-config.php, перший і найшвидший фікс: одна константа прибирає всю дебаг-інформацію з публічного доступу.

Рішення, вимкнення дебагу на продакшені:

Закриття лістингу директорій на рівні сервера або через .htaccess.

Rate limiting на /wp-login.php відсікає брутфорс ще до того, як запит торкнеться WordPress.

Серверні захисні правила (WAF-правила на рівні хоста або CDN). Плагін Solid Security (колишній iThemes Security) закриває багато з цих векторів централізовано, безплатної версії достатньо для покриття бази.

Приклад 2: зоопарк плагінів і роздуті права

Регулярні оновлення ядра, тем і плагінів, база, про яку не втомлюються нагадувати всі посібники з безпеки. Але на практиці важливіший не факт оновлення конкретного плагіна, а загальна конфігурація інсталяції.

Підхід до харденінгу тут системний:

• Скласти повний інвентар плагінів і тем
• Видалити все невикористовуване
• Закріпити відповідальних за оновлення

Ролі та права, суворо за мінімальним принципом. Редактору не потрібен доступ до налаштувань плагінів, а SEO-спеціалісту, до встановлення тем.

Реальний кейс: сайт використовує два форм-плагіни «з історичних причин».

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

Приклад 3: ін'єкції та XSS через фронтенд

OWASP ставить ін'єкції на перше місце в рейтингу загроз. У WordPress вони виникають там, де розробник вважає користувацьке введення «безпечним за замовчуванням»:

• Форми зворотного зв'язку та підписки на розсилку
• Пошук і фільтри в магазинах і каталогах
• Коментарі та довільні поля (Custom Fields)

Базовий захист, чотири правила, які закривають більшу частину векторів:

• Валідувати вхідні дані на сервері (ніколи не довіряти клієнту)
• Екранувати вивід відповідно до контексту (HTML, JS, SQL, URL)
• Тримати плагіни в актуальному стані
• Періодично рев'юїти кастомний код теми

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

Процес гарденінгу WordPress: від звіту до захисту

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

Крок 1: визначте scope і пріоритети

Не кожна знахідка у звіті є критичною. Якісний звіт із пентесту містить severity, уражені URL та опис потенційної шкоди. Це дає змогу вибудувати порядок:

• Віддалено експлуатовані вразливості без авторизації (критичний пріоритет)
• Вразливості в зоні автентифікації з простим вектором атаки
• Помилки конфігурації та defense-in-depth (низький пріоритет, але масові)

Крок 2: впроваджуйте виправлення так, щоб вони пережили оновлення

Класичний біль: поставили фікс, за тиждень прилетіло автооновлення теми, і все злетіло. Місце встановлення фіксу визначає його живучість:

• Серверний рівень або хостинг: заголовки, TLS, rate limits, права доступу. Найнадійніше, живе незалежно від WordPress.
• Дочірня тема або чисті хуки: правки шаблонів і функціональності. Жодних прямих змін у батьківській темі.
• Заміна плагіна замість «плагіна-латки»: якщо компонент проблемний за своєю архітектурою, його простіше замінити на сучасний аналог, ніж нескінченно патчити.

Документація WordPress із гарденінгу описує типові точки та підкреслює важливість операційних практик: оновлення, контроль доступу, аудит. Іноді достатньо замінити пару застарілих компонентів, і security score сайту змінюється радикально.

Крок 3: почніть із quick wins

Швидкі перемоги, які дають непропорційно великий ефект:

• Скоротити кількість адмін-акаунтів, увімкнути двофакторну автентифікацію, задати мінімальну довжину пароля
• Перевірити XML-RPC: якщо не потрібен (немає підключення через застосунок або Jetpack), вимкнути. Якщо потрібен, захистити через той самий Solid Security
• Виставити права на файли та директорії: вебсервер повинен писати лише в ті папки, куди це справді потрібно. Із хостерами цей момент обговорюється окремо, не всі файлові маски однаково безпечні при зміні
• Протестувати не лише створення бекапу, а й відновлення з нього. Бекап без перевіреного restore — це хибний спокій

Крок 4: ретест обов’язковий

Фікс вважається закритим, лише коли його верифіковано. Повторний пентест перевіряє: чи справді вразливість усунено та чи не з’явилося побічних ефектів. Це критично для таких заходів, як Content Security Policy або суворі HTTP-заголовки, вони ламають фронтенд за найменшої помилки в конфігурації.

Крок 5: розгляньте WAF-проксі

Концепція файрвол-проксі ефективна та перевірена часом: кожен запит до сайту спочатку проходить через проксі-шар, де аналізується та фільтрується, і лише потім досягає вебсервера. Це блокує величезний пласт атак ще до контакту з WordPress. Sucuri, один із варіантів такого захисту. Альтернативи: Cloudflare WAF, Wordfence Premium з ендпоінт-захистом.

Як зробити пентест швидшим та ефективнішим

Пентест приносить максимум користі, коли умови підготовлені заздалегідь. Penetration Testing Execution Standard виділяє фазу Pre-Engagement, момент, де сторони узгоджують цілі, правила та межі тестування.

Що це означає для вас як власника WordPress-сайту:

• Staging-оточення замість продакшену: знижує ризик для живих користувачів і дає змогу тестувати агресивніше. Якщо стейджинг недоступний, хоча б клон на піддомені із закритим доступом за IP.
• Тестові акаунти з різними ролями: щонайменше редактор і адміністратор. Без цього перевірка авторизації безглузда.
• Увімкнене логування: події входу, зміни файлів, встановлення плагінів. Ці записи безцінні під час розбору інциденту.
• Узгодження зі сторонніми сервісами: якщо сайт інтегрований із платіжним шлюзом, CRM або системами трекінгу, заздалегідь визначте, що можна чіпати в ході тесту, а що не можна.

Наступні кроки після пентесту

1. Складіть інвентар плагінів і тем, видаліть невикористовуване, налаштуйте ритм оновлень

2. Перевірте ролі та адмін-акаунти, права суворо за мінімальним принципом

3. Налаштуйте staging-оточення та процес впровадження фіксів, стійких до оновлень

4. Підготуйте скриншоти для документування: огляд звіту, приклад запиту з реакцією, порівняння заголовків або конфігурації до/після.

5. Заплануйте ретест із конкретною датою, гарденінг не повинен зупинятися на припущенні «ми все полагодили».

Такий підхід перетворює пентест із разової «перевірки на дірки» на безперервний цикл: тестуємо, лагодимо, верифікуємо, повторюємо. Сайт з часом стає не просто «прикритим», а справді стійким до атак, і ви це знаєте не тому, що так написано в чек-листі, а тому що перевірка це підтвердила.

⁉️🤔 Часті запитання

Чи потрібен пентест, якщо я використовую Solid Security і роблю бекапи?

Плагіни безпеки закривають відомі вектори атак, але не бачать кастомних вразливостей: самописний REST-ендпоінт без перевірки прав, логіку переспрямувань у темі або дірку в покинутому плагіні, який значиться «активним». Пентест знаходить саме такі нестандартні точки входу. Бекапи ж не запобігають зламу, вони допомагають відновитися після. Це різні рівні захисту, і вони доповнюють один одного.

Чим пентест відрізняється від автоматичного сканера на кшталт WPScan?

WPScan перевіряє сайт за базою сигнатур: дивиться версію ядра, плагінів, тем і звіряє з відомими CVE. Це корисно для baseline-перевірки, але сканер не розуміє контексту. Він не бачить, що форма підписки віддає дані без валідації, а кастомна роль «менеджер магазину» випадково отримала права редактора тем. Пентестер (або ручний пентест) аналізує саме логіку застосунку, а не лише номери версій.

Як часто потрібно проводити пентест?

Після будь-якої значної зміни: велике оновлення ядра, зміна теми, додавання нового критичного плагіна (платежі, членство, кастомні поля). Для сайтів із високою ціною простою (інтернет-магазин, membership-портал) виправданий плановий пентест раз на 6-12 місяців. В ідеалі пентест стає частиною циклу розробки: викотили зміни → протестували на стейджингу → поправили → у продакшен.

Чи можна провести пентест самому, без залучення фахівців?

Базові кроки доступні: запустити WPScan, перевірити заголовки безпеки через Security Headers, пройтися за OWASP Top 10 для вебзастосунків руками. Але повноцінний пентест потребує досвіду: розуміння, як комбінувати вектор атаки, як читати відповіді сервера і як відрізняти хибне спрацювання від реальної дірки. Для комерційного сайту розумніше замовити пентест у профільної команди, а власні перевірки використовувати як гігієнічний мінімум між аудитами.

Що робити, якщо пентест знайшов десятки вразливостей, а бюджет на виправлення обмежений?

Пріоритизувати безжально. Перший ешелон: вразливості, які експлуатуються без авторизації (віддалений доступ до даних, RCE). Другий: проблеми в зоні автентифікації, які дають змогу підвищити привілеї. Третій: defense-in-depth (логування, заголовки, зайві відкриті порти). Quick wins із кроку 3 вище закривають багато пунктів малою кров’ю. Решту, у план із дедлайном, а не в беклог без строку.

Захист WordPress після пентесту: з чого почати вже сьогодні

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

Якщо бюджет на професійний пентест поки не закладено, почніть із того, що доступне просто зараз:

• Запустіть безкоштовний WPScan проти свого сайту (хоча б у пасивному режимі --no-banner --enumerate vp)
• Пройдіться по quick wins із кроку 3 — це займе годину й закриє найпоширеніші вектори атак
• Складіть інвентар усього, що встановлено в адмінці, і видаліть те, чим не користуєтеся понад місяць

Коли дійде до повноцінного пентесту, ви вже будете до нього готові: стейджинг піднято, плагіни під контролем, ролі почищені. Пентестер не витратить ваш бюджет на перелік того, що ви й так знаєте, а займеться реальними вразливостями. А це саме те, заради чого ви до нього прийшли.