Водич за тестирање СКЛ убризгавања (пример и спречавање напада СКЛ убризгавањем)

sql injection testing tutorial example

Примери СКЛ убризгавања и начини за спречавање напада СКЛ убризгавања на веб апликације

Током тестирања веб странице или система, циљ тестера је да осигура да ли је тестирани производ што је могуће заштићенији.

Испитивање сигурности се обично изводи у ту сврху. Да бисмо извршили ову врсту тестирања, у почетку морамо размотрити који напади ће се највероватније догодити. СКЛ Ињецтион је један од тих напада.

СКЛ Ињецтион се сматра једним од најчешћих напада, јер може донијети озбиљне и штетне посљедице на ваш систем и осјетљиве податке.

Шта ћете научити:

• Шта је СКЛ ињекција?
• Ризици убризгавања СКЛ-а
• Суштина овог напада
• Препоручени алат
  • # 1) Киуван
• Испитивање сигурности веб апликација против убризгавања СКЛ-а
• Рањиви делови овог напада
• Аутоматизација тестова убризгавања СКЛ
• Поређење са другим нападима
• Закључак
• Препоручено читање

Шта је СКЛ ињекција?

Неки кориснички улази могу се користити за кадрирање СКЛ изјаве које затим извршава апликација на бази података. Могуће је да апликација НЕ обрађује правилно уносе које је дао корисник.

Ако је то случај, злонамерни корисник може пружити неочекиване улазе у апликацију који се затим користе за уоквиривање и извршавање СКЛ израза у бази података. То се назива СКЛ Ињецтион. Последице такве акције могу бити алармантне.

Као што само име говори, сврха напада СКЛ Ињецтион је убризгавање злонамерног СКЛ кода.

Свако поље веб странице је попут улаза у базу података. У образац за пријаву корисник уноси податке за пријаву, у поље за претрагу корисник уноси текст за претрагу, у образац за спремање података корисник уноси податке које треба сачувати. Сви ови наведени подаци иду у базу података.

Уместо тачних података, ако се унесе злонамерни код, постоје могућности да се догоди озбиљна штета у бази података и целом систему.

СКЛ Ињецтион се врши помоћу програмског језика СКЛ. СКЛ (језик структурираних упита) користи се за управљање подацима који се чувају у бази података. Због тога се током овог напада овај програмски језик користи као злонамерна ињекција.

Ово је један од најпопуларнијих напада, јер се базе података користе за готово све технологије.

Многе апликације користе неку врсту базе података. Апликација која се тестира може имати кориснички интерфејс који прихвата унос корисника који се користи за извршавање следећих задатака:

# 1) Покажите релевантне сачуване податке кориснику, нпр. апликација проверава акредитиве корисника помоћу података за пријављивање које је корисник унео и излаже кориснику само релевантне функције и податке

#два) Спремите податке које је корисник унео у базу података нпр. након што корисник попуни образац и преда га, апликација наставља са спремањем података у базу података; ти подаци се затим стављају на располагање кориснику у истој сесији као и у наредним сесијама

Ризици убризгавања СКЛ-а

Данас се база података користи за готово све системе и веб локације, јер би подаци требали негде бити ускладиштени.

Како се осетљиви подаци чувају у бази података, постоји више ризика који укључују сигурност система. Ако би било која лична веб локација или подаци блога били украдени, тада неће настати велика штета у поређењу са подацима који би били украдени из банкарског система.

Главна сврха овог напада је хаковање базе података система, па последице овог напада заиста могу бити штетне.

Следеће ствари могу произаћи из СКЛ Ињецтион-а

• Хакирање рачуна друге особе.
• Крађа и копирање осетљивих података веб странице или система.
• Промена осетљивих података система.
• Брисање осетљивих података система.
• Корисник се могао пријавити у апликацију као други корисник, чак и као администратор.
• Корисник је могао да прегледа приватне податке који припадају другим корисницима, нпр. детаљи профила других корисника, детаљи трансакција итд.
• Корисник може променити информације о конфигурацији апликације и податке осталих корисника.
• Корисник је могао изменити структуру базе података; чак и брисање табела у бази података апликација.
• Корисник је могао преузети контролу над сервером базе података и извршавати команде на њему по својој вољи.

Горе наведени ризици се заиста могу сматрати озбиљним, јер обнављање базе података или њених података може много коштати. Ваше компаније може коштати репутације и новца за враћање изгубљених података и система. Због тога се топло препоручује да заштитите свој систем од ове врсте напада и тестирање безбедности сматрате добром инвестицијом у репутацију вашег производа и компаније.

Као тестер, желео бих да коментаришем да је тестирање против могућих напада добра пракса чак и ако је Испитивање сигурности није било планирано. На овај начин можете заштитити и тестирати производ од неочекиваних случајева и злонамерних корисника.

