Обхід захисту сайтів за допомогою SQL-ін’єкцій та захист від них

Основна частина

Постановка проблеми.

Через різні вразливості веб-серверів і нескладні процедури, атаки на веб-сервери зросли, в основному за рахунок впровадження сценаріїв ASP або PHP. Атаки з використанням SQL ін'єкцій стали основним напрямком, в той час як процес компіляції веб-сервера переважає в сценарії, ігноруючи явище тестування безпеки програмного коду, що призводить до великої кількості надання інтерактивних лазівок в роботі на веб-сервері. Зловмисники можуть використовувати сервер, конфігурувати базу даних дефектів і розробляти структуру незаконних запитів за допомогою програм або сценаріїв вторгнення на сервер, отримувати дозволи адміністратора веб-сайту і отримувати відповідний контент баз даних. Виклад основного матеріалу й обґрунтування отриманих результатів.

Ін'єкція SQL - це вразливість веб-безпеки, яка дозволяє зловмиснику втручатися у запити, які подає програма до своєї бази даних. Як правило, зловмисник дозволяє переглядати дані, які вони зазвичай не можуть отримати. Це може включати дані, що належать іншим користувачам, або будь-які інші дані, до яких сама програма може отримати доступ. У багатьох випадках зловмисник може змінювати або видаляти ці дані, викликаючи постійні зміни у змісті чи поведінці програми.

У деяких ситуаціях існує можливість застосувати атаку ін'єкцій SQL, щоб поставити під загрозу базовий сервер чи іншу інфраструктуру.

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

В дослідженні було перевірено роботу підриву логіки програми за допомогою ін'єкцій SQL, де є можливість змінити запит, задля перешкоджання логіки програми, але також існує велика різноманітність і інших вразливих ситуацій, атак та методів ін'єкцій SQL, які виникають у різних ситуаціях. Деякі поширені приклади введення SQL включають:

• Отримання прихованих даних, де можна змінити SQL-запит, щоб повернути додаткові результати.

• UNION-атаки, де можливо отримати дані з різних таблиць баз даних.

• Вивчення бази даних, де можливо отримати інформацію про версію та структуру бази даних.

• Сліпа ін'єкція SQL, коли результати запиту, яким керує зловмисник, не відповідають результатам програми.

Підрив логіки програми

Розглянемо програму, яка дозволяє користувачам входити з іменем користувача та паролем. Якщо користувач подає ім'я користувача Andrew та пароль 123456, програма перевіряє облікові дані, виконуючи наступний SQL-запит:

SELECT * FROM accounts WHERE username = 'andrew' AND password = '123456'

Якщо запит повертає реквізити користувача, то реєстрація успішна. В іншому випадку реєстрація не відбудеться.

Якщо, наприклад, в поле паролю Ввести знак «' «може виникнути помилка, яка надасть нам потрібну інформацію про базу даних чи про файли сайту. Наприклад, як зображено на рисунку нижче.

Рис. 1. Помилка при відмові в реєстрації користувача

Для перевірки можливості використання SQL коду в полі реєстрації можна в полі password ввести 123456' and 1=1#. Після вводу в разі незахищеності системи реєстрація пройде успішно. Вид запиту після вводу пароля:

SELECT * FROM accounts WHERE username = 'andrew' AND password = '123456' and 1=1#'

Щоб перейти на відповідний аккаунт наприклад andrew, але пароль нам не відомий можна використати or замість and після чого запит буде мати вигляд:

SELECT * FROM accounts WHERE username = 'andrew' OR password = '123456' or 1=1#'

Також існує можливість ввійти, як будь-який користувач, без пароля просто за допомогою поля username. Наприклад, введення імені користувача admin'# та порожнього пароля призводить до наступного запиту:

SELECT * FROM accounts WHERE username = 'admin'# AND password = 'aaaaaa'

Цей запит повертає користувача, ім'я користувача якого є, admin і успішно входить в систему. Так як після 'admin' стоїть знак коментаря #, то все, що йде після нього, буде ігноруватись. Тому запит в дійсності буде таким:

SELECT * FROM accounts WHERE username = 'admin'#

Підрив логіки програми з більш складнішим захистом.

Візьмем більш складну систему яка блокує різні символи крім букв. Тоді при вводі будь-якого знаку буде видаватись така помилка:

Рис. 2. Помилка при вводі на стороні клієнта

Дана помилка відбувається тільки на стороні клієнта, і до серверу запит не відправляється, тому даним способом доступ до бази не буде отримано. Але, якщо будуть введені коректні символи, то зв'язок з базою відбудеться хоча б, щоб перевірити параметри авторизації. На даному етапі можна скористатися програмою Burp Suite та переглянути які пакети надсилаються:

Рис. 3. Інтерфейс програми Burp Suite

Дана програма може «притримати» пакети, які вже вийшли з клієнта, а попередня помилка не буде завадою для отримання доступу до бази. В цій програмі також можливо дещо підправити відправлені дані, а саме переправити пароль на вже відомий код 123456' or 1=1#.

Рис. 4. Деякі можливості програмного продукту Burp Suite

несанкціонований сайт вторгнення

Виявлення вразливості ін'єкцій SQL

