Урок за тестване на SQL инжектиране (Пример и предотвратяване на атака на SQL инжектиране)

sql injection testing tutorial example

Примери за SQL инжектиране и начини за предотвратяване на атаки за SQL инжектиране върху уеб приложения

Докато тествате уебсайт или система, целта на тестера е да гарантира дали тестваният продукт е възможно най-добре защитен.

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

SQL Injection се счита за една от най-често срещаните атаки, тъй като може да доведе до сериозни и вредни последици за вашата система и чувствителни данни.

Какво ще научите:

• Какво е SQL инжектиране?
• Рискове от SQL инжектиране
• Същността на тази атака
• Препоръчан инструмент
  • # 1) Киуван
• Тестване на сигурността на уеб приложения срещу SQL инжектиране
• Уязвими части от тази атака
• Автоматизиране на тестове за инжектиране на SQL
• Сравнение с други атаки
• Заключение
• Препоръчително четене

Какво е SQL инжектиране?

Някои от потребителските входове може да се използват при кадриране SQL изявления които след това се изпълняват от приложението в базата данни. Възможно е приложение да НЕ обработва правилно дадените от потребителя входове.

Ако случаят е такъв, злонамерен потребител може да предостави неочаквани входни данни за приложението, които след това се използват за рамкиране и изпълнение на SQL изрази в базата данни. Това се нарича SQL Injection. Последиците от подобно действие могат да бъдат тревожни.

Както подсказва самото име, целта на атаката SQL Injection е да инжектира злонамерения SQL код.

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

Вместо коректни данни, ако се въведе някакъв злонамерен код, тогава има вероятност да се случи сериозна повреда на базата данни и на цялата система.

SQL инжектирането се извършва с езика за програмиране SQL. SQL (Структуриран език за заявки) се използва за управление на данните, съхранявани в базата данни. Следователно по време на тази атака този код на програмния език се използва като злонамерена инжекция.

Това е една от най-популярните атаки, тъй като базите данни се използват за почти всички технологии.

Много приложения използват някакъв тип база данни. Тестваното приложение може да има потребителски интерфейс, който приема потребителски вход, който се използва за изпълнение на следните задачи:

# 1) Покажете съответните съхранени данни на потребителя, напр. приложението проверява идентификационните данни на потребителя, използвайки информацията за вход, въведена от потребителя, и излага на потребителя само съответната функционалност и данни

# две) Запазете данните, въведени от потребителя, в базата данни, напр. след като потребителят попълни формуляр и го изпрати, приложението продължава да запазва данните в базата данни; тези данни след това се предоставят на потребителя в същата сесия, както и в следващите сесии

Рискове от SQL инжектиране

В днешно време база данни се използва за почти всички системи и уебсайтове, тъй като данните трябва да се съхраняват някъде.

Тъй като чувствителните данни се съхраняват в базата данни, има повече рискове, свързани със сигурността на системата. Ако даден личен уебсайт или данни от блог бъдат откраднати, тогава няма да има големи щети в сравнение с данните, които ще бъдат откраднати от банковата система.

Основната цел на тази атака е да проникне в базата данни на системата, поради което последиците от тази атака наистина могат да бъдат вредни.

Следните неща може да са резултат от SQL Injection

• Хакване на акаунт на друг човек.
• Кражба и копиране на чувствителни данни на уебсайт или система.
• Промяна на чувствителните данни на системата.
• Изтриване на чувствителните данни на системата.
• Потребителят може да влезе в приложението като друг потребител, дори като администратор.
• Потребителят може да преглежда лична информация, принадлежаща на други потребители, напр. подробности за профилите на други потребители, подробности за транзакциите и др.
• Потребителят може да промени информацията за конфигурацията на приложението и данните на останалите потребители.
• Потребителят може да променя структурата на базата данни; дори изтриване на таблици в базата данни на приложенията.
• Потребителят може да поеме контрола върху сървъра на базата данни и да изпълнява команди върху него по желание.

Гореизброените рискове наистина могат да се считат за сериозни, тъй като възстановяването на база данни или нейните данни може да струва много. Това може да струва на вашата компания репутация и пари за възстановяване на изгубените данни и система. Ето защо е силно препоръчително да защитите системата си от този тип атака и да разгледате Тестването на сигурността като добра инвестиция в репутацията на вашия продукт и компания.

Като тестер бих искал да коментирам, че тестването срещу възможни атаки е добра практика, дори ако Тестване на сигурността не беше планирано. По този начин можете да защитите и тествате продукта срещу неочаквани случаи и злонамерени потребители.