Суштина овог напада

Као што је раније поменуто, суштина овог напада је хаковање базе података са злонамерном сврхом.

Да бисте извршили ово тестирање безбедности, у почетку морате да пронађете рањиве системске делове, а затим преко њих пошаљете злонамерни СКЛ код у базу података. Ако је овај напад могућ за систем, тада ће се послати одговарајући злонамерни СКЛ код и у бази података могу се извршити штетне радње.

Свако поље веб странице је попут улаза у базу података. Сви подаци или уноси које обично унесемо у било које поље система или веб локације иду на упит базе података. Стога, уместо тачних података, ако бисмо укуцали било какав злонамерни код, он би могао да се изврши у упиту базе података и донесе штетне последице.

Препоручени алат

# 1) Киуван

Лако пронађите и поправите рањивости попут СКЛ убризгавања у коду у свакој фази СДЛЦ-а. Киуван је усклађен са најстрожим безбедносним стандардима, укључујући ОВАСП, ЦВЕ, САНС 25, ХИППА и друге.

Интегришите Киуван у свој ИДЕ за тренутне повратне информације током развоја. Киуван подржава све главне програмске језике и интегрише се са водећим ДевОпс алатима.

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

Да бисмо извршили овај напад, морамо променити чин и сврху одговарајућег упита базе података. Једна од могућих метода за његово извршење је да упит увек буде истинит и након тога убаците злонамерни код. Промена упита базе података у увек истинито може се извршити једноставним кодом као што је ‘или 1 = 1; -.

Испитивачи треба да имају на уму да, док проверавају да ли се промена упита у увек тачно може извршити или не, треба испробати различите цитате - појединачне и двоструке. Стога, ако смо пробали код попут „или 1 = 1; -, требало би да испробамо и код са двоструким наводницима“ или 1 = 1; -.

На пример, узмимо у обзир да имамо упит који тражи унету реч у табели базе података:

изаберите * из напомена нт где је нт.субјецт = 'реч_потраге';

Стога, уместо речи за претрагу, ако унесемо упит за СКЛ Ињецтион ‘или 1 = 1; -, тада ће упит постати увек истинит.

изаберите * из напомена нт где је нт.субјецт = ‘‘ или 1 = 1; -

У овом случају параметар „субјецт“ затвара се наводником и тада имамо код или 1 = 1, што чини упит увек истинитим. Знаком „-“ коментаришемо остатак кода упита који се неће извршити. То је један од најпопуларнијих и најлакших начина да започнете контролу упита.

Неколико других кодова се такође може користити да би се упит увек учинио тачним, попут:

• „Или„ абц “=„ абц “; -
• ‘Или‘ ‘=‘ ‘; -

Овде је најважније да након знака зареза можемо да унесемо било који злонамерни код који бисмо желели да се изврши.

На пример, може бити ‘или 1 = 1; испустите белешке у табели; -

Ако је ово убризгавање могуће, тада се може написати било који други злонамерни код. У овом случају, то ће зависити само од знања и намере злонамерног корисника. Како проверити убризгавање СКЛ-а?

Провера ове рањивости може се извршити врло лако. Понекад је довољно да се у тестирана поља укуца знак „или“. Ако врати било какву неочекивану или изванредну поруку, можемо бити сигурни да је за то поље могуће убризгавање СКЛ-а.

На пример , ако као резултат претраге добијете поруку о грешци попут „Интерна грешка сервера“, можемо бити сигурни да је овај напад могућ у том делу система.

Остали резултати који могу извести могући напад укључују:

• Учитана празна страница.
• Нема порука о грешкама или успеху - функционалност и страница не реагују на унос.
• Порука о успеху за злонамерни код.

Погледајмо како ово функционише у пракси.

На пример, Испробајмо да ли је одговарајући прозор за пријаву рањив за СКЛ Ињецтион. У ту сврху у поље адресе е-поште или лозинке само откуцамо знак као што је приказано доле.

Ако такав унос врати резултат као што је порука о грешци „Интерна грешка сервера“ или било који други наведени неприкладни резултат, тада можемо бити готово сигурни да је овај напад могућ за то поље.

Врло зезнуто СКЛ Ињецтион цоде такође може бити суђено. Желео бих да напоменем да у својој каријери нисам срео ниједан случај када је као знак била порука „Интерна грешка сервера“, али понекад поља нису реаговала на сложенији СКЛ код.

Стога је провера СКЛ Ињецтион-а са једним наводником ‘прилично поуздан начин да се провери да ли је овај напад могућ или не.

Ако појединачни наводник не даје неприкладан резултат, можемо покушати да унесемо двоструке наводнике и проверимо резултате.

