Преглед садржаја
ПХП настао као свестран језик који нам омогућава да манипулишемо подацима унетим путем обрасца ХТМЛНаравно, унутар њеног устава постоји више алата и способности него само ово.Разноврсност и једноставност употребе чине га једним од најраспрострањенијих језика у свету за веб пројекте који се крећу од једноставних образаца за контакт, па до почетка великих апликација као што су Фејсбук.
Проблем са свестраношћу и лакоћом употребе је у томе што програмер није приморан да пише сигуран код, али са врло несигурним функцијама код ће радити савршено, и ту долазе проблеми.
Заштита веб апликација је нешто што немате од почетка ПХПМеђутим, то га не чини несигурним језиком, јер безбедност одговара скупу техника и стилова рада које програмер мора знати да би их применио на своје скрипте.
ОквириИстина је да се појавом оквири Многе безбедносне функције су подразумевано укључене, међутим нису сви програмери користили а оквир у старијим апликацијама и могуће је да за неке функције користите а оквир бити вишак.
Кључеви за постизање безбедности у нашим апликацијама помоћу ПХП То су: контрола и оплемењивање података које корисник уноси у образац, верификација порекла захтева ХТТП које наша апликација прима и коначно избећи директно извршавање инструкција путем образаца.
У програмирању постоји правило и оно је универзално, односно не односи се само на ПХПЧини се да су сви подаци које апликација не генерише потенцијално злонамерни, што значи да ако није нешто што је резултат који смо програмирали не можемо веровати.
Овај принцип се примењује на вредности образаца, датотеке, Базе података, па је први корак за побољшање наше безбедности филтрирање података ако морамо да ступимо у интеракцију са овим елементима.
Навешћемо неке од најбољих пракси које можемо применити када филтрирамо податке који су унети у наш образац:
Користите листе дозвољених вредностиОвом праксом знамо да ако подаци који долазе кроз образац не пролазе кроз нашу листу дозвољених и сигурних вредности, не би требало да иду у обраду, у овом тренутку се мора послати порука кориснику да исправи своје податке.
Никада не исправљајте неважеће податкеМожда звучи примамљиво направити врло интелигентан систем који исправља податке с недосљедностима, али дугорочно нам то може донијети проблеме и рањивости, па ако откријемо нешто неправилно, не бисмо га требали обрадити.
Користите конвенцију именовањаОвом праксом можемо разликовати сигурне податке и вредности од оних података и вредности које је унео корисник, чиме ћемо у оквиру програмирања појачати употребу првих за обраду.
Постоји две врсте филтрирања што можемо да урадимо, прва је од вредности које познајемо, а друга од вредности које не познајемо.
Тхе први То је врло лако учинити, само морамо извести рутине са списковима познатих елемената и упоредити их, међутим ово је гломазно и тешко се изводи у већим апликацијама. Тхе друго То подразумева креирање рутина које процењују структуру вредности и ако она одговара оној коју сматрамо сигурном, пуштамо је на обраду, у супротном бацамо грешку, будући да је динамичке природе ово је препоручени формат.
Погледајмо испод пример кода прве врсте филтрирања:
У следећем коду видећемо како стварамо образац који има елемент изаберите Да би корисник одабрао боју, будући да корисник не мора писати податке за директан унос, можемо упасти у грешку ако не потврдимо информације, али то само значи да имамо сигурносну празнину с обзиром на образац који се примјењује истим именима можемо добити потенцијално опасне информације.
Зато једном када се вредност обрасца пошаље ПОШТА, наша скрипта процјењује могуће вриједности, а у случају било које од очекиваних просљеђујемо је нашем низу сигурних вриједности као што видимо доље.
Овим смо проблем решили на једноставан начин, међутим да је листа уместо три боје имала сто, прича о једноставности би била другачија.
У следећем примеру динамички ћемо потврдити поље које је корисник унео на одговарајући начин, за то морамо да користимо регуларни изрази и на овај начин избећи унос знакова који доводе у опасност нашу обраду, такође проценити величину уноса и на тај начин избећи а преливање или преоптерећење нашег типа података у обради програма. Погледајмо код на слици:
ЕНЛАРГЕ
Овде је кључ за постизање валидације тачно знати шта желимо да обрадимо, на пример у случају корисничког имена, оно што обично тражимо су алфанумерички знакови и цртице, зато у редовна фраза Ово потврђујемо, такође нам треба да буде веће од 0 знакова и максимално 32, ако оно што је унео корисник задовољава све ово, пролази валидацију, најбоље од свега је што ово ради са вредношћу као што је сто, пошто је потпуно динамичан.Још једна претња од које морамо да се заштитимо је извршавање скрипти са других локација, захваљујући АЈАКС Можемо послати обрасце од клијента на руту, укључујући врсту захтева и вредности које желимо.
Мекано местоОва врста слабости олакшава некоме да прегледа наш образац и провери наша поља, при чему поседовањем ових имена и метода ХТТП Покушајте да пошаљете несигурне вредности, да бисмо то избегли, морамо применити технике које нам омогућавају да потврдимо одакле захтев потиче и ако је безбедно дозволити његово извршавање, у супротном избегавајте наставак путање унутар нашег програма.
Да би се избегао овај проблем, систем жетони И сесије, тако да приликом подношења обрасца процењујемо да ли је сесија иста као она која је успостављена на сигуран начин, па злонамерни корисник не може да настави.
Кључни циљ нападача је да убаци свој код у наше окружење, за то користе ињекције кода СКЛ, овај напад је познат као СКЛ Ињецтион, где са незаштићеним обрасцима и неправилном обрадом можемо добити упутства СКЛ директно без ограничења. На пример, ако је наша процена СКЛ је следеће у нашем писму ПХП:
Било којег корисника система можемо користити као корисничко име и за Лозинка користимо два скрипта “--” са овим можемо без проблема проћи безбедност, пошто су две скрипте коментар СКЛ и стога лозинка неће бити процењена.
Прави начин да се процените СКЛ који потиче од корисника, уклања посебне и опасне знакове, само процењујући безбедне изразе. Погледајмо пример испод како избећи претходни случај:
Прва ствар коју морамо да урадимо је а дезинфекција података, односно спречити да чисти стигне из форме у нашу СКЛ; Друга ствар коју морамо да проценимо је да ако две вредности одговарају приступу, али потоња одговара логици сваке од њих, да видимо на слици како постижемо циљ:
ЕНЛАРГЕ
Овде смо урадили коришћење алата припремљене изјаве оно што нам књижара дозвољава ПДО за повезивање са База података, овим постижемо да се оно што се унесе никада не узима у други контекст који није податак, такође видимо да уместо коришћења методе ПОШТА Користили смо наш сигурни низ, то значи да су наши подаци већ верификовани, па је ризик мањи.Овим смо завршили овај водич, јер видимо да су радње које можемо подузети да би наша апликација била сигурнија једноставне, не захтијевају људске напоре, али нам помажу да избјегнемо најчешће нападе, а можда и најчешће … дати су. Постоји лоша перцепција о томе ПХП оних који кажу да је то несигуран језик, али реалност је да несигурност производи програмер, јер језик има само алате које можемо користити за побољшање и спречавање напада на наше апликације путем података које је унео корисник.