Безпечне завантаження файлів у WordPress та Elementor

Які ризики створює завантаження файлів

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

Навіть файл без виконуваного коду може становити проблему. У ньому можуть бути шкідливі макроси, небезпечні конструкції, надмірний розмір або дані, які розкривають приватну інформацію. Окрему увагу слід приділити SVG: це не просто зображення, а XML-документ, який може містити скрипти або зовнішні посилання.

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

• подвійні розширення: document.pdf.php або photo.jpg.phtml;
• невідповідність між розширенням, MIME-типом і реальним вмістом;
• надто великі файли, які витрачають дисковий простір або ресурси PHP;
• небезпечні формати: PHP, CGI, JS, HTML, PHAR та неперевірений SVG;
• доступ до приватних документів за прямим публічним URL.

Обмежте формати та розмір у формі Elementor

У полі завантаження Elementor Forms залишайте тільки ті формати, які справді потрібні бізнес-процесу. Для резюме це може бути PDF і DOCX, для фотографій — JPG та PNG. Не додавайте універсальні або потенційно небезпечні формати «про всяк випадок».

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

Встановіть максимально допустимий розмір, виходячи з реальної потреби. Для короткої заявки немає сенсу приймати файли на сотні мегабайтів. Перевірте, щоб ліміт форми не перевищував обмеження PHP та веб-сервера, інакше користувач отримає помилку ще до обробки WordPress.

• дозволяйте лише PDF, JPG, PNG або DOCX, якщо саме вони потрібні;
• забороніть множинне завантаження, якщо воно не використовується;
• обмежте кількість файлів на одну заявку;
• покажіть користувачу допустимі формати та максимальний розмір;
• перевірте сценарії з порожнім файлом, пошкодженим файлом і файлом із подвійним розширенням.

Перевіряйте MIME-тип і реальний вміст файлу

Розширення — це лише частина перевірки. Надійніша схема порівнює три значення: розширення, MIME-тип і сигнатуру або структуру файлу. MIME-тип, переданий браузером, також не можна вважати достовірним, адже його можна підробити.

Для зображень WordPress та PHP можуть перевіряти, чи справді файл є зображенням. Для PDF і DOCX варто перевіряти MIME-тип серверними засобами та обмежувати набір дозволених розширень. DOCX фактично є ZIP-контейнером, тому сам факт наявності ZIP-сигнатури ще не доводить, що документ безпечний.

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

Після перевірки генеруйте нове ім’я файлу, а не зберігайте оригінальне. Ім’я має містити випадковий ідентифікатор, дозволені символи та коректне розширення. Це зменшує ризик обходу правил через спеціальні символи, кодування або службові назви.

• не довіряйте заголовку Content-Type, який надіслав браузер;
• перевіряйте фактичний тип через серверні функції або бібліотеки;
• не дозволяйте файли з розширеннями PHP, PHTML, PHAR, CGI, JS та HTML;
• не перейменовуйте небезпечний файл у безпечний без перевірки його вмісту;
• видаляйте невдалі або підозрілі завантаження, а не залишайте їх у тимчасовій папці.

Забороніть виконання скриптів у папці uploads

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

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

• для Apache забороніть виконання PHP-подібних розширень у каталозі uploads;
• для Nginx додайте окреме правило, яке повертає 403 для спроб відкрити скрипт у uploads;
• не покладайтеся лише на заборону доступу до файлу .php — врахуйте phtml, phar та інші оброблювані розширення;
• після налаштування перевірте, що звичайні JPG і PDF відкриваються, а тестовий PHP-файл не виконується.

<FilesMatch "\.(php|phtml|php[0-9]?|phar)$">
    Require all denied
</FilesMatch>

# Для старих конфігурацій Apache може використовуватися:
# Deny from all

Приклад правила для Nginx

У Nginx правило додають у конфігурацію відповідного віртуального хоста. Шлях у регулярному виразі потрібно узгодити з фактичною URL-структурою сайту. Якщо сервер працює через проксі або CDN, тестування слід виконувати безпосередньо на origin-сервері.

• після зміни перевірте конфігурацію командою тестування, доступною у вашому середовищі;
• перезавантажуйте Nginx лише після успішної перевірки конфігурації;
• не копіюйте правило без адаптації, якщо uploads винесено в інший каталог.

location ~* /wp-content/uploads/.*\.(php|phtml|php[0-9]?|phar)$ {
    return 403;
}

Подбайте про зберігання та приватність файлів

Файли з Elementor можуть оброблятися самим WordPress, плагіном або інтеграцією, тому потрібно з’ясувати, де саме вони зберігаються і чи доступні за прямим посиланням. Не вважайте файл приватним лише тому, що користувач не бачить його в медіатеці.

Якщо документ містить резюме, договори, паспортні дані або іншу персональну інформацію, краще не залишати його у відкритій папці. Безпечніший підхід — зберігати файл поза публічним web root і видавати його лише після перевірки прав доступу через контрольований endpoint. Для тимчасових заявок використовуйте автоматичне видалення після завершення строку зберігання.

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

• визначте строк зберігання файлів у політиці сайту;
• видаляйте невикористані вкладення та тимчасові копії;
• не показуйте оригінальне ім’я файла в публічному URL;
• обмежте доступ до приватних документів перевіркою авторизації;
• переконайтеся, що резервні копії та журнали не містять відкритих посилань на персональні дані.

Регулярно перевіряйте uploads і журнали

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

Переглядайте каталоги медіа на незнайомі файли, несподівані розширення, файли з випадковими назвами та свіжі зміни, яких ніхто з адміністраторів не робив. Окремо перевіряйте файли .php, .phtml, .phar, .cgi, .js, .html і приховані файли.

Аналізуйте журнали веб-сервера та WordPress: спроби відкрити скрипти в uploads, численні помилки завантаження, запити до незвичних URL і повторювані звернення з однієї адреси можуть свідчити про автоматизоване сканування або атаку.

• виконуйте перевірку після кожного інциденту або підозрілої активності;
• зберігайте резервну копію до очищення, якщо потрібне подальше розслідування;
• видаляйте невідомі файли після перевірки їх походження, а не механічно стирайте все підряд;
• обмежте доступ до адміністративної частини та використовуйте унікальні паролі й 2FA;
• оновлюйте WordPress, Elementor, тему та плагіни з надійних джерел.

Типові помилки під час налаштування

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

Після внесення змін протестуйте завантаження з різними сценаріями: дозволений файл, заборонений формат, перевищення розміру, змінений MIME-тип, подвійне розширення, пошкоджений документ і спроба відкрити файл за прямою адресою. Тестуйте також від імені звичайного користувача, а не лише адміністратора.

• дозволяти всі формати, щоб не створювати помилок користувачам;
• змінювати лише налаштування Elementor і не перевіряти сервер;
• вважати MIME-тип із браузера доказом безпечності;
• залишати завантажені файли назавжди;
• забороняти весь каталог uploads і випадково ламати відображення зображень;
• забувати про DOCX, SVG та інші формати, які можуть містити активний або складний вміст.