Меню

Підручник з тестування ін’єкцій SQL (Приклад та запобігання атаці ін’єкцій SQL)

sql injection testing tutorial example

Спробуйте Наш Інструмент Для Усунення Проблем

яка різниця між контролем якості та забезпеченням якості

Приклади ін’єкції SQL та способи запобігання атакам ін’єкції SQL на веб-додатки

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

Зазвичай для цього проводять перевірку безпеки. Для того, щоб провести цей тип тестування, спочатку нам потрібно врахувати, які атаки найімовірніше відбудуться. SQL Injection - одна з таких атак.

Приклад вкладання SQL-ін’єкції та запобігання

Введення SQL вважається однією з найпоширеніших атак, оскільки воно може спричинити серйозні та шкідливі наслідки для вашої системи та конфіденційних даних.

Що ви дізнаєтесь:

Що таке ін'єкція SQL?

Деякі введені користувачем дані можуть бути використані для кадрування Виписки SQL які потім виконуються додатком у базі даних. Додаток НЕ може правильно обробляти введені користувачем дані.

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

Як випливає з назви, мета атаки SQL Injection полягає у введенні шкідливого SQL-коду.

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

Замість правильних даних, якщо введено будь-який зловмисний код, то існує можливість серйозних пошкоджень бази даних і всієї системи.

Введення SQL виконується за допомогою мови програмування SQL. SQL (мова структурованих запитів) використовується для управління даними, що зберігаються в базі даних. Тому під час цієї атаки цей код мови програмування використовується як зловмисна ін’єкція.

Це одна з найпопулярніших атак, оскільки бази даних використовуються майже для всіх технологій.

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

# 1) Показати відповідні збережені дані користувачеві, наприклад додаток перевіряє облікові дані користувача, використовуючи дані для входу, введені користувачем, і надає користувачеві лише відповідні функції та дані

# два) Збережіть дані, введені користувачем, до бази даних, наприклад як тільки користувач заповнює форму та подає її, програма продовжує зберігати дані в базі даних; ці дані надаються користувачеві в тому ж сеансі, а також у наступних сеансах

Ризики введення SQL

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

Оскільки конфіденційні дані зберігаються в базі даних, існує більше ризиків, пов’язаних із безпекою системи. Якщо будь-який персональний веб-сайт або дані блогу будуть викрадені, тоді шкоди не буде великим, якщо порівнювати з даними, викраденими з банківської системи.

Основна мета цієї атаки - зламати базу даних системи, тому наслідки цієї атаки дійсно можуть бути шкідливими.

Наступні речі можуть бути результатом SQL Injection

  • Злом акаунта іншої особи.
  • Викрадення та копіювання конфіденційних даних веб-сайту або системи.
  • Зміна конфіденційних даних системи.
  • Видалення конфіденційних даних системи.
  • Користувач міг увійти до програми як інший користувач, навіть як адміністратор.
  • Користувач міг переглянути приватну інформацію, що належить іншим користувачам, наприклад деталі профілів інших користувачів, деталі трансакцій тощо.
  • Користувач міг змінити інформацію про конфігурацію програми та дані інших користувачів.
  • Користувач міг змінити структуру бази даних; навіть видаляти таблиці в базі даних програми.
  • Користувач міг взяти під контроль сервер баз даних і виконувати на ньому команди за бажанням.

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

Як тестувальник, я хотів би зауважити, що тестування проти можливих атак є гарною практикою, навіть якщо Тестування безпеки не планувалося. Таким чином ви можете захистити та протестувати продукт від несподіваних випадків та зловмисних користувачів.

Суть цього нападу

Як уже згадувалося раніше, суть цієї атаки полягає у злому бази даних зі зловмисною метою.

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

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

Рекомендований інструмент

# 1) Кіуван

kiuwan банер

Легко знаходити та виправляти такі вразливості, як введення SQL, у коді на кожному етапі SDLC. Kiuwan відповідає найсуворішим стандартам безпеки, включаючи OWASP, CWE, SANS 25, HIPPA та інші.

Інтегруйте Kiuwan у свою IDE для миттєвого зворотного зв’язку під час розробки. Kiuwan підтримує всі основні мови програмування та інтегрується з провідними інструментами DevOps.

=> Скануйте свій код безкоштовно

Для здійснення цієї атаки ми повинні змінити дію та мету відповідного запиту до бази даних. Одним з можливих методів його виконання є зробити запит завжди істинним, а після цього вставити свій зловмисний код. Змінити запит до бази даних на завжди істинний можна виконати за допомогою простого коду типу ‘або 1 = 1; -.

Суть ін’єкції SQL

