SQL-ін’єкції можуть бути використані різними способами для створення серйозних проблем. Використовуючи SQL-ін’єкції, зловмисник може обійти автентифікацію, отримати доступ, змінити або видалити дані в базі даних. У деяких випадках SQL-ін’єкції можуть навіть використовуватися для виконання команд в операційній системі, що потенційно дозволяє зловмиснику перейти до більш руйнівних атак всередині мережі, яка знаходиться за брандмауером.
SQL-ін’єкції можна розділити на три основні категорії – In-band SQLi, Inferential SQLi та Out-of-band SQLi.
In-band SQLi (класичний SQLi)
In-band SQL ін’єкція є найпоширенішим і найпростішим у виконанні видом атак SQL ін’єкції. In-band SQL ін’єкції виникають, коли зловмисник може використовувати один і той же канал зв’язку для запуску атаки та збору результатів.
Два найпоширеніші типи in-band SQL ін’єкцій – це SQLi на основі помилок (Error-based SQLi) та SQLi на основі об’єднань (Union-based SQLi).
Error-based SQLi
Error-based SQLi – це метод in-band SQL ін’єкції, який покладається на повідомлення про помилки, що надсилаються сервером бази даних для отримання інформації про структуру бази даних. У деяких випадках зловмиснику достатньо одної лише error-based SQL-ін’єкції, щоб перерахувати всю базу даних. Хоча помилки дуже корисні на етапі розробки вебдодатків, їх слід вимкнути на справному сайті або замість цього записати у файл з обмеженим доступом.
Union-based SQLi
Union-based SQLi – це внутрішньосмугова техніка SQL-ін’єкцій, яка використовує оператор UNION SQL для об’єднання результатів двох або більше SELECT-операторів в один результат, який потім повертається як частина HTTP-відповіді.
Inferential SQLi (blind SQL)
Існує два типи inferential SQL-ін’єкцій: SQLi на основі сліпих булевих операцій та SQLi на основі сліпих часових операцій (Blind-boolean-based SQLi та Blind-time-based SQLi).
Boolean-based (content-based) Blind SQLi
Boolean-based SQL ін’єкція – це техніка Inferential SQL ін’єкції, яка ґрунтується на надсиланні SQL запиту до бази даних, який змушує додаток повертати різні результати залежно від того, чи запит повертає результат TRUE або FALSE.
Залежно від результату, вміст HTTP-відповіді змінюється або залишається незмінним. Це дозволяє зловмиснику зробити висновок про те, що використовуване корисне навантаження повернуло true або false, навіть якщо ніяких даних з бази даних не повертається. Ця атака зазвичай є повільною (особливо для великих баз даних), оскільки зловмиснику потрібно перерахувати базу даних, символ за символом.
Time-based Blind SQLi
Time-based SQL ін’єкція – це техніка вивідної SQL ін’єкції, яка базується на надсиланні SQL запиту до бази даних, що змушує базу даних чекати певний час (в секундах) перед тим, як відповісти на нього. Час відповіді вкаже зловмиснику, чи є результат запиту TRUE або FALSE.
Залежно від результату, HTTP-відповідь буде повернута із затримкою або повернута негайно. Це дозволяє зловмиснику зробити висновок про те, чи повернулося корисне навантаження (payload) істинним чи хибним, навіть якщо ніяких даних з бази даних не повертається. Ця атака зазвичай є повільною (особливо для великих баз даних), оскільки зловмиснику потрібно перебирати базу даних символ за символом.
Out-of-band SQLi
Out-of-band SQL ін’єкції не дуже поширені, в основному тому, що вони залежать від функцій, увімкнених на сервері бази даних, який використовується вебдодатком Out-of-band SQL ін’єкції виникають, коли зловмисник не може використовувати той самий канал для запуску атаки та збору результатів.
Позаканальні методи пропонують зловмиснику альтернативу методам, що базуються на вирахуванні часу, особливо якщо відповіді сервера не дуже стабільні (що робить атаку, що базується на вирахуванні часу, ненадійною).
Out-of-band SQLi покладаються на здатність сервера бази даних робити DNS або HTTP-запити для передачі даних зловмиснику. Це стосується команди xp_dirtree в Microsoft SQL Server, яку можна використовувати для надсилання DNS-запитів на сервер, який контролює зловмисник; а також пакету UTL_HTTP в Oracle Database, який можна використовувати для надсилання HTTP-запитів з SQL і PL/SQL на сервер, який контролює зловмисник.
Як виявити SQL ін’єкції ?
Якщо використовується лише комерційне або відкрите програмне забезпечення і відсутня власна розробка, то може бути достатньо визначити точну версію системи або додатку, що використовується. Якщо визначена версія чутлива до SQLi, можна припустити, що програмне забезпечення вразливе. Можна визначити версію самостійно або скористатися відповідним інструментом безпеки, наприклад, рішенням для аналізу складу програмного забезпечення (SCA) для вебдодатків або мережевим сканером для мережевих систем і додатків.
Якщо розробник додатків хоче мати можливість потенційно знаходити в них SQLi вразливості, він повинен мати можливість успішно експлуатувати SQLi вразливість, щоб бути впевненим в її існуванні. Для цього потрібно або виконати мануальне тестування на проникнення за допомогою дослідників безпеки, або скористатися інструментом для сканування вразливостей, який може використовувати автоматизацію для експлуатації вебвразливостей. Прикладами таких інструментів є Invicti та Acunetix.
Як захиститися від атак SQL-ін’єкцій?
Можливі методи захисту від SQLi атак залежать від типу вразливого програмного забезпечення:
- У випадку користувацького програмного забезпечення, такого як вебдодатки, єдиним способом постійного захисту від SQLi є використання параметризованих (parameterized) запитів або збережених процедур, якщо параметризовані запити недоступні. До інших заходів слід вдаватися лише в тому випадку, якщо перехід на параметризовані запити вимагатиме значних змін у дизайні програмного забезпечення, наприклад, якщо потрібно перенести застарілий PHP-додаток з оригінального API MySQL на PDO або MySQLi.
- У випадку відомого SQLis в сторонньому програмному забезпеченні, потрібно перевірити останні рекомендації з безпеки на наявність виправлень і оновити його до невразливої версії (як правило, до останньої версії).
- У випадку з zero-day SQLis в сторонньому програмному забезпеченні, можна покладатися лише на тимчасові правила WAF (брандмауер вебдодатків) для пом’якшення наслідків. Однак, це лише ускладнить експлуатацію SQLi та не усуне першопричину проблеми.
Далі розглянуті заходи, які допоможуть зменшити шкоду в разі успішної експлуатації наявної вразливості в SQLi:
- Розробники: Для доступу до бази даних слід використовувати найнижчі можливі привілеї. Кожного разу, коли виконується доступ до бази даних у додатку, необхідно переконатися, що використовується обліковий запис бази даних, який має мінімально необхідні для цієї операції привілеї.
- Адміністратори бази даних: Відключити всі опції, які спричиняють повернення користувачеві повідомлень про помилки бази даних, наприклад, у відповідях HTTP. Ввімкнути такі опції тимчасово, лише під час налагодження коду.
- Системні адміністратори: Переконатися, що базові операційні системи програми та сервера бази даних захищені та оновлені. Це допоможе запобігти атакам на підвищення привілеїв у випадку, якщо в додатку існує вразливість SQL-ін’єкції.
