Атаки SQL-ін'єкцій створюють величезні ризики для веб-програм, які залежать від бази даних для створення динамічного контенту. У цьому типі атаки хакери маніпулюють веб-додатком, намагаючись впровадити свої власні команди SQL в команди, видані базою даних. У цій статті ми розглянемо кілька способів тестування веб-додатків, щоб визначити, чи вразливі вони для атак SQL-ін'єкцій.
Автоматичне сканування ін'єкцій SQL
Однією з можливостей є використання автоматичного сканера вразливостей веб-програм, таких як HP WebInspect, IBM AppScan або Cenzic Hailstorm. Всі ці інструменти пропонують прості, автоматизовані способи аналізу ваших веб-додатків на предмет потенційних вразливостей SQL-ін'єкцій. Тим не менш, вони досить дорогі і коштують до 25 000 доларів за місце.
Ручні тести SQL-ін'єкцій
Що робити поганому розробнику програм? Ви можете запустити деякі базові тести, щоб оцінити свої веб-програми на наявність вразливостей SQL-ін'єкцій, використовуючи не більше ніж веб-браузер. По-перше, застереження: тести, які ми описуємо, шукають тільки основні недоліки SQL-ін'єкцій. Вони не будуть виявляти передові методи і дещо втомлюються у використанні. Якщо ви можете собі це дозволити, використовуйте автоматичний сканер. Однак, якщо ви не можете впоратися з цим цінником, ручне тестування - відмінний перший крок.
Найпростіший спосіб оцінити, чи є додаток вразливим, - це поекспериментувати з невинними ін'єкційними атаками, які насправді не завдадуть шкоди вашій базі даних, але нададуть вам докази того, що вам потрібно виправити проблему. Наприклад, припустимо, що у вас є простий веб-додаток, який шукає людину в базі даних і в результаті надає контактну інформацію. На цій сторінці можна використовувати такий формат URL:
Ми можемо припустити, що ця сторінка виконує пошук у базі даних, використовуючи запит, подібний до такого:
Давайте трохи поекспериментуємо з цим. Виходячи з нашого припущення вище, ми можемо зробити просту зміну URL-адреси, який перевіряє атаки SQL-ін'єкцій:
Якщо веб-програма не була належним чином захищена від впровадження SQL, вона просто вставляє це підроблене ім'я в оператор SQL, виконуваний для бази даних, що призводить до:
Ви помітите, що наведений вище синтаксис трохи відрізняється від синтаксису вихідного URL. Ми дозволили собі перетворити закодовану на URL змінну для їх еквівалентів ASCII, щоб було легше наслідувати приклад. Наприклад,% 3d - це кодування URL для символу «=». Ми також додали кілька розривів рядків для аналогічних цілей.
Оцінка результатів
Тест приходить, коли ви намагаєтеся завантажити веб-сторінку з URL-адресою, вказаною вище. Якщо веб-додаток добре себе веде, він видалить одинарні лапки з вхідних даних перед передачею запиту в базу даних. Це просто призведе до дивного пошуку когось, чиє ім'я включає в себе кілька SQL. Ви побачите повідомлення про помилку з програми, подібне до наведеної нижче програми:
З іншого боку, якщо програма вразлива для впровадження SQL-коду, вона передасть оператор безпосередньо в базу даних, що призведе до однієї з двох можливостей. По-перше, якщо на вашому сервері включені докладні повідомлення про помилки (чого не слід робити), ви побачите щось на зразок цього:
З іншого боку, якщо ваш веб-сервер не показує докладні повідомлення про помилки, ви отримаєте більш загальну помилку, таку як:
Якщо ви отримаєте одну з двох помилок, зазначених вище, ваша програма вразлива для атаки SQL-ін'єкцією. Ось деякі кроки, які ви можете зробити, щоб захистити свої програми від атак SQL-ін'єкцій:
- Реалізувати перевірку параметрів у всіх програмах. Наприклад, якщо ви просите когось ввести номер клієнта, переконайтеся, що введення числового, перш ніж виконувати запит.
- Обмежте дозвіл облікового запису, який виконує запити SQL. Використовується правило найменших привілеїв. Якщо обліковий запис, який використовується для виконання запиту, не має дозволу на його виконання, це не буде виконано успішно.
- Використовуйте збережені процедури (або подібні методи), щоб запобігти безпосередній взаємодії користувачів з кодом SQL.
