Шкідливий код у WordPress не завжди видно у файлах теми чи плагінів. Після злому він може зберігатися безпосередньо в базі даних: у налаштуваннях сайту, текстах публікацій, віджетах, меню або метаданих. Така ін’єкція здатна непомітно перенаправляти відвідувачів, створювати приховані посилання, підвантажувати скрипти чи повертатися після видалення зараженого файлу.
Перед будь-якими змінами необхідно створити резервну копію файлів і бази даних. Навіть пошкоджена база може містити важливі матеріали, а необережне виконання SQL-запиту здатне видалити записи без можливості простого скасування. Якщо доступ до сайту обмежений або зараження масштабне, доцільно спочатку звернутися по Відновлення бази даних сайту після пошкодження.
Де зберігається заражений код
У типовій інсталяції WordPress дані зберігаються в таблицях бази, назви яких залежать від префікса, заданого під час встановлення. Найчастіше перевіряють такі таблиці:
wp_options— глобальні налаштування, віджети, параметри плагінів і службові значення;wp_posts— записи, сторінки, чернетки, меню та інші типи контенту;wp_postmeta— додаткові поля та налаштування окремих матеріалів;wpterms,wpterm_taxonomyі пов’язані таблиці — категорії, мітки та таксономії;wpusersіwpusermeta— облікові записи та їхні параметри.
Зловмисники часто маскують фрагменти через кодування, довгі рядки, виклики eval, base64_decode, gzinflate або вставки JavaScript. Водночас наявність окремого слова чи функції ще не доводить зараження: легітимні плагіни також можуть використовувати серіалізацію та технічне кодування.
Ознаками можливого зараження є поява невідомих адміністраторів, раптові зміни URL сайту, сторонні скрипти, незнайомі віджети, перенаправлення для окремих користувачів і записи, яких немає в адмінпанелі. Перевірку слід проводити не лише за датою зміни, а й у контексті встановлених плагінів, тем і фактичної поведінки сайту.
Підозрілі записи options
Таблиця wp_options є однією з найпоширеніших цілей для прихованого коду. Шкідник може додати новий запис із випадковою назвою або змінити вже наявне значення. Особливу увагу варто приділити полям, у яких:
- значення містить великий незрозумілий рядок;
- зустрічаються закодовані фрагменти, HTML або JavaScript без очевидної причини;
- параметр має ознаку автоматичного завантаження —
autoload; - назва нагадує системну, але не відповідає жодному встановленому компоненту;
- запис з’явився приблизно в момент виникнення проблеми.
Для початкового аналізу можна переглянути список параметрів через phpMyAdmin або інший інструмент керування базою. Не слід одразу видаляти всі довгі чи закодовані значення: у WordPress це можуть бути серіалізовані налаштування плагінів. Пошкодження такого поля іноді призводить до помилок усього сайту або втрати конфігурації.
Безпечніше спочатку експортувати підозрілий запис окремо, зафіксувати його назву та значення, а потім порівняти з чистою копією бази або документацією відповідного плагіна. Якщо шкідливе значення завантажується автоматично, після очищення потрібно також перевірити файли WordPress і планувальник завдань: інакше код може бути записаний назад.
Ін’єкції в публікаціях
Ін’єкції часто приховують у вмісті публікацій і сторінок. У результаті в кінці матеріалу з’являються невидимі посилання, iframe, рекламні блоки або скрипти, які не відображаються у звичайному режимі редактора. Перевіряти потрібно не тільки опубліковані записи, а й чернетки, шаблони, меню та записи користувацьких типів.
У таблиці wp_posts підозрілими можуть бути:
- HTML-конструкції з прихованими стилями, наприклад
display:none; - iframe або скрипти на невідомі домени;
- посилання з неприродними анкорами та великою кількістю ключових слів;
- фрагменти, що повторюються в багатьох матеріалах;
- зміни, яких не робили адміністратори сайту.
Пошук за окремими тегами не завжди достатній, оскільки код можуть розбивати на частини, кодувати або додавати через шорткод. Результати потрібно перевіряти вручну, зберігаючи оригінальний текст. Масова заміна без розуміння структури HTML може пошкодити розмітку, вбудовані відео, галереї та серіалізовані дані.
Якщо зараження стосується великої кількості записів, важливо встановити джерело ін’єкції. Окрім бази даних, перевіряють облікові записи, файли теми, плагіни, права доступу та журнали сервера. Просте видалення видимого коду без усунення вразливості часто дає лише тимчасовий результат.
Безпечне очищення SQL
SQL-запити можуть бути корисними для пошуку та пакетного очищення, але вони мають підвищений ризик. Перед виконанням будь-якої команди потрібно перевірити назву бази, префікс таблиць і зробити актуальну резервну копію. Бажано спершу виконувати запит у режимі вибірки SELECT, щоб побачити майбутні результати, і лише після перевірки переходити до зміни даних.
Не варто застосовувати універсальні команди на кшталт безумовного DELETE або масової заміни за коротким словом. Одна й та сама послідовність символів може бути частиною легітимного контенту, URL, налаштування плагіна або серіалізованого масиву. Особливо обережно потрібно працювати з полями, які містять serialized data: звичайна текстова заміна може зламати довжину рядка та зробити значення непридатним для WordPress.
Рекомендована послідовність така:
- зберегти повний дамп бази та окрему копію файлів;
- визначити точні таблиці й записи, що мають ознаки зараження;
- експортувати вибрані рядки перед редагуванням;
- перевірити результати обмеженого
SELECT-запиту; - виконати мінімальну зміну лише для підтверджених шкідливих даних;
- перевірити сайт і за потреби відновити коректну копію.
Якщо невідомо, які поля належать плагінам, у базі є помилки або резервна копія не перевірена, краще не виконувати SQL самостійно. Некоректне очищення може призвести до втрати контенту, помилки «Error establishing a database connection» або пошкодження структури даних.
Перевірка після ремонту
Після очищення бази даних робота не завершується. Потрібно перевірити сайт у режимі інкогніто та з різних пристроїв, переглянути головну сторінку, публікації, форми, кошик, особистий кабінет і сторінки, які раніше перенаправляли відвідувачів. Окремо варто очистити кеш WordPress, плагіна кешування, CDN і браузера.
Подальша перевірка має охоплювати:
- файли ядра WordPress, тем і плагінів за допомогою відомої чистої копії;
- список адміністраторів і невідомі облікові записи;
- права доступу до файлів, бази, хостингу та поштових скриньок;
- cron-завдання, які можуть повторно запускати шкідливий код;
- журнали сервера та помилки PHP;
- автоматичне створення нових підозрілих записів після очищення.
Після підтвердження ремонту потрібно змінити паролі адміністратора, хостингу, FTP або SSH і бази даних, оновити WordPress, тему та плагіни, а невикористовувані компоненти видалити. Резервні копії слід зберігати окремо та періодично перевіряти їхнє фактичне відновлення.
Звернення до спеціаліста потрібне, якщо вірус повертається, немає доступу до бази, пошкоджено таблиці, сайт показує різний вміст ботам і людям або незрозуміло, яка копія є чистою. У таких випадках спочатку проводять діагностику, щоб не втратити залишки даних і визначити безпечний порядок відновлення.