10 вразливостей WordPress, про які варто знати. Захист сайту на WordPress

WordPress – найпопулярніша CMS у світі. Зважаючи на це, більшість зламів та вразливостей також припадають на WordPress-сайти. Це не означає, що WordPress має жахливу систему безпеки – порушення можуть траплятися і через недостатню обізнаність розробників та адміністраторів сайту. Тому краще застосовувати запобіжні заходи ще до того, як ваш сайт стане мішенню для хакерів.

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

Проблема 1. Вразливості сайтів-сусідів на сервері

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

А якщо з тієї самої IP раз за разом хтось розсилатиме спам-листи, можна ні за що нарватися ще й на фільтри поштових служб. 

Як вирішити проблеми зі спільною IP-адресою?

Скористайтеся послугою виділеної IP-адреси. На всіх тарифах VPS виділена IP зазвичай включена в тариф. А от якщо ви користуєтесь послугою віртуального Хостингу, купувати dedicated IP доведеться додатково. Зробити це максимально просто – додайте її при замовленні Хостингу або ж придбайте потім з Особистого кабінету. Наразі вартість виділеної IPv4-адреси в HostPro складає $3.00.

Проблема 2. Застаріле ПЗ

WordPress кайфовий тим, що його розробники приблизно що три місяці випускають оновлення, які покращують функціональність і виправляють критичні вразливості безпеки. 

Та водночас чуток про можливість “легко” зламати WordPress менше не стає. Уся комічність ситуації в тому, що зловмисникам навіть не треба шукати прогалини в безпеці, вони й так відомі за рахунок виправлення їх у наступній версії. До прикладу, у версії WordPress 5.8.1 виправили вразливість міжсайтового скриптингу (XSS) в редакторі блоків Gutenberg. Відповідно сайти зі старішими версіями WP вже опинилися під загрозою. 

За статистикою Sucuri, 50.3% зламаних WP сайтів були застарілими. Відсоток здається не таким лячним, як наприклад, 99% застарілих сайтів на Drupal, але варто врахувати, що чисельно 50% сайтів на WP – це набагато більше, ніж 99% сайтів на будь-якій іншій CMS.

Мало хто любить оновлювати WordPress, бо це, мʼяко кажучи, справа не 5 хвилин. До того ж, якщо сайт написаний не за документацією або це кастомна розробка, десь відсотків 90%, що після оновлення посипляться помилки, які призведуть до непрацездатності сайту. У таких випадках автоматичні оновлення, як правило, вимикають.

Як запобігти проблемам з оновленням WP?

Тільки оновленням WP. Робити це можна автоматично або вручну. Якщо ви на 100% впевнені в тому, що сайт не зляже після оновлення, можна сміливо вмикати автооновлення в адмінці, перейшовши за посиланням “Enable automatic updates for all new versions of WordPress” у розділі “Updates”. 

Якщо маєте свій софт, то краще підключити через файл wp-config.php автооновлення для мінорних версій, а мажорні оновлення виконувати вручну:

define('WP_AUTO_UPDATE_CORE', 'minor' );
/* That's all, stop editing! Happy publishing. */

Проблема 3. Застарілі теми й плагіни

Як і застаріле основне програмне забезпечення може наражати ваш сайт на небезпеку, так і застарілі теми та плагіни можуть прекрасно з цим впоратися.  

Згідно з даними WPScan, близько 97% вразливостей у їхній базі даних зосереджені саме в темах і плагінах. 

Що робити із застарілими темами і плагінами?

Автоматичне оновлення плагінів WP варто використовувати лише за умови створення регулярних резервних копій. А також, якщо встановлені доповнення рідко конфліктують після виходу оновлень або ж випускаються після попередніх бета-тестів.

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

Можна також керуватися правилом: ставити автоматичне оновлення на всі плагіни, окрім тих, які відповідають за структуру, дизайн та захист сайту. Бо, наприклад, доповнення для Elementor дуже люблять поводити себе непередбачувано.

Проблема 4. DoS і DDoS-атаки