Більшість уразливостей ін'єкцій SQL можна швидко та надійно знайти за допомогою веб-сканера вразливості Burp Suite.

Ін'єкцію SQL можна виявити вручну за допомогою систематичного набору тестів проти кожної точки входу в програму. Зазвичай це стосується:

- Подання символу єдиної цитати та пошуку помилок чи інших аномалій.

- Подання деякого специфічного для SQL синтаксису, який оцінює базове (вихідне) значення точки введення та інше значення та шукає систематичні відмінності в отриманих відповідях додатків.

- Посилають логічні умови, такі, як OR 1=1 і OR 1=2, і шукаємо відмінності у відповідях додатка чи сайту.

- Подання корисних навантажень, призначених для запуску затримок у часі при виконанні в межах SQL-запиту, та пошуку відмінностей у часі, необхідному для відповіді.

- Подання корисних навантажень OAST, призначених для запуску позадіапазонної мережевої взаємодії при виконанні в рамках SQL-запиту, а також для моніторингу будь-яких результуючих взаємодій.

Введення SQL в різні частини запиту

Більшість уразливостей для введення SQL виникає в WHERE пункті SELECT запиту. Цей тип ін'єкції SQL, як правило, добре зрозумілий досвідченим тестерам.

Але вразливості введення SQL можуть в принципі виникати в будь-якому місці в межах запиту та в різних типах запитів. Найбільш поширені інші місця, де виникає ін'єкція SQL, це:

- У UPDATE висловлюваннях, в межах оновлених значень або WHERE пункту.

- У INSERT висловлюваннях у межах вставлених значень.

- У SELECT висловлюваннях, в межах назви таблиці чи стовпця.

- У SELECT заявах, у межах ORDER BY.

Захист сайту від SQL-ін'єкцій

Так як ми вже визначили, що SQL-ін'єкції дуже небезпечні тому потрібно мати надійний захист від даних атак. Тому одним з виходів використовувати PHP Data Objects або PDO. PDO (PHP Data Objects) - рівень абстракції для запитів вашої бази даних і є приголомшливою альтернативою MySQLi, оскільки він підтримує 12 різних драйверів баз даних. MySQL - це найпопулярніша база даних. Вона також дуже добре поєднується з PHP, саме тому ця пара технологій добре підтримується у світі PHP.

Якщо фактично знаєте, що єдиною базою даних SQL, якими ви користуєтесь, є або MySQL, або MariaDB, слід вибрати PDO.

Існує думка, що головна перевага PDO полягає в тому, що він переноситься з бази даних в базу даних але насправді це не є так. Насправді, дуже рідко приймається рішення щодо переключення баз даних на конкретний проект, а саме для компаній середнього рівня дана перевага є недоречною. Незважаючи на це, зазвичай, як правило, вважають за краще дотримуватися поточної технології, яка використовується, якщо тільки немає обґрунтованих причин втрачати значну кількість часу та грошей для переносу.

Справжня перевага PDO полягає в тому, що використовується практично подібний API для будь - якої з безлічі баз даних, які він підтримує, тому вам не потрібно вивчати нову для кожної. Названі параметри також, безсумнівно, є величезною перевагою для PDO, оскільки ви можете повторно використовувати однакові значення в різних місцях запитів. На жаль, ви не можете використовувати одні і ті ж названі параметри не один раз із вимкненим режимом емуляції.

Робота підготовлених заявок PDO

Для простішого пояснення, підготовлені заяви PDO працюють так:

1. Підготуйте SQL-запит із порожніми значеннями, як заповнювачі або знаком питання, або ім'ям змінної з двокрапкою, що передує йому, для кожного значення.

2. Прив'яжіть значення або змінні до заповнювачів

3. Виконувати запит одночасно.

Недоліки PDO

Однак при використанні визначених виразів спільно з PDO необхідно знати деякі нюанси, щоб уникнути неприємних ситуацій. Наприклад, в MySQL клієнта деякі запити, складені за допомогою визначених виразів, тому не можуть бути виконані, а так само вони не використовують кеш, що може уповільнити роботу вашого web-додатка.

Гарантована безпека при використанні визначених виразів звучить добре, але розробники не повинні приймати PDO і інші види абстракції, зумовлені вираженням, як абсолютний захист від злому. Будь-які вхідні дані повинні перевірятися, PDO - додаткова лінія оборони. Це розширення не закриває все безліч вразливостей, за допомогою яких може бути завдано шкоди вашій інформації, але в той же час, PDO непогано справляється з питанням запобігання SQL ін'єкцій.

Висновки та перспективи подальшого дослідження.

Отже, SQL-ін'єкції дуже небезпечні для незахищеної системи, так це є найпопулярніший спосіб взлому, і не є дуже складним для розуміння і використання. Тому навіть недосвідчений зловмисник може отримати доступ до бази даних. Байдуже ставлення до захисту від даних атак може призвести до катастрофічних наслідків.

Для надійного захисту використовуйте різні технології захисту, як приклад, технологію PDO, яка захистить від SQL ін'єкцій і дозволить використовувати чистий шар абстракції з бази даних, що забезпечить вам майбутню гнучкість у разі зміни баз даних.

Список бібліографіного опису