6 Сигурносни ризици веб бакенда који треба размотрити у развоју

Предузмите мере у развоју да ојачате и одржавате заштитну веб локацију на мрежи.


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

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

Шта је Бацкенд?

Веб апликација је подељена на два дела – Фронтенд и Бацкенд.

  • Предња страна је на страни клијента, то је део са којим корисник комуницира. Обично је изграђен са ХТМЛ, ЦСС и Јавасцрипт.
  • Повратак је на страни сервера. У основи функционише апликација, примењује пословну логику, промене и ажурирања. Неки од популарних технолошких скупова на страни сервера укључују ПХП, НодеЈС, Јава, Руби, Ц, Питхон, базу података, безбедност (аутентификација, контрола приступа итд.), Структуру и управљање садржајем.

Мали подсетник пре него што почнемо – аутентификација, контрола приступа & управљање сесијом

Уобичајено је да збуњујемо изразе. Па разјаснимо брзо:

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

Истражимо следеће за бољу заштиту веб страница.

Недостаци убризгавања

Од 2010. године ОСВАП је ињекцију класификовао као најопаснији ризик веб апликације.

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

унаме = рекуест.ПОСТ [‘корисничко име’]
пассвд = рекуест.ПОСТ [‘лозинка’]
скл = "ОДАБИР ИД ОД корисника ГДЈЕ корисничко име = ‘" + унме + "’АНД пассворд =’" + пассвд + "’"
датабасе.екецуте (скл)

Нападач сада може манипулирати пољем лозинке користећи СКЛ ињекцију, на примјер уносом лозинке ‘ИЛИ 1 =’ 1, што доводи до сљедећег СКЛ упита:

скл = "ОДАБИР ИД ОД корисника ГДЈЕ корисничко име = ” И лозинка = ‘лозинка’ ИЛИ ​​1 = ‘1’

На тај начин нападач може приступити свим корисничким таблицама базе података, а лозинка је увек валидна (1 = ‘1’). Ако се пријаве као администратор, могу извршити било какве промене које он жели.

Како то спречити?

Врло је ЛАКО! како би се избегли недостаци убризгавања.

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

А требало би и следеће.

  • Користите ОРМ-ове (Обитељски алати за релацијско пресликавање).
  • Побегните од свих улаза. У пољу за датум никада не би требало бити похрањено у њима ништа друго осим датума.
  • Изолирајте своје податке тако да се на тој локацији држе само оне ствари којима треба приступити са одређене локације.
  • Напишите добре кодове грешака при руковању. Немојте да вашу базу података или позадину чине превише верболизмом.

Трои Хунт добио је сјајан курс за СКЛ ињекцију. Ако сте заинтересовани, можете то истражити.

Прекинута аутентификација

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

Сломљена аутентификација углавном се одвија по три обрасца:

  • Пуњење акредитација: где нападач има листу важећих корисничких имена и лозинки и може аутоматизовати напад да би утврдио да су вјеродајнице валидне.
  • Брутефорце напад: где апликација дозвољава слабе лозинке за кориснике или администраторе.
  • Отмица сесије: где апликација излаже ИД сесије, УРЛ или се не ротира након пријаве.

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

Како то спречити?

Пре примене система за аутентификацију запитајте се – шта би нападач могао постићи ако је систем аутентификације угрожен?

А према одговору, можете учинити следеће.

  • Имплементирајте мултифакторску провјеру аутентичности да бисте спречили аутоматске нападе.
  • Охрабрите (или приморајте) корисника да усвоји добру политику лозинке.
  • Ограничите неуспеле пријаве.
  • Користите ефикасан хасх алгоритма. Приликом одабира алгоритма узмите у обзир максималну дужину лозинке.
  • Тестирајте систем прекида сесије и провјерите да је токен сесије неважећи након одјаве.

Прекинута контрола приступа

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