Такође, СКЛ код за промену упита у увек истинит може се сматрати начином да се провери да ли је овај напад могућ или не. Затвара параметар и мења упит у „тачно“. Стога, ако није потврђен, такав унос такође може вратити било који неочекивани резултат и исто обавестити да је овај напад у овом случају могућ.

Провера могућих СКЛ напада може се извршити и путем везе до веб странице. Претпоставимо да имамо везу до веб странице као хттп://ввв.тестинг.цом/боокс=1 . У овом случају „књиге“ је параметар, а „1“ је његова вредност. Ако бисмо у наведену везу написали ‘знак уместо 1, онда бисмо проверили да ли постоји могућност убризгавања.

Стога линк хттп://ввв.тестинг.цом/боокс= ће бити попут теста ако је за веб локацију могућ СКЛ напад хттп://ввв.тестинг.цом или не.

У овом случају, ако линк хттп://ввв.тестинг.цом/боокс= враћа поруку о грешци попут „Интерна грешка сервера“ или празну страницу или било коју другу неочекивану поруку о грешци, тада такође можемо бити сигурни да је за ту веб локацију могуће убризгавање СКЛ-а. Касније можемо да покушамо да пошаљемо лукавији СКЛ код преко везе до веб странице.

Да бисте проверили да ли је овај напад могућ путем везе до веб странице или не, може се послати и код попут „или 1 = 1; -.

Као искусни испитивач софтвера, желео бих да подсетим да се не само неочекивана порука о грешци може сматрати рањивошћу СКЛ Ињецтион. Многи тестери проверавају могуће нападе само у складу са порукама о грешкама.

Међутим, треба имати на уму да ниједна порука грешке у потврди или порука о успеху за злонамерни код такође не може бити знак да је овај напад могућ.

Испитивање сигурности веб апликација против убризгавања СКЛ-а

Испитивање безбедности веб апликација објашњено једноставним примерима:

Будући да би последице омогућавања ове технике рањивости могле бити озбиљне, произилази да овај напад треба тестирати током безбедносног тестирања апликације. Сада са прегледом ове технике, хајде да разумемо неколико практичних примера убризгавања СКЛ-а.

Важно: Овај тест убризгавања СКЛ треба тестирати само у тест окружењу.

Ако апликација има страницу за пријављивање, могуће је да апликација користи динамички СКЛ као што је изјава у наставку. Очекује се да ће ова наредба вратити барем један ред са корисничким детаљима из табеле Корисници као скуп резултата када постоји ред са корисничким именом и лозинком унетим у СКЛ израз.

СЕЛЕЦТ * ФРОМ Усерс ВХЕРЕ Усер_Наме = ‘” & стрУсерНаме & “‘ АНД Пассворд = ‘” & стрПассворд & '’; '

Ако би тестер унео Јохна као стрУсерНаме (у оквир за текст за корисничко име) и Смитх као стрПассворд (у поље за лозинку), горенаведени СКЛ израз би постао:

Ако би тестер унео Јохн’– као стрУсерНаме и без стрПассворд, СКЛ израз би постао:

Имајте на уму да је део СКЛ израза након Џона претворен у коментар. Ако је било ког корисника са корисничким именом Јохн у табели Усерс, апликација би могла да дозволи тестеру да се пријави као корисник Јохн. Тестер је сада могао да види приватне податке корисника Џона.

Шта ако тестер не зна име ниједног постојећег корисника апликације? У таквом случају, тестер може испробати уобичајена корисничка имена попут админ, администратор и сисадмин. Ако ниједан од ових корисника не постоји у бази података, тестер би могао да унесе Јохн 'или' к '=' к као стрУсерНаме и Смитх 'или' к '=' к као стрПассворд. То би проузроковало да СКЛ израз постане као онај у наставку.

Будући да је услов ‘к’ = ’к’ увек тачан, скуп резултата састојао би се од свих редова у табели Корисници. Апликација би могла да дозволи испитивачу да се пријави као први корисник у табели Корисници.

Важно: Тестер треба да затражи од администратора базе података или програмера да копира дотичну табелу пре покушаја следећих напада.

Ако би тестер ушао у Јована ’; ДРОП табела усерс_детаилс; ’- као стрУсерНаме и било шта као стрПассворд, СКЛ израз ће постати као онај у наставку.

Ова изјава може довести до трајног брисања табеле „усер_детаилс“ из базе података.

Иако се горњи примери баве употребом СКЛ технике убризгавања само странице за пријављивање, испитивач би требало да тестира ову технику на свим страницама апликације које прихватају унос корисника у текстуалном формату, нпр. странице за претраживање, странице са повратним информацијама итд.

СКЛ убризгавање може бити могуће у апликацијама које користе ССЛ. Чак и заштитни зид можда неће моћи да заштити апликацију од ове технике.

