security testing
Како тестирати безбедност апликација - технике тестирања безбедности веба и радне површине
Потреба за безбедносним тестирањем?
Софтверска индустрија постигла је солидно признање у ово доба. У последњој деценији, међутим, чини се да сајбер свет још више доминира и покреће снагу која обликује нове облике готово сваког пословања. Веб-базирани ЕРП системи који се данас користе најбољи су доказ да су ИТ револуционирали наше вољено глобално село.
Данас веб странице нису намењене само реклами или маркетингу, већ су оне развијене у снажније алате за задовољавање пословних потреба.
Системи обрачуна зарада засновани на Интернету, тржни центри, банкарство, апликација за трговину не користе само организације, већ се данас продају и као производи.
То значи да су мрежне апликације стекле поверење купаца и корисника у погледу њихове виталне функције назване БЕЗБЕДНОСТ.
Без сумње, фактор сигурности је од примарне вредности и за десктоп апликације.
Међутим, када говоримо о мрежи, важност сигурности експоненцијално расте. Ако мрежни систем не може да заштити податке о трансакцији, нико никада неће помислити да их користи. Безбедност још увек није реч у потрази за својом дефиницијом, нити је суптилан концепт. Међутим, желео бих да набројим неке комплименте о безбедности.
Примери сигурносних недостатака у апликацији
јава интервју питање и одговори за свеже
- Систем управљања студентима није сигуран ако огранак „Пријем“ може да уређује податке огранка „Испит“
- ЕРП систем није сигуран ако ДЕО (оператор уноса података) може да генерише „Извештаје“
- Тржни центар на мрежи нема сигурност ако подаци о кредитној картици купца нису шифровани
- Прилагођени софтвер поседује неадекватну сигурност ако СКЛ упит преузме стварне лозинке својих корисника
Сигурност
Сада вам представљам најједноставнију дефиницију безбедности својим речима.
„Сигурност значи да се заштићеним подацима даје одобрени приступ, а неовлашћени приступ ограничава“ .
Дакле, има два главна аспекта; прво је заштита података, а друго приступ тим подацима. Штавише, без обзира да ли је апликација радна површина или мрежа, сигурност се врти око два горе поменута аспекта.
Допустите нам преглед безбедносних аспеката софтверских апликација за рачунаре и за веб.
Шта ћете научити:
Тестирање радне површине и Веба
Апликација за радну површину треба да буде сигурна не само у погледу приступа, већ и у погледу организације и чувања података.
Слично томе, веб апликација захтева, чак и више, сигурност у погледу свог приступа, заједно са заштитом података. Веб програмер треба да учини апликацију имуном на СКЛ ињекције, Бруте Форце Аттацкс и КССС (скриптирање на више локација). Слично томе, ако веб апликација омогућава удаљене приступне тачке, и оне морају бити сигурне.
Штавише, имајте на уму да се Бруте Форце Аттацк не односи само на веб апликације, већ је и десктоп софтвер рањив на ово.
Надам се да је овај предговор довољан и сада ћу прећи на ствар. Молимо вас да прихватите моје извињење ако сте до сада мислили да читате о теми овог чланка. Иако сам укратко објаснио безбедност софтвера и његове главне проблеме, моја тема је „Испитивање безбедности“.
Препоручено читање => Тестирање сигурности веб апликација
Сада ћу објаснити како се функције безбедности примењују у софтверској апликацији и како их треба тестирати. Мој фокус ће бити на Вхатс анд Ховс сигурносног тестирања, а не сигурности.
Препоручени алати за испитивање безбедности
# 1) Мрежни паркер
Нетспаркер је решење за тестирање безбедности веб апликација са могућностима аутоматског пузања и скенирања за све врсте застарелих и модерних веб апликација као што су ХТМЛ5, Веб 2.0 и Сингле Паге Апплицатионс. Користи технологију скенирања засновану на доказима и скалабилне агенсе за скенирање.
Омогућава вам потпуну видљивост иако имате велики број средстава којима можете управљати. Има много више функционалности попут управљања тимом и управљања рањивостима. Може се интегрисати у ЦИ / ЦД платформе попут Јенкинс, ТеамЦити или Бамбоо.
=> Испробајте најбољи алат за тестирање безбедности Нетспаркер-а#два) Киуван
Пронађите и поправите рањивости у свом коду у свакој фази СДЛЦ-а.
Киуван је у складу са најстрожим безбедносним стандардима, укључујући ОВАСП, ЦВЕ, САНС 25, ХИППА и друге. Интегришите Киуван у свој ИДЕ за тренутне повратне информације током развоја. Киуван подржава све главне програмске језике и интегрише се са водећим ДевОпс алатима.
=> Скенирајте свој код бесплатно# 3) Индусфаце ЈЕ БЕСПЛАТНА провера малвера за веб странице
Индусфаце је био пружа ручно тестирање продирања у пакету са сопственим аутоматизованим скенером рањивости веб апликација који открива и пријављује рањивости на основу ОВАСП топ 10, а такође укључује проверу репутације веб локација, злонамерног софтвера и провере кварења веб локације у сваком скенирању
=> Покрените брзо скенирање веб страница бесплатно
=> Контактирајте нас да овде предложим списак.
Списак 8 најбољих техника испитивања безбедности
# 1) Приступ апликацији
Било да се ради о апликацији за рачунаре или веб локацији, сигурност приступа спроводи „Управљање улогама и правима“. То се често ради имплицитно док покрива функционалност,
На пример, у систему управљања болницом, рецепционера најмање брину лабораторијски тестови, јер је његов посао да само региструје пацијенте и закаже њихов састанак са лекарима.
Дакле, сви менији, обрасци и екрани који се односе на лабораторијске тестове неће бити доступни улози „рецепционара“. Дакле, правилно спровођење улога и права гарантоваће сигурност приступа.
Како тестирати: Да би се ово тестирало, требало би извршити темељно тестирање свих улога и права.
Тестер треба да креира неколико корисничких налога са различитим, као и са више улога. Тада би требало да користи апликацију уз помоћ ових налога и да провери да ли свака улога има приступ само својим модулима, екранима, обрасцима и менијима. Ако тестер пронађе било какав сукоб, требало би да са потпуним поверењем пријави безбедносни проблем.
Ово се такође може разумети као тестирање аутентичности и ауторизације, што је врло лепо приказано на доњој слици:
Дакле, у основи треба да тестирате „ко сте ви“ и „шта можете учинити“ за различите кориснике.
мирна веб сервиса јава интервју питања
Неки од тестова за потврду идентитета укључују тест за правила квалитета лозинке, тест за подразумеване пријаве, тест за опоравак лозинке, тест цаптцха, тест за функцију одјаве, тест за промену лозинке, тест за безбедносно питање / одговор итд.
Слично томе, неки од тестова ауторизације укључују тест за обилажење путање, тест за недостајућу ауторизацију, тест за проблеме са хоризонталном контролом приступа итд.
# 2) Заштита података
Постоје три аспекта сигурности података. Прво је то корисник може да прегледа или користи само податке које би требало да користи . То се такође осигурава улогама и правима
На пример, ТСР (представник телепродаје) компаније може да види податке о расположивим залихама, али не може да види колико је сировина купљено за производњу.
Дакле, овај аспект безбедносног тестирања је већ горе објашњен. Други аспект заштите података повезан је са како се ти подаци чувају у ДБ .
Даље читање = >> Шта је тестирање сигурности базе података
Сви осетљиви подаци морају бити шифровани да би били сигурни. Шифровање би требало да буде јако, посебно за осетљиве податке попут лозинки корисничких рачуна, бројева кредитних картица или других пословних информација важних.
Трећи и последњи аспект је продужење овог другог аспекта. Морају се усвојити одговарајуће мере безбедности када се догоди проток осетљивих или пословних критичних података. Без обзира да ли ови подаци лебде између различитих модула исте апликације или се преносе различитим апликацијама, они морају бити шифровани да би били безбедни.
Како тестирати заштиту података: Тестер треба да испита базу података у вези са „лозинкама“ корисничког рачуна, информацијама о рачунима клијената, осталим пословно критичним и осетљивим подацима и треба да верификује да ли су сви такви подаци у ДБ2 сачувани у шифрованом облику.
Слично томе, он мора да верификује да се подаци преносе између различитих образаца или екрана само након одговарајућег шифровања. Штавише, испитивач треба да осигура да се шифровани подаци правилно дешифрују на одредишту. Посебну пажњу треба обратити на различите акције „подношења“.
Тестер мора да верификује да се приликом преноса информација између клијента и сервера не приказују у адресној траци веб прегледача у разумљивом формату. Ако било која од ових верификација не успе, онда апликација дефинитивно има сигурносну грешку.
Тестер би такође требало да провери да ли правилно користи сољење (додавање додатне тајне вредности крајњем уносу попут лозинке и на тај начин чинећи га јачим и тежим за пуцање).
Такође би требало тестирати и несигурну случајност, јер је то врста рањивости. Други начин тестирања заштите података је провера слабе употребе алгоритма.
На пример, пошто је ХТТП протокол са јасним текстом, ако се осетљиви подаци попут корисничких података преносе путем ХТТП-а, онда то представља претњу за безбедност апликације. Уместо ХТТП-а, осетљиви подаци треба да се преносе путем ХТТПС-а (заштићени ССЛ-ом, ТЛС-тунелом).
Међутим, ХТТПС повећава површину напада и стога треба тестирати да ли су конфигурације сервера исправне и да ли је ваљаност сертификата осигурана.
# 3) Бруте-Форце Аттацк
Бруте Форце Аттацк углавном раде неки софтверски алати. Концепт је да се помоћу важећег корисничког ИД-а с офтваре покушава да погоди повезану лозинку покушавајући да се поново и поново пријави.
Једноставан пример заштите од таквог напада је суспендовање налога на кратак временски период као што то раде све апликације за слање поште попут „Иахоо“, „Гмаил“ и „Хотмаил“. Ако одређени број узастопних покушаја (углавном 3) не успе да се успешно пријави, тада је тај рачун блокиран на неко време (30 минута до 24 сата).
Како тестирати Бруте-Форце Аттацк: Тестер мора да верификује да ли је доступан неки механизам за обуставу рачуна и да ли он ради тачно. (С) Он мора покушати да се пријави са неважећим корисничким ИД-овима и лозинкама, како би био сигуран да софтверска апликација блокира рачуне ако се непрекидно покушавају пријавити са неважећим подацима.
Ако апликација то чини, сигурна је од напада грубом силом. У супротном, испитивач мора пријавити ову сигурносну рањивост.
Испитивање грубе силе такође се може поделити на два дела - испитивање црне кутије и испитивање сиве кутије.
У тестирању црне кутије открива се и тестира метода аутентификације коју користи апликација. Штавише, тестирање сиве кутије заснива се на делимичном знању детаља о лозинци и налогу и нападима на компромис меморије.
Кликните овде да истражите грубу силу црне кутије и сиве кутије заједно са примерима.
Горе наведена три сигурносна аспекта треба узети у обзир и за веб и за десктоп апликације, док су следеће тачке повезане само са веб апликацијама.
# 4) СКЛ Ињецтион И КССС (Цросс-Сите Сцриптинг)
Концептуално гледано, тема оба покушаја хаковања је слична, па се о њима разговара заједно. У овом приступу, злонамерну скрипту користе хакери да би манипулисали веб страницом .
Постоји неколико начина да се имуни против таквих покушаја. За сва поља за унос веб странице, дужине поља треба да буду дефинисане довољно мале да ограниче унос било које скрипте
На пример, Презиме би требало да има дужину поља уместо 255. Можда постоје нека поља за унос где је неопходан велик унос података, за таква поља треба извршити одговарајућу проверу уноса пре него што те податке сачувате у апликацији.
најбољи софтвер за праћење температуре процесора
Штавише, у таквим пољима мора бити забрањено уношење било каквих ХТМЛ тагова или скрипти. Да би изазвала КССС нападе, апликација би требала одбацити преусмјеравања скрипти из непознатих или непоузданих апликација.
Како да тест СКЛ Ињецтион и КССС: Тестер мора осигурати да се дефинишу и примењују максималне дужине свих поља за унос. (С) Такође би требало да осигура да дефинисана дужина поља за унос не садржи било који унос скрипте, као ни унос ознаке. Обоје се могу лако тестирати
На пример, Ако је 20 максимална дужина наведена за поље „Име“, а улазни низ „
тхекуицкбровнфокјумпсовертхелазидог “може да верификује оба ова ограничења.
Тестер такође треба да верификује да апликација не подржава анонимне методе приступа. У случају да постоји било која од ових рањивости, апликација је у опасности.
У основи, тестирање убризгавања СКЛ може се обавити на следећих пет начина:
- Технике откривања
- Стандардне технике убризгавања СКЛ-а
- Отисак базе података
- Техничка експлоатација
- Технике инвазије потписа СКЛ убризгавања
Кликните овде да детаљно прочитате горе наведене начине за тестирање СКЛ убризгавања.
КССС је такође врста убризгавања која убацује злонамерне скрипте у веб локацију. Кликните овде да истражите детаљно о тестирању за КССС.
# 5) Приступне тачке за услуге (запечаћене и безбедно отворене)
Данас предузећа зависе и међусобно сарађују, исто важи и за апликације, посебно за веб локације. У том случају, оба сарадника треба да дефинишу и објаве неке приступне тачке једни за друге.
Засад се чини да је сценарио једноставан и јасан, али за неке производе засноване на Интернету, попут трговине акцијама, ствари нису тако једноставне и лагане.
Када постоји велики број циљне публике, приступне тачке би требале бити довољно отворене да олакшају све кориснике, довољно смештене да испуне све захтеве корисника и довољно сигурне да се носе са било којим безбедносним испитивањем.
Како тестирати приступне тачке за услуге: Да објасним са пример веб апликације за трговање акцијама; инвеститор (који жели да купи акције) треба да има приступ тренутним и историјским подацима о ценама акција. Кориснику треба дати могућност да преузме ове историјске податке. То захтева да апликација буде довољно отворена.
Прилагођавањем и сигурношћу мислим да би апликација требало да олакша инвеститорима да слободно тргују (у складу са законским прописима). Они могу куповати или продавати 24/7, а подаци о трансакцијама морају бити имуни на било који напад хаковања.
Штавише, велики број корисника истовремено ће комуницирати са апликацијом, тако да апликација треба да обезбеди довољно приступних тачака за забаву свих корисника.
У неким случајевима, ови приступне тачке могу бити запечаћене за нежељене апликације или људе . Ово зависи од пословног домена апликације и њених корисника,
На пример, Прилагођени систем управљања системом заснован на Интернету може да препозна своје кориснике на основу ИП адреса и одбија да успостави везу са свим осталим системима (апликацијама) који не спадају у опсег важећих ИП адреса за ту апликацију.
Тестер мора да обезбеди да сви приступ између мрежа и унутар мреже апликацији пружају поуздане апликације, машине (ИП-ови) и корисници.
Да би потврдио да је отворена приступна тачка довољно сигурна, тестер мора да покуша да јој приступи са различитих машина које имају и поуздане и непоуздане ИП адресе. Да би се имало добро поверење у перформансе апликације, требало би масовно испробати различите врсте трансакција у реалном времену. Чинећи то, капацитет приступних тачака апликације такође ће се јасно посматрати.
Тестер мора осигурати да апликација обрађује све захтеве за комуникацију са поузданих ИП-ова и апликација само док су сви остали захтеви одбијени.
Слично томе, ако апликација има неку отворену приступну тачку, тестер треба да осигура да дозвољава (ако је потребно) слање података од стране корисника на безбедан начин. На овај сигуран начин мислим на ограничење величине датотеке, ограничење типа датотеке и скенирање учитане датотеке на вирусе или друге безбедносне претње.
Ово је све како тестер може да провери сигурност апликације у односу на њене приступне тачке.
# 6) Управљање сесијама
Веб сесија је секвенца ХТТП захтева и трансакција одговора повезаних са истим корисником. Тестови за управљање сесијама проверавају како се управља сесијама у веб апликацији.
Можете тестирати истек сесије након одређеног времена неактивности, прекид сесије након максималног животног века, прекид сесије након одјаве, проверити обим и трајање колачића сесије, тестирање да ли један корисник може имати више истовремених сесија итд.
# 7) Руковање грешкама
Тестирање руковања грешкама укључује:
Проверите кодове грешака : На пример, тестирајте време чекања 408 захтева, 400 лоших захтева, 404 није пронађено итд. Да бисте их тестирали, потребно је да упутите одређене захтеве на страницу тако да се ти кодови грешака врате.
Кодови грешака се враћају са детаљном поруком. Ове поруке не би смеле да садрже критичне информације које се могу користити за хаковање
Проверите трагове стека : У основи укључује давање неких изузетних података апликацији, тако да враћена порука о грешци садржи трагове стека који имају занимљиве информације за хакере.
# 8) Специфичне ризичне функције
Углавном су две ризичне функционалности Плаћања и отпремање датотека . Ове функционалности треба врло добро тестирати. За отпремање датотека, првенствено морате да тестирате да ли је ограничено свако нежељено или злонамерно отпремање датотека.
За плаћања морате првенствено тестирати рањивости убризгавања, несигурно криптографско складиште, преливање бафера, погађање лозинке итд.
=> Контактирајте нас да овде предложим списак.Додатна литература:
- Тестирање безбедности веб апликација
- 30 главних питања о испитивању безбедности
- Разлика између САСТ / ДАСТ / ИАСТ / РАСП
- САНС Топ 20 безбедносних пропуста
Препоручено читање
- Водич за тестирање безбедности веб апликација
- Алфа тестирање и бета тестирање (потпун водич)
- Водич за тестирање складишта података ЕТЛ (комплетан водич)
- Тестирање мрежне сигурности и најбољи алати за мрежну сигурност
- Водич за почетнике за тестирање продора веб апликација
- Комплетни водич за тестирање верификације израде (БВТ тестирање)
- Функционално тестирање вс нефункционално тестирање
- Комплетан водич за испитивање пенетрације са узорцима тест примера