Тестери повинні мати на увазі, що, перевіряючи, чи можна змінити запит на завжди істинний, слід спробувати різні цитати - одинарні та подвійні. Отже, якщо ми спробували код типу „або 1 = 1; -, ми також повинні спробувати код із подвійними лапками“ або 1 = 1; -.

Essensce введення SQL

Наприклад, давайте розглянемо, що ми маємо запит, який шукає введене слово в таблиці бази даних:

виберіть * з приміток nt, де nt.subject = ‘слово_пошуку’;

Тому замість пошукового слова, якщо ми введемо запит на ін’єкцію SQL ‘або 1 = 1; -, тоді запит стане завжди істинним.

виберіть * з приміток nt, де nt.subject = ‘‘ або 1 = 1; -

У цьому випадку параметр “subject” закривається цитатою, і тоді ми маємо код або 1 = 1, що робить запит завжди істинним. Зі знаком «-» ми коментуємо решту коду запиту, який не буде виконаний. Це один з найпопулярніших і найпростіших способів розпочати контроль над запитом.

Кілька інших кодів також можуть бути використані, щоб зробити запит завжди істинним, наприклад:

  • ‘Або‘ abc ‘=‘ abc ‘; -
  • ‘Або‘ ‘=‘ ‘; -

Найголовніше тут, що після знаку коми ми можемо ввести будь-який зловмисний код, який ми хотіли б виконати.

Наприклад, це може бути ‘або 1 = 1; викинути примітки до таблиці; -

Примітки до таблиці

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

Перевірити цю вразливість можна дуже легко. Іноді достатньо набрати в тестованих полях знак «або». Якщо воно повертає якесь несподіване або надзвичайне повідомлення, то ми можемо бути впевнені, що для цього поля можливо введення SQL.

Наприклад , якщо в результаті пошуку ви отримаєте повідомлення про помилку, наприклад, «Внутрішня помилка сервера», ми можемо бути впевнені, що ця атака можлива в тій частині системи.

Інші результати, які можуть сповістити про можливу атаку, включають:

  • Завантажено порожню сторінку.
  • Немає повідомлень про помилки чи успіх - функціональність та сторінка не реагують на введення.
  • Повідомлення про успіх для зловмисного коду.

Давайте розглянемо, як це працює на практиці.

Наприклад, Давайте перевіримо, чи відповідне вікно входу вразливе для SQL Injection. Для цього в поле електронної адреси або пароля ми просто вводимо знак, як показано нижче.

Електронна адреса

Якщо таке введення повертає результат, як-от повідомлення про помилку «Внутрішня помилка сервера» або будь-який інший перерахований невідповідний результат, тоді ми можемо бути майже впевнені, що ця атака можлива для цього поля.

Внутрішня помилка сервера

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

Тому перевірка SQL Injection за допомогою однієї лапки «є досить надійним способом перевірити, чи можлива ця атака чи ні.

Якщо одинарна лапка не дає жодного невідповідного результату, тоді ми можемо спробувати ввести подвійні лапки та перевірити результати.

Одинарна пропозиція

Крім того, SQL-код для зміни запиту на завжди істинний може розглядатися як спосіб перевірити, чи можлива ця атака чи ні. Він закриває параметр і змінює запит на 'true'. Тому, якщо не перевірено, такий ввід може також повернути будь-який несподіваний результат і повідомити те саме, що в цьому випадку можлива ця атака.

Essensce введення SQL

Перевірку можливих атак SQL також можна виконати за посиланням веб-сайту. Припустимо, у нас є посилання на веб-сайт як http://www.testing.com/books=1 . У цьому випадку параметр 'книги' є параметром, а '1' - його значенням. Якщо у наданому посиланні ми напишемо «знак замість 1, то ми перевіримо на можливу ін’єкцію.

Тому посилання http://www.testing.com/books= буде як тест, якщо для веб-сайту можлива атака SQL http://www.testing.com чи ні.

Посилання для тестування

У цьому випадку, якщо посилання http://www.testing.com/books= повертає повідомлення про помилку, наприклад, «Внутрішня помилка сервера», чи порожню сторінку, або будь-яке інше несподіване повідомлення про помилку, тоді ми також можемо бути впевнені, що для цього веб-сайту можливо введення SQL. Пізніше ми можемо спробувати надіслати більш хитрий код SQL за посиланням веб-сайту.

Щоб перевірити, чи можлива ця атака за посиланням веб-сайту, чи ні, код, наприклад «або 1 = 1; - також можна надіслати.

Тестування посилань