Покушао сам да објасним ову технику напада у једноставном облику. Желео бих да поновим да овај напад треба тестирати само у тест окружењу, а не у развојном окружењу, производном окружењу или било ком другом окружењу.

тест цасе темплате екцел бесплатно преузимање

Уместо да ручно тестирамо да ли је апликација рањива на СКЛ напад или не, могли бисмо користити а Скенер за рањивост веб-а која проверава ову рањивост.

Сродно читање: Испитивање безбедности веб апликације . Погледајте ово за више детаља о различитим веб рањивостима.

Рањиви делови овог напада

Пре започињања процеса тестирања, сваки искрени испитивач би требао мање-више знати који делови би били најосетљивији на могући напад.

Такође је добра пракса планирати које ће се поље система тачно тестирати и којим редоследом. У својој тестној каријери научио сам да није добра идеја насумично тестирати поља против СКЛ напада јер нека поља могу пропустити.

Како се овај напад изводи у бази података, сви делови система за унос података, поља за унос и везе до веб локација су рањиви.

Рањиви делови укључују:

• Поља за пријаву
• Поља за претрагу
• Поља коментара
• Било која друга поља за унос и чување података
• Везе до веб странице

Важно је приметити да током тестирања против овог напада није довољно проверити само једно или неколико поља. Сасвим је уобичајено да једно поље може бити заштићено од СКЛ Ињецтион-а, али друго не. Стога је важно да не заборавите да тестирате сва поља веб странице.

Аутоматизација тестова убризгавања СКЛ

Будући да неки тестирани системи или веб локације могу бити прилично сложени и садрже осетљиве податке, ручно тестирање може бити заиста тешко и такође одузима пуно времена. Стога тестирање против овог напада помоћу специјалних алата понекад може бити од велике помоћи.

Један такав алат за убризгавање СКЛ-а је СОАП УИ . Ако имамо аутоматизоване тестове регресије на нивоу АПИ-ја, помоћу ове алатке такође можемо пребацити проверу против овог напада. У СОАП УИ алату већ постоје припремљени предлошци кода за проверу против овог напада. Ти предлошци се такође могу допунити вашим писаним кодом.

То је прилично поуздан алат.

Међутим, тест би већ требало да буде аутоматизован на нивоу АПИ-ја, што није тако лако. Други могући начин аутоматског тестирања је коришћење различитих додатака за прегледач.

Треба напоменути да, чак и ако аутоматизовани алати штеде ваше време, не сматрају се увек врло поузданима. Ако тестирамо банкарски систем или било коју веб страницу са врло осетљивим подацима, топло се препоручује да је тестирате ручно. Где можете видети тачне резултате и анализирати их. Такође, у овом случају можемо бити сигурни да ништа није прескочено.

Поређење са другим нападима

СКЛ Ињецтион се може сматрати једним од најозбиљнијих напада, јер утиче на базу података и може нанети озбиљну штету вашим подацима и целом систему.

Сигурно може имати озбиљније последице од убризгавања Јавасцрипта или ХТМЛ убризгавања, јер се оба изводе на страни клијента. Поређења ради, овим нападом можете имати приступ целој бази података.

Треба напоменути да бисте за тестирање против овог напада требали имати прилично добро знање програмског језика СКЛ и уопште, требали бисте знати како раде упити база података. Такође током извођења овог ињекцијског напада требали бисте бити пажљивији и пажљивији, јер свака нетачност може бити СКЛ рањивост.

Закључак

Надам се да бисте имали јасну идеју шта је то СКЛ Ињецтион и како бисмо требали спречити ове нападе.

Међутим, топло се препоручује тестирање против ове врсте напада сваки пут када се тестира систем или веб локација са базом података. Било која преостала рањивост базе података или система може коштати репутацију компаније и пуно ресурса да би се вратио цео систем.

Како тестирање против ове ињекције помаже да се пронађе највише важне сигурносне рањивости , такође се препоручује да инвестирате у своје знање и алате за тестирање.

Ако је планирано безбедносно тестирање, тада би тестирање против СКЛ Ињецтион требало да буде планирано као један од првих делова тестирања.

Да ли сте наишли на неко типично СКЛ Ињецтион? Слободно поделите своја искуства у одељку за коментаре испод.

Препоручено читање

• Водич за ХТМЛ ињекције: Врсте и превенција са примерима
• Најбољи алати за тестирање софтвера 2021. године (КА Тест Аутоматион Тоолс)
• Дубински водичи за помрачење за почетнике
• Водич за испитивање разарања и испитивања без разарања
• Преузимање е-књиге за тестирање буквара
• Функционално тестирање вс нефункционално тестирање
• Водич за тестирање СОА: Методологија тестирања за модел архитектуре СОА
• Водич за тестирање у паровима или за све парове са алатима и примерима