Същността на тази атака

Както бе споменато по-рано, същността на тази атака е да взломи базата данни със злонамерена цел.

За да извършите това Тестване на защитата, първоначално трябва да намерите уязвимите системни части и след това да изпратите злонамерен SQL код през тях до базата данни. Ако тази атака е възможна за система, тогава ще бъде изпратен подходящ злонамерен SQL код и в базата данни могат да бъдат извършени вредни действия.

Всяко поле на уебсайта е като врата към базата данни. Всички данни или входни данни, които обикновено въвеждаме във всяко поле на системата или уебсайта, отиват в заявката за база данни. Следователно, вместо правилни данни, ако бихме въвели злонамерен код, той може да бъде изпълнен в заявката за база данни и да доведе до вредни последици.

Препоръчан инструмент

# 1) Киуван

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

Интегрирайте Kiuwan във вашата IDE за незабавна обратна връзка по време на разработката. Kiuwan поддържа всички основни езици за програмиране и се интегрира с водещите инструменти DevOps.

=> Сканирайте кода си безплатно

За да извършим тази атака, трябва да променим действието и целта на подходяща заявка за база данни. Един от възможните методи за изпълнение е да направите заявката винаги вярна и след това да вмъкнете вашия злонамерен код. Промяната на заявката за база данни на винаги true може да се извърши с прост код като ‘или 1 = 1; -.

Тестерите трябва да имат предвид, че докато проверяват дали промяната на заявката на винаги истина може да се извърши или не, трябва да се изпробват различни кавички - единични и двойни. Следователно, ако сме опитали код като „или 1 = 1; -, също трябва да опитаме кода с двойни кавички“ или 1 = 1; -.

Например, нека помислим, че имаме заявка, която търси въведената дума в таблицата на базата данни:

изберете * от бележките nt, където nt.subject = ‘дума за търсене’;

Следователно вместо думата за търсене, ако въведем SQL Injection заявка ‘или 1 = 1; -, тогава заявката ще стане винаги вярна.

изберете * от бележките nt, където nt.subject = ‘‘ или 1 = 1; -

В този случай параметърът „subject“ се затваря с офертата и тогава имаме код или 1 = 1, което прави заявката винаги вярна. Със знака „-“ коментираме останалата част от кода на заявката, която няма да бъде изпълнена. Това е един от най-популярните и най-лесните начини да започнете да контролирате заявката.

Няколко други кода също могат да бъдат използвани, за да направят заявката винаги вярна, като:

• ‘Или‘ abc ‘=‘ abc ‘; -
• ‘Или‘ ‘=‘ ‘; -

Най-важната част тук е, че след запетая можем да въведем всеки злонамерен код, който бихме искали да бъде изпълнен.

Например, може да е „или 1 = 1; пуснете бележки за масата; -

Ако тази инжекция е възможна, тогава може да бъде написан всеки друг злонамерен код. В този случай това ще зависи само от знанието и намерението на злонамерения потребител. Как да проверя инжектирането на SQL?

Проверката за тази уязвимост може да се извърши много лесно. Понякога е достатъчно да напишете „или“ знак в тестваните полета. Ако връща някакво неочаквано или извънредно съобщение, тогава можем да сме сигурни, че за това поле е възможно SQL Injection.

Например , ако получите съобщение за грешка като „Вътрешна грешка на сървъра“ като резултат от търсенето, тогава можем да сме сигурни, че тази атака е възможна в тази част на системата.

Други резултати, които могат да уведомят за възможна атака, включват:

• Заредена е празна страница.
• Няма съобщения за грешка или успех - функционалността и страницата не реагират на входа.
• Съобщение за успех за злонамерен код.

Нека да разгледаме как това работи на практика.

Например, Нека тестваме дали подходящ прозорец за вход е уязвим за SQL Injection. За тази цел в полето за имейл адрес или парола просто въвеждаме знак, както е показано по-долу.

Ако такова въвеждане връща резултат като съобщение за грешка „Вътрешна грешка на сървъра“ или някакъв друг изброен неподходящ резултат, тогава можем да сме почти сигурни, че тази атака е възможна за това поле.

Много сложно SQL инжекционен код може също да бъде съден. Бих искал да спомена, че през кариерата си не съм срещал случай, когато в резултат на знака е имало съобщение „Вътрешна грешка в сървъра“, но на моменти полетата не са реагирали за по-сложен SQL код.

