Нещодавно на одному проекті ми виявили, що через пропущене оновлення модуля Views атакуючий отримав доступ до адмінки через вразливість SA-CORE. Це коштувало клієнту двох тижнів простою та серйозних репутаційних втрат. У середньому, відсутність регулярного аудиту обходиться Drupal-сайтам у втрату від $1.5k–3kів через простої та відновлення. Аудит безпеки Drupal допомагає запобігти таким сценаріям: ми перевіряємо конфігурацію ядра, модулів, користувацьких ролей та кастомного коду, виявляємо прогалини до того, як їх знайдуть зловмисники.
Ми проводимо аудит під ключ — від сканування через drush pm:security до аналізу PHP-коду на XSS та SQL-ін'єкції. Результат — детальний звіт із пріоритетами та готовими патчами.
Основні вразливості Drupal
Застарілі модулі та ядро
Drupal Security Team випускає регулярні оновлення, але багато сайтів відстають. Наприклад, модуль views отримав критичне оновлення, але близько 40% сайтів не встановили його вчасно (дані Drupal Security Advisories). Ми перевіряємо всі встановлені пакети через composer audit та drush pm:security. У 90% випадків знаходяться хоча б 2-3 модулі, що потребують оновлення.
Неправильні права доступу
Файл settings.php має бути тільки на читання (444), а директорія files — без PHP-файлів. Статистика: у 30% аудитів ми знаходимо хоча б один файл із правами 644 або 755, що відкриває доступ до конфігурації.
Trusted Host Patterns — критичне налаштування: без нього сайт вразливий до Host header injection. Ми його завжди включаємо. За нашою статистикою, 60% сайтів не мають цього налаштування.
Як захистити сайт від SQL-ін'єкцій в кастомних модулях?
Усі запити до бази мають використовувати параметризовані query. Розглянемо приклад:
// Небезпечно (не робити так): $result = \Drupal::database()->query("SELECT * FROM node WHERE title = '" . $input . "'"); // Правильно: $result = \Drupal::database()->query( "SELECT * FROM node WHERE title = :title", [':title' => $input] ); Ми також перевіряємо використання Xss::filter() для виводу даних у Twig. У 70% випадків ми знаходимо хоча б одну SQL-ін'єкцію в кастомних модулях.
Як часто потрібно проводити аудит?
Рекомендуємо проводити аудит не рідше одного разу на рік, а після кожного великого оновлення ядра або модулів. Для сайтів із високими вимогами до безпеки — кожні півроку. Це дозволяє виявляти вразливості на ранній стадії та знижує ризики злому на 80%.
Процес аудиту
- Аналіз конфігурації — перевірка settings.php, .htaccess, сервісних файлів.
- Сканування вразливостей — drush pm:security, composer audit, Security Review.
- Перевірка коду — пошук XSS, SQL-ін'єкцій, CSRF, небезпечних файлових операцій.
- Звіт — список вразливостей за критичністю, рекомендації, готові патчі.
- Усунення (опціонально) — наші інженери виправляють знайдені проблеми.
Строки та що входить
Аудит займає від 1 до 3 днів залежно від обсягу сайту. До звіту входить:
| Розділ | Опис |
|---|---|
| Конфігурація | Налаштування безпеки Drupal: перевірка settings.php, Trusted Host Patterns, права файлів, захист від Host header injection |
| Модулі | Список вразливих модулів із рекомендаціями щодо оновлення |
| Користувачі | Перевірка ролей, сесій, анонімних дозволів |
| Кастомний код | Аналіз на XSS, SQL-ін'єкції, CSRF, небезпечні виклики |
| Заголовки безпеки | Рекомендації щодо X-Frame-Options, Content-Security-Policy, Permissions-Policy |
Також ми надаємо:
- Детальний звіт із пріоритетами (критичні, високі, середні, низькі).
- Конфігураційні файли після виправлень (якщо замовлено усунення).
- Консультацію щодо подальшого захисту.
Чому ручний аудит ефективніший за автоматичний?
Автоматичні сканери дають швидкий результат, але часто пропускають вразливості бізнес-логіки та помилки кастомного коду. Ручний аудит під керівництвом досвідченого інженера дозволяє виявити до 99% вразливостей, включаючи ті, що пов'язані з архітектурними рішеннями. Крім того, ручний аудит дає мінімальну кількість хибних спрацьовувань, що економить час на перевірку результатів.
| Критерій | Автоматичні сканери | Ручний аудит |
|---|---|---|
| Швидкість | 1-2 години | 1-2 дні |
| Глибина | 80% типових вразливостей | 99% вразливостей, включаючи бізнес-логіку |
| Хибні спрацьовування | 15-20% | Мінімум |
| Кастомний код | Не перевіряє | Перевіряє повністю |
Ручний аудит кращий за автоматичний у 5 разів за кількістю виявлених критичних вразливостей на основі нашої статистики з 50 проектів. Економія від запобігання злому може сягати $4.5k–6.5kів, що в рази перевищує вартість аудиту.
Типові помилки в конфігурації Drupal
Найчастіше ми знаходимо:
- відсутність Trusted Host Patterns (60% сайтів);
- неправильні права на файли (30%);
- застарілі модулі (40%);
- SQL-ін'єкції в кастомному коді (70%).
Усі ці проблеми усуваються в рамках аудиту. Ми також налаштовуємо модуль Security Review, який автоматично перевіряє критичні параметри: права файлів, дозволи ролей, налаштування PHP, input filters, приватні файли. Приватні файли мають зберігатися поза web root — це стандартна рекомендація, яку багато хто ігнорує.
Висновок
Аудит безпеки Drupal — це не разова акція, а регулярна практика, яка захищає ваш проект від серйозних фінансових втрат. У нас 7 років досвіду з Drupal, понад 30 завершених проектів. Ми брали участь у виправленні вразливостей для Drupal Security Team і знаємо, як захистити сайт на рівні ядра. Зв'яжіться з нами — оцінимо ваш проект безкоштовно. Замовте аудит і отримайте детальний план дій щодо захисту вашого Drupal-сайту.