Drupal є досить популярним засобом створення сайтів. На Drupal написані сотні тисяч сайтів, які функціонують в інтернеті, а спільнота розробників, які його використовують, зростає. Тож його продовжують перевіряти, сканувати, аналізувати на вразливість у плані безпеки. Drupal розроблений і продовжує розроблятися таким чином, щоб запобігати критичним вразливостям безпеки, в тому числі і Топ 10 ризикам безпеки, які визначив Open Web Application Security Project (OWASP). Drupal показав себе як надійний програмний продукт і використовується для створення сайтів серйозних підприємств і організацій, зокрема, сайт Білого Дому США написаний на Drupal.
Ядро Drupal добре захищене за замовчуванням, але ми можемо ненавмисно відкрити вразливі місця через незахищені налаштування. Прикладом цього є такі прості речі, як дозвіл недовіреним юзерам використовувати html-теги у полі коментарів, а це відкриває можливість для атак типу міжсайтового скриптингу. Тож не варто покладатися на заходи безпеки, які вшиті в ядро Drupalа, але й дотримуватися додаткових правил, які можуть вберегти ваш сайт від атак та інших небезпек.
Релізи безпеки Drupal
Релізи безпеки ядра Drupal (security releases) нумеруються за стандартною схемою нумерації версій, тож не додається жодний індикатор, який би вказував, що в цій версії додані поправки безпеки. Наприклад, версія ядра 7.34 є релізом безпеки, що виправляє деякі вразливості безпеки, тоді як попередня версія 7.33 є звичайним релізом підтримки (maintenance release), яка виправляє окремі баги і вносить деякі покращення в апі. Тож одним із способів зробити свій сайт безпечнішим є своєчасне оновлення ядра Drupal. Більше про релізи ядра тут: https://www.drupal.org/node/1173280
Видалення/блокування юзера
Сайти на Drupal можуть дозволяти юзерам видаляти інших юзерів, або навіть самих себе. Іноді це може призвести до непередбаченої ситуації, коли анонімні юзери можуть переглядати або редагувати сторінки на сайті, які вони взагалі не повинні бачити. Таке може статися, якщо видалені юзери залишили на сайті свої ноди чи коментарі. Уникнути цього можна двома способами: 1. блокувати юзерів замість того, щоб їх видаляти. 2. видаляти юзерів командою “Cancel account”, використовуючи опцію “Видалити акаунт і провласнити весь контент цього юзера анонімному юзеру”.
Використання HTTPS
Протокол HTTPS зашифровує http-запити і відповіді на них, він забезпечує, щоб, навіть якщо хтось спроможеться підключитися до з’єднання між вами і сервером, він не зміг “прослухати” або втрутитися у ваш зв’язок. HTTPS зазвичай використовується в ситуаціях, коли юзер має посилати таємну чи особисту інформацію і перехоплення такої інформації може призвести до проблем. Зазвичай мається на увазі: кредитні картки паролі і логіни ідентифікаційна інформація (номер соціального страхування, адреса, індекс) конфіденційна інформація.
Особливо у ситуаціях, коли вам як адміністратору потрібно відіслати пароль головного юзера або ftp пароль до вашого сервера, ви повинні використовувати https скрізь, де це можливо, щоб зменшити ризик шкоди для вашого сайту. Обслуговування https-трафіку потребує більше ресурсів, ніж http-запитів (і для сервера, і для браузера), тому можна використовувати на одному сайті поєднання цих двох протоколів відповідно до потреби. Більше про налаштування HTTPS для Drupal-сайта можна знайти тут: https://www.drupal.org/https-information
Запобігання виконанню ненадійного PHP-коду
Потрібно розуміти, які наслідки може мати дозвіл юзерам запускати php. Таке трапляється, коли юзер вводить php-код у форму, запускає форму, і тоді цей код виконується на сервері. Такий юзер зможе редагувати і навіть видаляти будь-які файли, які дозволяє сервер (до яких є доступ). У більшості випадків це файли Drupal-сайта у папці “files”.
PHP також може використаний щоб змінити базу даних чи вкрасти звідти інформацію. У таких випадках таблиці можуть бути видалені, контент змінений, особисті дані користувачів змінені або витягнуті. Особливо небезпечно, якщо сайт комерційний, тоді піддається ризику фінансова інформація юзерів. Є безліч способів взяти сайт під свій контроль, якщо запустити php-скрипт.
Також важливо, щоб сторонні особи не могли прочитати файл settings.php (навіть якщо він належить іншій інсталяції Drupal), оскільки в ньому записується логін і пароль доступу до бази даних.
Є два основні шляхи виконання php-коду, що представляє ризик для сайту. Перший - через існуючий код сайту, який оцінює вхідний текст як php, наприклад, модулі, які підтримують текстовий формат php. Другий спосіб - це коли небезпечний php-код виконується через завантаження юзером файла, що містить код, до файлової системи.
Модулі, які дозволяють виконання php-коду повинні давати доступ до цього лише довіреним ролям, або навіть лише юзеру з uid 1. Якщо ви виявили модуль, який дозволяє небезпечний запуск php-коду без відповідних зауважень чи контролю, вам варто уникати використання такого модуля.
Функціональність завантаження файлів, яку дає ядро Drupal, допомагає захиститися від запуску php-коду, обмежуючи допустимий формат файлів. За замовчуванням файли з розширенням .php не підтримуються. З іншої сторони, якщо php-код включений у файл з іншим розширенням, і веб-сервер налаштований виконати цей файл як php, тоді зловмисник має шанс провести атаку на сервер.
Боротися з цим можна, правильно налаштувавши файл .htaccess для серверів Apache. Звичайно, цей файл повинен бути захищеним від редагування вебсервером. Ще можна захиститися, правильно довіривши доступи:
- Користувач user/1 звичайно має доступ до встановлення модулів, які запускають php-код.
- Давати доступ “Administer permissions” варто тільки довіреним ролям, бо юзери, які мають такий доступ можуть дати собі будь-які інші доступи.
- Доступ Administer users дозволяє редагувати головного юзера (user/1), змінити йому пароль і зайти під ним. Тож і тут варто теж не допускати недовірених юзерів до таких можливостей.
Кілька слів потрібно додати про текстові формати для форм. В жодному разі не можна давати анонімам і іншим юзерам, які не мають довірених ролей, доступу до формату Full HTML, оскільки відвідувачі сайту матимуть змогу не лише вставляти в текст картинки, а й прописувати туди небезпечний JavaScript-код. Таким юзерам краще давати доступ до формату Filtered HTML. Звичайно, не слід дозволяти недовіреним юзерам змінювати доступи до текстових форматів зі сторінки admin/people/permissions.
Юзер №1
Акаунт, який створюється при інсталації Drupal і має uid рівний 1 (user/1 або суперадмін), особливий. Перш за все тим, що він володіє обходом всіх перевірок доступу - тобто він за замовчуванням має всі доступи на сайті. Захистити такий акаунт дуже важливо, бо невдача із захистом веде до серйозних ризиків. Щоб захистити головний акаунт, слід дотримуватися правил. Насамперед, уникати таких імен для користувача, як ‘admin’, ‘administrator’, чи інших, які легко вгадати.
Головного юзера можна відключити (disable). Оскільки будь-які доступи можна довірити іншим юзерам з відповідною роллю, щоденне використання суперадміна не є обов’язковим. А якщо час від часу потрібно використовувати цей акаунт, його можна включати/виключати в будь-який час за допомогою drush:
drush user-block 1
drush user-unblock 1
або через MySQL:
UPDATE users SET status = 0 WHERE uid = 1
UPDATE users SET status = 1 WHERE uid = 1
Варто ставити складний пароль для головного юзера. Для цього можна використати функцію php user_password, яка генерує випадковий числово-буквений пароль. Щоб зробити це через drush, потрібно ввести в терміналі команду:
drush php-eval ‘print user_password();’
Ховайте інформацію від юзерів
Це є не так важливо, оскільки зловмисники можуть дізнатися потрібну їм інформацію про ваш сайт і іншими способами. Але хорошою практикою є давати потенційним атакерам якомога менше інформації. Це стосується, перш за все, повідомлень про помилки. У Drupal можна показувати або ховати такі повідомлення. Для розробки корисно їх бачити, щоб бачити, що треба виправити, але на живому сайті необхідно ховати такі повідомлення для того, щоб запобігти розкриттю такої інформації, як повний шлях до системних файлів або структуру таблиць у базі даних.
Такі файли, як README.txt, CHANGELOG.txt, можуть містити інформацію про версії. Їх можна видалити, але краще перемістити за межі сайту чи переіменувати, оскільки можуть містити і корисну інформацію.
Як перевірити сайт на “сек’юрність” та деякі поради щодо захисту свого сайту
Є кілька корисних тестів, які дозволяють перевірити, чи ваш сайт становить загрозу:
http://www.unmaskparasites.com/
Якщо тест показав, що загроз нема, це ще не доводить, що сайт добре захищений, це лише показує, що сайт не становить безпосередньої загрози для відвідувачів.
Часто ціллю атакерів є таблиця menu_router у базі даних. Цікавий випадок описаний на сайті http://www.zoubi.me/ коли зловмисники модифікували базу, щоб записувати в неї шкідливі дані. Тож варто перевірити, чи у вас немає чогось подібного.
Інфіковані сайти можуть мати додаткових юзерів або навіть адмінські ролі. Перевірте таблиці users і user_roles на предмет підозрілих записів. Хакери часто використовують такі імена, як drupaldev, megauser, system, admin122. Якщо ви більш підозріливі, перевірте таблицю sessions на підозрілу активність.
Буває таке, що в директорії /modules/ або /sites/ хакери поміщають php-файли зі шкідливим кодом, а в базі можна знайти записи, які ведуть до цих файлів. Один такий випадок описаний у блозі на сайті https://www.reddit.com.
Траплялися випадки, коли хакери видаляли рядки, що містять захисні заходи, з файлу .htaccess, тому краще завжди мати бекап-версію цього файлу і час від часу звірятися з нею, чи не було внесено змін.
Для перевірки сайту на безпеку можна скористатися site_audit. Це не модуль, тож його не треба ставити як модуль, це набір команд для drush, тому інсталюється відповідно. Всі інструкції є в файлі README.txt. Нові команди аналізують різні налаштування сайту: кешування, наявність невикористовуваних типів контенту, які розробницькі модулі є включеними (а на живому сайті їх варто виключати), які є виключеними, але ще не деінстальованими та інші, і дають рекомендації щодо підвищення рівня безпеки та продуктивності сайту.
У ядрі Drupal версії 7.31 і нижче було одне вразливе місце. Функція, яка відсилає запити у базу даних з форми (у тому числі з форми логінації), не проводила перевірки ключів масиву. А значить, замість ключа можна було ввести будь-яку команду SQL. Робилось усе дуже просто: через inspect element редагуємо форму логінації, замість значення name, яке буде ключем масиву, вводимо SQL-ін’єкцію і пробуємо зайти на сайт, навіть якщо нам не вдасться залогінитися, команда успішно виконається і принесе шкоду базі даних.
Виправлявся цей баг одним рядком коду у патчі 7.32:
Ще є цікаве доповнення для drush, яке називається drupalgeddon. Воно дає можливість додатково перевірити свій сайт на сек’юрність.
Іноді у новачків виникає ідея, і вони запитують на drupal.org: як приховати від відвідувачів те, що сайт написаний на Drupal? На що drupal.org відповідає: Ви не можете цього зробити, не намагайтесь. По-перше, автоматичні атаки не досліджують сервер перед тим як атакувати, змінювати файли ядра заради маскування є небезпечно, бо можна зробити помилку і стане складніше оновити ядро через справжній сек’юріті апдейт.
Також drupal.org дає багато корисних порад щодо написання сек’юрного коду: writting secure code. Наприклад не використовувати змінних з масиву $form_state[‘input’], оскільки туди приходять дані прямо з форми перед будь-якою обробкою, написання безпечних запитів до бази даних і багато іншого.
Команда безпеки (Security team)
Drupal-спільнота має свою команду безпеки (security team), яка займається аналізом ядра і контрібних модулів і переглядом репортів юзерів на рахунок безпеки, пишуть документацію про безпеку Drupal-сайтів, дають поради щодо написання сек’юрного коду та іншим. Про те, як написати репорт про проблему безпеки Drupal, можна прочитати тут.
Огляд модулів безпеки Drupal (Drupal security modules)
Розроблено багато модулів, які дають можливість підвищити безпеку вашого сайту. Ось короткий огляд деяких з них.
Drupal Security Review - модуль, який проводить перевірку сайту на предмет налаштувань, які можуть створити вразливі для атак місця. Зручний і легкий у використанні.
Paranoia - модуль, який, інсталювавшись, одразу себе приховує, а разом з собою і пермішн давати можливість юзерам запускати php-код через інтерфейс, виключає можливість створювати формати введення, які використовують php фільтр, відключає можливість редагування головного юзера, та інші можливості, які можуть потрапити до рук ненадійних юзерів. Цей модуль також відключає можливість виключити самого себе (це можна зробити тільки через базу даних).
Hacked! - модуль перевіряє, чи були внесені зміни в ядро або контрібні модулі чи теми. Може запускатися через drush. Якщо включений модуль diff, то можна буде побачити навіть рядки коду, що були змінені.
Security kit - модуль додає різноманітні опції для посилення безпеки. Це дозволяє зменшити ризик нанесення шкоди вашому сайту.
Encrypt - модуль, що дозволяє шифрувати і розшифровувати дані, наприклад, для збереження у базі даних різної конфіденційної інформації, включає в себе підтримку чотирьох методів кодування. Є модулі, які додають свою функціональність з шифрування, наприклад Encrypt form api дозволяє шифрувати поля форми.
Captcha - це текст, який додається до форми, щоб перевірити чи юзер - людина чи бот (думаю, всі через це проходили, це чимось нагадує тест Тюрінга). Можуть бути капчі у вигляді математичної операції типу додавання, результат якої треба ввести, але найчастіше це картинка з майже нечитабельним текстом, який прочитати може тільки людина і має цей текст ввести. Є багато модулів, які доповнюють цей, додаючи свої різновиди капч.
AES Encryption дає додаткові способи шифрування/дешифрування даних з використанням Advanced Encryption Standard. На основі цього модуля написані інші, такі як Encrypted files, який дозволяє шифрувати файли, які завантажуються на сервер і дешифрувати їх, якщо юзер завантажує їх з сайту, таким чином на сервері зберігаються виключно зашифровані версії файлів.
Висновок
Сам по собі Drupal не захистить вас від усіх небезпек, він лише дає можливість вам організувати своєму сайту захист на власний розсуд. Для цього пишуться сек’юріті апдейти і поради розробників, створюють контрібні модулі, але варто і самому налаштувати сайт так, щоб зменшити ризик. Drupal лише дає карти в наші руки, а грати ними повинні ми.