Атака типу DoS, Denial of Service (“Відмова в обслуговуванні”) має на меті заблокувати адміністраторам сайту та відвідувачам доступ до нього. Це робиться шляхом надсилання такої кількості трафіку на цільовий сервер, що він виходить з ладу.

Є ще DDoS – це по-суті та сама DoS, але реалізована з кількох машин (утворюючи ботнет) на один цільовий хост. Це дозволяє приховати вихідне джерело трафіку та збільшує кількість спаму.

Як запобігти DoS і DDoS-атакам на WordPress?

Основна ціль DDoS  – хостинг-сервер, а от недоступність вашого WordPress сайту – це вже наслідок його непрацездатності. Саме тому так важливо обрати безпечний Хостинг під WordPress, який надасть вам кіберзахист корпоративного рівня або хоча б мінімізує даунтайми, які зазвичай виникають в таких випадках. 

Підтримка Hostpro надає захист від DDoS у кожному з тарифів віртуального Хостингу або VPS. Ми моніторимо усі сервери, на яких розміщені ваші сайти. І коли адміни помічають атаку, одразу ставлять IP на фільтр, все відбувається через власноруч розроблені скрипти і фільтри. За 20+ років на ринку кейсів успішної боротьби з DDoS більше, ніж достатньо. 

Утім, важливо розуміти, що цілковитого захисту від DDoS на практиці досягти майже неможливо. Вони бувають різної складності і щодня модифікуються. Можна, звісно, поставити зі свого боку додаткові фільтри, але вони, як правило, так сильно перевантажують сторінки, що користувачам доводиться чекати по 20 сек. 

От що можна зробити зі свого, клієнтського боку:

• підключити Cloudflare [для захисту від DDoS достатньо буде і безкоштовної версії];
• підключити капчу та cookie – вони будуть слугувати барʼєрами від ботів.

Проблема 5. Брутфорс-атаки

Brute-force, або так звані “атаки грубої сили” – вид зламу, при якому хакер або тестувальник методом перебору намагається вгадати дані для входу в систему. Класичний приклад – коли намагаються підібрати правильне імʼя користувача чи пароль шляхом перебору сотень комбінацій. 

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

Як запобігти bruteforce-атакам?

По-перше, створіть довгий надійний пароль, включно з цифрами, літерами у нижньому і верхньому регістрах та спеціальними символами – обовʼязково унікальний для кожного з облікових записів. І радимо припинити зберігати паролі в Google Таблицях чи Google Документах (вони в будь-який момент можуть потрапити у відкритий доступ). 

По-друге, підключіть двофакторну аутентифікацію. Так ви зможете двічі підтверджувати користувачів, які входять в адмінку вашого сайту. Зробити це можна через плагін WP 2FA. Ви будете додатково отримувати унікальний код на телефон або email при кожному вході в адмін-панель WP.

Проблема 6. SQL-ін’єкції

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

Якщо атака SQL-ін’єкції зайде занадто далеко, то зловмисник зможе навіть скомпрометувати базовий сервер або іншу внутрішню інфраструктуру. Іноді онлайн-шахраї можуть непомітно залишатися в такому “чорному вході” в систему надто довго, що в результаті призводить до довгострокових ризиків витоку інформації, штрафів і погіршення репутації. 

Як попередити SQL-ін’єкції на WP сайті?

• Використовувати динамічні запити лише за необхідності. До прикладу, в PHP замість динамічного SQL можна юзати PDO зі строгою типізацією параметризованих запитів. 
• Додати на сайт captcha й обмежити введення спеціальних символів у полях і формах для відвідувачів. Оскільки зловмисники часто використовують для SQL-ін’єкцій контактні форми й поля платіжної інформації, це може послугувати додатковим заходом безпеки. 
• У конфігураційному файлі .htaccess додати код:

RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC, OR]
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0 — 9A-Z]{0, 2}) [OR]
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0 — 9A-Z] {0,2})
RewriteRule ^(.*)$ index.php [F.L]

Щоб перевірити, чи не став ваш сайт жертвою SQL-інʼєкції, скористайтеся сервісами WPScan або Sucuri SiteCheck.