Уобичајени недостаци у контроли приступа укључују:

  • Погрешна конфигурација ЦОРС-а која омогућава неовлашћени приступ АПИ-ју.
  • Манипулација метаподацима ради директног приступа методама.
  • Присилно прегледавање: Нападач ће покушати УРЛ, изменити путање (нпр., Хттп: //вебсите.домаин/усер/ до хттп: //вебсите.домаин/админ), и чак може открити важне датотеке.

Како то спречити?

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

  • Одбијте подразумевано, осим јавних ресурса.
  • Онемогућите попис директорија сервера и будите сигурни да датотеке сигурносних копија не постоје.
  • Ограничи ограничење приступа АПИ-ју да би се смањио утицај аутоматизованих напада.
  • Неважећи ЈВТ токене након одјаве на позицији за помоћ.

Излагање података

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

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

Утицај на пословање је велики са финансијске стране: Просечно кршење може коштати 3,92 милиона долара, према ИБМ.

Како то спречити?

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

А онда да спречите такве недостатке:

  • Шифрирајте осетљиве податке: За податке на РЕСТ-у све криптирајте. За податке у транзиту обавезно користите сигурне пролазе (ССЛ)
  • Идентификујте податке који захтевају додатну заштиту и ограничавају приступ само гомилу законитих корисника само наметањем шифрирања заснованог на кључевима.
  • Избегавајте слаб алгоритам шифровања: користите ажурне и јаки алгоритми.
  • Имајте сигуран сигурносни план.

Несигурна десеријализација

Серијализација и десериализација су појмови који се користе када се подаци претварају у објектни формат за похрањивање или слање у другу апликацију. Серијализација се састоји од претварања података у објектни формат попут КСМЛ или ЈСОН како би их учинили употребљивима. Десериализација је само обрнути процес.

Напади на десеријализаторе могу довести до одбијања услуге, контроле приступа и напада даљинског извршења кода (РЦЕ) ако постоје класе које се могу модификовати да промене понашање.

Други пример документа ОВАСП топ 10 пружа добру илустрацију ПХП сериализер објекта:

а: 4: {и: 0; и: 132; и: 1; с: 7:"Маллори"; и: 2; с: 4:"корисник";
и: 3; с: 32:"б6а8б3беа87фе0е05022ф8ф3ц88бц960";}

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

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

а: 4: {и: 0; и: 1; и: 1; с: 5:"Алице"; и: 2; с: 5:"админ";
и: 3; с: 32:"б6а8б3беа87фе0е05022ф8ф3ц88бц960";}

Како то спречити?

Кључно је не прихватати серијске предмете из непоузданих извора.

Такође би требало:

  • Никада не верујте корисничком уносу.
  • Провјера података: Ако је ваша апликација осим низа, провјерите је ли низ прије употребе
  • Користите чек да бисте били сигурни да подаци нису промењени. Корисно је да податке шаљете између два поуздана извора (нпр., Складиштење података на страни клијента).

Сервер КССС

Сервер КССС (Скрипта на више места) је врста убризгавања када нападач користи веб апликацију за слање злонамерног кода различитим корисницима. До тога долази када нападач објави неке израђене податке који садрже злонамерни код који апликација складишти. Ова рањивост је на страни сервера; прегледач једноставно даје одговор.

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

Како то спречити?

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

  • Потврдите унос: проверите дуљину уноса, користите подударање регуларних израза и допушта само одређени скуп знакова.
  • Потврдите излаз: Ако апликација копира у своје одговоре на било коју ставку података која је настала од неког корисника или треће стране, ови подаци требају бити кодирани ХТМЛ-ом како би се санирали потенцијално злонамерни знакови.
  • Дозволи ограничење ХТМЛ-а: на пример, ако имате систем блогова за коментаре, дозволите употребу само одређених ознака. Ако можете, користите одговарајући оквир за ХТМЛ марку коју сте добили од корисника да бисте били сигурни да не садржи никаква средства за извршавање ЈаваСцрипта.

Закључак

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

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map