Следователно проверката за SQL Injection с една кавичка ‘е доста надежден начин да проверите дали тази атака е възможна или не.

Ако единичната кавичка не връща неподходящ резултат, тогава можем да опитаме да въведем двойни кавички и да проверим резултатите.

Също така, SQL кодът за промяна на заявката на винаги true може да се разглежда като начин за проверка дали тази атака е възможна или не. Той затваря параметъра и променя заявката на „true“. Следователно, ако не е валидиран, такъв вход може също да върне всеки неочакван резултат и да информира същото, че в този случай е възможна тази атака.

Проверка за възможни 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 Injection е възможно за този уебсайт. По-късно можем да се опитаме да изпратим по-сложен SQL код чрез връзката на уебсайта.

За да проверите дали тази атака е възможна чрез връзката на уебсайта или не, код като ‘или 1 = 1; - също може да бъде изпратен.

Като опитен софтуерен тестер, бих искал да напомня, че не само неочакваното съобщение за грешка може да се разглежда като уязвимост на SQL Injection. Много тестери проверяват за възможни атаки само в съответствие със съобщенията за грешки.

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

Тестване на сигурността на уеб приложения срещу SQL инжектиране

Тестване на сигурността на уеб приложения, обяснени с прости примери:

Тъй като последиците от допускането на тази техника на уязвимост могат да бъдат сериозни, следва, че тази атака трябва да бъде тествана по време на тестването на защитата на приложение. Сега с преглед на тази техника, нека разберем няколко практически примера за SQL инжектиране.

Важно: Този тест за инжектиране на SQL трябва да бъде тестван само в тестовата среда.

Ако приложението има страница за вход, възможно е приложението да използва динамичен SQL, като например изявлението по-долу. Очаква се този оператор да върне поне един ред с потребителски данни от таблицата Потребители като набор от резултати, когато в SQL израза има ред с потребителско име и парола.

ИЗБЕРЕТЕ * ОТ Потребители КЪДЕ Име на потребителя = ‘” & strUserName & “‘ И Парола = ‘” & strPassword & '’; '

Ако тестерът въведе John като strUserName (в текстовото поле за потребителско име) и Smith като strPassword (в текстовото поле за парола), горният SQL израз ще стане:

Ако тестерът въведе John’– като strUserName и без strPassword, SQL изразът ще стане:

Имайте предвид, че частта от SQL израза след Джон се превръща в коментар. Ако има потребител с потребителското име на John в таблицата Users, приложението може да позволи на тестера да влезе като потребител John. Тестерът вече можеше да види личната информация на потребителя Джон.

Какво ще стане, ако тестерът не знае името на нито един съществуващ потребител на приложението? В такъв случай тестерът може да опита общи потребителски имена като администратор, администратор и sysadmin. Ако никой от тези потребители не съществува в базата данни, тестерът може да въведе John ’или‘ x ’=’ x като strUserName и Smith ’или‘ x ’=’ x като strPassword. Това би накарало SQL израза да стане като този по-долу.

Тъй като условието ‘x’ = ’x’ винаги е вярно, наборът от резултати ще се състои от всички редове в таблицата Users. Приложението може да позволи на тестера да влезе като първи потребител в таблицата Потребители.

Важно: Изпитателят трябва да поиска от администратора на базата данни или разработчика да копира въпросната таблица, преди да опита следните атаки.

Ако тестерът щеше да влезе в Джон ’; DROP таблица users_details; ’- като strUserName и каквото и да е като strPassword, SQL изразът ще стане като този по-долу.

Това изявление може да доведе до трайно изтриване на таблицата „потребителски_детайли“ от базата данни.

Въпреки че горните примери се занимават с използването на техниката за инжектиране на SQL само на страницата за вход, тестващият трябва да тества тази техника на всички страници на приложението, които приемат въвеждане от потребителя в текстов формат напр. страници за търсене, страници за обратна връзка и т.н.

SQL инжектирането може да е възможно в приложения, които използват SSL. Дори защитната стена може да не е в състояние да защити приложението срещу тази техника.

Опитах се да обясня тази техника на атака в проста форма. Бих искал да повторя тази атака, трябва да бъде тествана само в тестова среда, а не в среда за разработка, производствена среда или друга среда.

безплатно изтегляне на шаблон за тест за Excel

Вместо да тествате ръчно дали приложението е уязвимо на SQL атака или не, може да се използва Скенер за уеб уязвимост който проверява за тази уязвимост.

