Атаки типу SQL-ін’єкції виникають, коли ненадійні дані користувача виконуються як частина SQL-запиту через небезпечні практики написання коду. У цій статті розглянуто основну причину та супутні фактори SQL-ін’єкцій, а також пояснюється, як DAST допомагає виявляти та запобігати цим вразливостям.
SQL-ін’єкція можлива лише тоді, коли неочищені дані користувача напряму вставляються в динамічно сформовані SQL-запити. Ця вразливість дозволяє зловмисникам змінити структуру запиту, отримати несанкціонований доступ до даних або виконати інші команди бази даних. Вразливий застосунок сприймає вхідні дані користувача як виконуваний код. Це відкриває шлях до однієї з найпоширеніших і найнебезпечніших проблем веббезпеки.
Приклад SQL-ін’єкції
Приклад наведено з навчальною метою для кращого розуміння спеціалістів з безпеки, як запобігти таким атакам. Цей допис не закликає до протиправних дій.
Перш ніж перейти до причин недоліку, нижче наведено простий приклад на PHP із вразливим запитом у процесі входу. Можна припустити, що ім’я користувача та пароль були взяті з надісланої форми входу та ці значення безпосередньо вставлені в рядок SQL-запиту наступним чином:
$username = $_POST['username'];
$password = $_POST['password'];
$query = "SELECT * FROM users WHERE username = '$username' AND password = '$password'";Зазвичай застосунок надішле такий запит до бази даних, і якщо результат не порожній – облікові дані правильні. Щоб обійти цю перевірку, зловмисник може вставити корисне навантаження SQL-ін’єкції як ім’я користувача, як цьому фрагменті коду (завершуючи символом коментаря, щоб обійти решту запиту після ін’єкції):
' OR 1=1;--У результаті SQL-запит виглядатиме так:
SELECT * FROM users WHERE username = '' OR 1=1;-- AND password = ''Оскільки умова 1=1 завжди істинна, а перевірка пароля прокоментована, цей запит обходить автентифікацію і може надати несанкціонований доступ. Додавання базової перевірки допоможе ускладнити атаку, але правильне рішення – використання параметризованих запитів, які чітко відокремлюють вхідні дані користувача від виконуваного коду.
Причини SQL-ін’єкцій
Хоч основна причина SQL-ін’єкцій – небезпечне оброблення вхідних даних від користувача у SQL-запитах, існують додаткові фактори, які сприяють виникненню цієї вразливості. Їх розуміння допомагає виявити слабкі місця у на ранніх етапах розробки додатків.
Недостатня перевірка та очищення вхідних даних
Якщо програма не перевіряє або не очищає вхідні дані користувача, злочинний хакер може вставити шкідливі SQL оператори у поля для звичайних даних. Без валідації застосунок не може відрізнити легітимні дані від зловмисних, що дозволяє небезпечним командам потрапити до бази даних.
Неправильне використання динамічного SQL
Формування SQL-запитів через конкатенацію рядків (з’єднання двох або більше рядків в один) з вхідними даними користувача створює високий ризик. Побудова запиту таким чином включає необроблені вхідні дані користувача в логіку запиту, що дає можливість зловмисникам ними маніпулювати. Використання параметризованих запитів або підготовлених операторів є безпечнішою альтернативою, яка забезпечує розділення коду та даних.
Кодування, що не враховує контекст
Кодування вихідних даних має відповідати контексту їх використання. Наприклад, HTML-кодування доречне для вебсторінок, але вхідні дані SQL-запиту слід відповідним чином кодувати як частину процесу параметризації, а не вручну. Неправильне використання або пропуск кодування під час побудови небезпечного запиту значно збільшує ризик ін’єкції, оскільки база даних або програма можуть неналежним чином нейтралізувати шкідливі вхідні дані.
Небезпечний застарілий код
Старі програми часто використовують жорстко закодовану логіку SQL та застарілі практики розробки. Вони можуть не проводити перевірку вхідних даних, застосовувати небезпечні конструкти написання коду, або навіть використовувати старі версії баз даних з відомими вразливостями. Без оновлення такі програми стають постійним джерелом ризику.
Надмірні привілеї бази даних
Якщо застосунок підключається до бази даних з правами адміністратора або розширеним доступом, зловмисник може отримати доступ до системних таблиць, які не призначені для користування. У такій ситуації будь-яка успішна ін’єкція може призвести до значної шкоди. Обмеження привілеїв бази даних лише до того, що необхідно для кожної операції, є критично важливим засобом контролю, який допомагає зменшувати вплив потенційних експлойтів. Це також включає запуск самого процесу бази даних з обмеженого облікового запису, а не з root.
Неналежне оброблення помилок
Надання користувачам детальних повідомлень про помилки може дати зловмисникам уявлення про структуру бази даних, що полегшує створення успішних корисних навантажень SQL-ін’єкцій. Правильна обробка помилок гарантує безпечне логування внутрішніх проблем, водночас повертаючи кінцевим користувачам лише загальні повідомлення. У деяких випадках зловмисники також можуть виявляти помилки опосередковано на основі змін часу реакції бази даних, що дозволяє проводити сліпі SQL-ін’єкції.
Недостатнє тестування безпеки
Без регулярного тестування безпеки SQL-ін’єкції легко пропустити. Статичний аналіз – це перший крок, але перевірка коду сама по собі не може передбачити, як вхідні дані користувача потраплять у запити. Будь-які прогалини в динамічному тестуванні безпеки, як автоматизованому, так і ручному, значно збільшують ризик потрапляння невиявлених вразливостей у продакшн.
Запобігання SQL-ін’єкціям завдяки DAST
Найефективніший спосіб запобігти SQL-ін’єкціям – поєднати безпечні практики написання коду з тестуванням запущених застосунків. Саме тут важливу роль відіграє DAST (динамічне тестування безпеки додатків).
Підхід DAST, який підтримує Invicti (раніше Netsparker), дає змогу побачити справжні ризики, які можна експлуатувати, завдяки тестуванню додатків в реальних умовах. За допомогою технології Proof-based сканування Invicti автоматично підтверджує знайдені вразливості, зменшуючи кількість хибнопозитивних спрацьовувань і прискорюючи виправлення.
Інтегруючи DAST у процес розробки, організації можуть виявляти та усувати SQL-ін’єкції до того, як ними скористається зловмисник. Це практична і масштабована стратегія для боротьби з однією з найдавніших, але й досі найнебезпечніших загроз веббезпеки.