Проблема 7. Атаки CSRF

Підробку міжсайтових запитів (CSRF) зловмисники використовують для надсилання запитів від автентифікованого користувача до вебзастосунку. Жертва не бачить відповіді на підроблені запити, метод працює ніби “за лаштунками”, спричиняючи збої в роботі. CSRF-атаки можуть призвести до втрати конфіденційних даних, а також вплинути на якість обслуговування клієнтів, що може завдати шкоди репутації. 

Наприклад, Микола авторизований на сайті банку, у нього є сесія в куках. На пошті він знаходить лист із посиланням, яке насправді є фішинговим. Так він потрапляє на сторінку JavaScript, де викликається form.submit і відправляється форма на сайт, наприклад, mail.com. Цей сайт перевіряє кукі, бачить, що користувач залогінений і обробляє форму. 

Оскільки кукі перевіряють лише користувача, а не дані, які він відправляє, так Микола ненароком надсилає повідомлення від свого імені, але із вмістом, сформованим хакером.

Як захиститися від CSRF-атак (Cross-Site Request Forgery)?

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

Під час відправки форми сервер перевірить поле csrf, достовірність токена і лише після цього надішле повідомлення.

Проблема 8. Міжсайтовий скриптинг (XSS атаки)

Зовсім нещодавно, 6 травня, The Hacker News писали про плагін для створення кастомних полів на сторінках WordPress, який містив вразливості до XSS. 

Міжсайтовий скриптинг (XSS,Cross-Site Scripting) полягає в додаванні шкідливого скрипту в код сторінки сайту. За допомогою цього коду здійснюється крадіжка користувацьких cookies з подальшим використанням їх для атак. У браузері користувачів такий JavaScript код відображається як частина загального коду сайту. Водночас сам сайт стає співучасником XSS. 

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

Як боротися з міжсайтовим скриптингом (XSS)?

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

Здебільшого останні версїі движка, а також плагіни WP уже захищені від XSS, однак плагіни не з офіційного переліку, написані сторонніми розробниками, можуть мати таку вразливість. Тож старайтеся все ж оновлювати систему керування контентом WP, теми і плагіни та завантажувати останні лише з перевірених джерел, зокрема каталогу WordPress.org.  

Іншим корисним інструментом для запобігання XSS є фаєрвол вебдодатків (WAF), який перевіряє трафік і запобігає несанкціонованому входу у вашу систему із зовнішніх мереж. Якщо хтось здійснить на ваш WordPres-сайт XSS-атаку, фаєрвол позначить такий запит як підозрілий і заблокує хакерів ще до того, як вони отримають доступ до конфіденційних даних. Як варіант, можете розглянути загальний плагін безпеки, який просто буде включати в себе фаєрвол або підключити послугу CloudFlare.

Проблема 9. Скімінг кредитних карток

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

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

Як захистити дані карток від скімінгу?

1. Встановіть будь-який інструмент моніторингу для перевірки вашого сайту на наявність шкідливого коду. 
2. Оновлюйте сайт найновішими патчами безпеки.  
3. Використовуйте безпекові  інструменти, зокрема фаєрвол (або CloudFlare) і обовʼязково SSL-сертифікат для додаткового захисту сайтів і конфіденційної інформації. Як підключити до сайту SSL-сертифікат, читайте у нашій статті.

Проблема 10. LFI, RFI, RCE-атаки

LFI (Local File Inclusion) – атака, при якій хакер впливає на обробку даних таким чином, що сервер сприймає їх як шлях до локальних файлів і включає його у вихідну відповідь. 

RFI (Remote File Inclusion) – атака, при якій через зовнішній файл зловмисник може виконати код чи отримати доступ до конфіденційних даних на сервері. 

RCE (Remote Code Execution) – атака, при якій хакер може запускати віддалені програми чи виконувати команди ОС на скомпрометованому сервері. 

Як захистити сайт на WP від LFI/RFI/RCE-атак?