Свързано четене: Тестване на сигурността на уеб приложението . Проверете това за повече подробности относно различните уеб уязвимости.

Уязвими части от тази атака

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

Също така е добра практика да планирате коя област на системата трябва да бъде тествана точно и в какъв ред. В моята тестова кариера научих, че не е добра идея да тествате полета срещу SQL атаки на случаен принцип, тъй като някои полета могат да бъдат пропуснати.

Тъй като тази атака се извършва в базата данни, всички части на системата за въвеждане на данни, полета за въвеждане и връзките към уебсайта са уязвими.

Уязвимите части включват:

• Полета за вход
• Полета за търсене
• Полета за коментари
• Всички други полета за въвеждане и запис на данни
• Връзки към уебсайта

Важно е да се отбележи, че докато тествате срещу тази атака, не е достатъчно да проверите само едно или няколко полета. Доста често се случва, че едно поле може да бъде защитено срещу SQL Injection, но след това друго не. Ето защо е важно да не забравите да тествате всички полета на уебсайта.

Автоматизиране на тестове за инжектиране на SQL

Тъй като някои тествани системи или уебсайтове могат да бъдат доста сложни и да съдържат чувствителни данни, тестването ръчно може да бъде наистина трудно и също отнема много време. Следователно тестването срещу тази атака със специални инструменти може да бъде наистина полезно понякога.

Един такъв инструмент за SQL Injection е Потребителски интерфейс на SOAP . Ако имаме автоматизирани тестове за регресия на ниво API, можем също да превключим проверката срещу тази атака с помощта на този инструмент. В инструмента SOAP UI вече има подготвени кодови шаблони за проверка срещу тази атака. Тези шаблони също могат да бъдат допълнени от вашия собствен писмен код.

Това е доста надежден инструмент.

Тестът обаче вече трябва да бъде автоматизиран на ниво API, което не е толкова лесно. Друг възможен начин за автоматично тестване е чрез използване на различни приставки за браузър.

Трябва да се спомене, че дори автоматизираните инструменти да ви спестят време, те не винаги се считат за много надеждни. Ако тестваме банкова система или уебсайт с много чувствителни данни, силно се препоръчва да го тествате ръчно. Къде можете да видите точните резултати и да ги анализирате. Също така, в този случай можем да сме сигурни, че нищо не е пропуснато.

Сравнение с други атаки

SQL Injection може да се счита за една от най-сериозните атаки, тъй като влияе на базата данни и може да причини сериозни щети на вашите данни и на цялата система.

Със сигурност това може да има по-сериозни последици от Javascript Injection или HTML Injection, тъй като и двете се извършват от страна на клиента. За сравнение, с тази атака можете да имате достъп до цялата база данни.

Трябва да се спомене, че за да тествате срещу тази атака, трябва да имате доста добри познания за езика за програмиране SQL и като цяло трябва да знаете как работят заявките към бази данни. Също така, докато извършвате тази инжекционна атака, трябва да бъдете по-внимателни и наблюдателни, тъй като всяка неточност може да бъде оставена като SQL уязвимости.

Заключение

Надявам се, че сте имали ясна представа какво е SQL инжекция и как трябва да предотвратим тези атаки.

Горещо се препоръчва да тествате срещу този тип атака всеки път, когато се тества система или уебсайт с база данни. Всяка оставена уязвимост на база данни или система може да коства репутацията на компанията и много ресурси за възстановяване на цялата система.

Тъй като тестването срещу тази инжекция помага да се намери най-много важни уязвимости в сигурността , препоръчва се също да инвестирате във вашите знания и инструменти за тестване.

Ако се планира тестване на сигурността, тогава тестването срещу SQL Injection трябва да бъде планирано като една от първите части за тестване.

Попадали ли сте на някакво типично SQL инжектиране? Чувствайте се свободни да споделите своя опит в раздела за коментари по-долу.

Препоръчително четене

• Урок за инжектиране на HTML: Видове и превенция с примери
• Най-добри инструменти за тестване на софтуер 2021 г. (Инструменти за автоматизация на QA теста)
• Уроци за задълбочено затъмнение за начинаещи
• Урок за деструктивно изпитване и безразрушително тестване
• Изтегляне на eBook за тестване на Primer
• Функционално тестване срещу нефункционално тестване
• Урок за тестване на SOA: Методология за тестване за архитектурен модел на SOA
• Учебник за тестване по двойки или за всички двойки с инструменти и примери