Як досвідчений тестувальник програмного забезпечення, я хотів би нагадати, що не тільки несподіване повідомлення про помилку може розглядатися як вразливість SQL Injection. Багато тестувальників перевіряють можливі атаки лише відповідно до повідомлень про помилки.

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

Тестування безпеки веб-додатків проти введення SQL

Тестування безпеки веб-додатків пояснюється на простих прикладах:

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

Важливо: Цей тест ін'єкції SQL слід тестувати лише в тестовому середовищі.

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

ВИБЕРІТЬ * ВІД користувачів, ДЕ Ім'я користувача = ‘” & strUserName & “‘ І Пароль = ‘” & strPassword & '’; '

Якщо тестер введе Джона як ім'я strUserName (у текстовому полі для імені користувача), а Сміта як strPassword (у текстовому полі для пароля), наведений вище оператор SQL стане:

SELECT * FROM Users WHERE User_Name = 'John' AND Password = 'Smith’;

Якщо тестер введе John’– як strUserName і не strPassword, оператор SQL стане:

SELECT * FROM Users WHERE User_Name = 'John'-- AND Password = 'Smith’;

Зверніть увагу, що частина оператора SQL після Джона перетворюється на коментар. Якщо в таблиці Користувачів є користувач із іменем користувача John, програма може дозволити тестувальнику ввійти як користувач John. Тепер тестувальник міг переглянути приватну інформацію користувача Джона.

Що робити, якщо тестувальник не знає імені жодного існуючого користувача програми? У такому випадку тестувальник може спробувати поширені імена користувачів, такі як адміністратор, адміністратор та системний адміністратор. Якщо жоден із цих користувачів не існує в базі даних, тестер може ввести John 'або' x '=' x як strUserName та Smith 'або' x '=' x як strPassword. Це призведе до того, що оператор SQL стане таким, як наведений нижче.

SELECT * FROM Users WHERE User_Name = 'John' or 'x'='x' AND Password = 'Smith’ or ‘x’=’x’;

Оскільки умова ‘x’ = ’x’ завжди істинна, набір результатів буде складатися з усіх рядків у таблиці Користувачі. Додаток може дозволити тестувальнику увійти як перший користувач у таблиці Користувачі.

Важливо: Тестер повинен попросити адміністратора бази даних або розробника скопіювати відповідну таблицю, перш ніж робити наступні атаки.

Якби випробувач увійшов до Джона '; DROP таблиця users_details; ’- як strUserName і будь-що як strPassword, оператор SQL стане таким, як наведений нижче.

SELECT * FROM Users WHERE User_Name = ‘John’; DROP table users_details;’ –‘ AND Password = 'Smith';

Цей вислів може призвести до того, що таблиця “деталі_користувачів” буде назавжди видалена з бази даних.

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

Введення SQL може бути можливим у програмах, що використовують SSL. Навіть брандмауер може бути не в змозі захистити програму від цієї техніки.

Я спробував пояснити цю техніку атаки у простій формі. Я хотів би повторити цю атаку, протестувати її слід лише в тестовому середовищі, а не в середовищі розробки, виробничому середовищі чи будь-якому іншому середовищі.

найкраща ідея для python на mac

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

Пов’язане читання: Тестування безпеки веб-програми . Перевірте це, щоб отримати докладнішу інформацію про різні веб-вразливості.

Вразливі частини цієї атаки

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

Також хорошою практикою є планування того, яке саме поле системи має бути тестоване і в якому порядку. За свою кар’єру тестування я зрозумів, що не є гарною ідеєю тестувати поля проти атак SQL випадковим чином, оскільки деякі поля можна пропустити.

Оскільки ця атака виконується в базі даних, усі частини системи введення даних, поля введення та посилання на веб-сайт є вразливими.

До вразливих частин належать:

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

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

Автоматизація тестів ін’єкцій SQL

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

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

Це досить надійний інструмент.

Однак тест вже повинен бути автоматизований на рівні API, що не так просто. Інший можливий спосіб автоматичного тестування - це використання різних плагінів браузера.

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

Порівняння з іншими атаками

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

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

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

Висновок

Сподіваюся, ви б чітко уявили, що таке ін’єкція SQL і як нам запобігти цим атакам.

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

Оскільки тестування проти цієї ін’єкції допомагає знайти найбільше важливі уразливості безпеки , також рекомендується інвестувати у свої знання та інструменти тестування.

Якщо планується тестування безпеки, то тестування проти SQL Injection слід запланувати як одну з перших частин тестування.

Ви стикалися з якоюсь типовою інжекцією SQL? Не соромтеся поділитися своїм досвідом у розділі коментарів нижче.

Рекомендована література

^