1. Виконуйте перевірку та фільтрацію вхідних даних. Щоб очистити вхідні дані, радимо використовувати функції filter_input() або sanitize_text_field().
2. Для обробки прикріплених файлів краще використовувати спеціальний сервер чи службу. 
3. Обмежте права доступу до файлів і папок. Можна дозволити права на читання/запис, і заборонити на редагування. Детальніше про найпопулярніші права доступу до папок та файлів та варіанти їх зміни читайте тут. 
4. Не забувайте про спеціальні фільтри для вхідних даних у формах та полях коментарів. 
5. Зверніть особливу увагу на захист API.
6. Користуйтесь загальними правилами безпеки, про які ми говорили раніше: вчасно оновлюйте ядро WP, плагіни й теми, використовуйте двофакторну аутентифікацію, фаєрволи, системи моніторингу вторгнень та відсіювання шкідливих запитів.

Хто відповідальний за безпеку сайту на WP?

Безпека будь-якого WordPress сайту лежить на трьох китах: власнику/розробнику сайту, WP комʼюніті та хостинг-провайдері.

Зона відповідальності власника/розробника сайту:

• вчасне оновлення версії WordPress;
• оновлення тем і плагінів;
• оновлення версій PHP;
• підключення CloudFlare або інших плагінів безпеки; 
• генерація надійних паролів та налаштування двофакторної аутентифікації;
• вибір безпечного постачальника послуг Хостингу;
• регулярне сканування сайту на вразливості безпеки.

Зона відповідальності спільноти WordPress:

• випуск оновлень та патчів для усунення вразливостей у старих версіях WP, темах і плагінах;
• підтримка тем та плагінів WordPress в актуальному стані;
• забезпечення бета-тестувань нових плагінів і тем; 
• дослідження для покращення безпеки ядра WordPress.

Зона відповідальності провайдера WordPress Хостингу

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

З кожним тарифом віртуального Хостингу в HostPro ви отримуєте:

• захист від DDoS; 
• цілодобовий моніторинг серверів; 
• технічну підтримку 24/7; 
• антивірус ImunifyAV +;
• щоденні бекапи;
• можливість придбати додатову IPv4 та безкоштовно підключити захисну послугу CloudFlare.  

На завершення

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

1. Слідкуйте за оновленням ядра WordPress, плагінів та тем, бо це основні джерела вразливостей.
2. Встановлюйте теми й плагіни лише з офіційних джерел, зокрема каталогу WordPress.org – так буде більше гарантій, що, по-перше, їх краще тестували перед випуском, по-друге, за їх оновленням та виправленням критичних вразливостей будуть слідкувати, і по-третє, що серед WP-комʼюніті можна буде підглянути вирішення своєї проблеми.
   Віддавайте перевагу плагінам іменитих розробників з найбільш актуальними оновленнями (наприклад, якщо плагін оновлювався ще 6 місяців тому, то ймовірно, він уже не зовсім “живий”). Бажано, щоб він тестився з актуальною версією WP. І, звісно, що більше встановлень, то краще. 
3. Використовуйте надійні паролі та припиніть зберігати їх в Google-доках чи таблицях.  
4. Підключіть двофакторну аутентифікацію.  
5. Використовуйте безпекові плагіни чи сервіси, що містимуть WAF (фаєрвол) та скануватимуть сайт на вразливості. Хорошим рішенням буде підключити хоча б безкоштовний CloudFlare.  
6. Хостіться в надійного провайдера WordPress Хостингу, який пропонує захист від DDoS, цілодобовий моніторинг серверів та підтримку 24/7.
7. Обмежте права доступу до файлів та папок. У класичному варіанті на всі папки встановлюють 755, на файли – 644. Іноді на папку wp-content ставлять права 777, але краще 755. 
8. Робіть резервні копії хоча б раз на добу або ж оберіть хостера, який робитиме це за вас і зберігатиме їх в архіві.

Бажаємо вам безпечної дивовижної подорожі у світі WordPress. Виникли запитання чи потрібна додаткова консультація? З радістю й безкоштовно допоможемо 24/7, просто напишіть запит у нашу техпідтримку або ж зателефонуйте.

Наш телеграм

з важливими анонсами, розіграшами й мемами

Приєднатися