Када је у питању безбедност стека предузећа, софтверске апликације су најслабија карика. Ин Стање безбедности апликација, 2020, Форрестер каже да се већина спољних напада дешава или коришћењем софтверске рањивости (42%) или путем веб апликације (35%).
Програмери су под притиском да објаве функције што је пре могуће како апликације постану сложеније, а рокови развоја се смањују. Да би постигли различиту и убедљиву функционалност апликације, програмери се све више ослањају на библиотеке независних произвођача.
Овај помак ка компонентама отвореног кода чини безбедност праксе сложеније за компаније. Нови оквири као што су контејнери и АПИ-ји додатно компликују безбедност апликација.
Пошто су програмери под притиском да стално објављују нове функције, организације се суочавају са веома реалним ризиком да безбедност не успе да одржи корак. Безбедност се може постићи уграђивањем најбољих пракси за безбедност апликација у животни циклус развоја софтвера и њиховом применом.
Зашто је тестирање веб безбедности важно?
Тестирање веб апликација и њихових конфигурација на безбедносне пропусте је циљ тестирања безбедности на вебу. Напади на слоју апликације (тј. циљање апликација заснованих на ХТТП-у) су примарни циљеви.
Уобичајено је слати различите типове уноса у веб апликацију како би се изазвале грешке и изазвало њено неочекивано понашање. У овим такозваним „негативним тестовима“, систем се проверава због понашања које није предвиђено.
Такође је важно напоменути то Тестирање безбедности на вебу не ради се само о тестирању безбедносних функција које су имплементиране у апликацији (нпр. аутентификација и ауторизација).
Такође је неопходно тестирати да ли су друге карактеристике (нпр. пословна логика и валидација улаза и излаза) имплементиране на безбедан начин. Безбедан приступ функцијама веб апликације је циљ.
Које су различите врсте безбедносних тестова?
- Динамички тест безбедности апликација (ДАСТ). За усклађеност са регулаторним безбедносним проценама, овај аутоматизовани тест безбедности апликација је идеалан за интерно суочене, нискоризичне апликације. Комбинација ручног тестирања безбедности на вебу и ДАСТ-а је најбољи приступ за апликације средњег ризика и критичне апликације које пролазе кроз мање промене.
- Статички тест безбедности апликације (САСТ). Овај приступ безбедносним тестовима апликација и ручно и аутоматски. Апликација се може тестирати на овај начин без потребе да се покреће у производном окружењу. Штавише, омогућава програмерима да систематски откривају и елиминишу безбедносне пропусте софтвера скенирањем изворног кода.
- Тест пенетрације. Посебно за апликације које пролазе кроз велике промене, овај ручни безбедносни тест апликације је идеалан. Процене укључују пословну логику и тестирање засновано на противнику да би се идентификовали напредни сценарији напада.
- Самозаштита апликације током извршавања (РАСП). Бројне технолошке технике се користе у овом развијајућем приступу безбедности апликација за инструментирање апликације на такав начин да се напади могу надгледати док се извршавају и, идеално, блокирати у реалном времену.
Како тестирање безбедности апликација смањује ризик ваше организације?
Већина напада на веб апликације
- Техника СКЛ ињекције
- Цросс-Сите Сцриптинг (КССС)
- Извршавање команди на даљину
- Патх Траверсал
Резултати напада
- Садржај који је ограничен
- Рачуни који су компромитовани
- Инсталација злонамерног софтвера
- Изгубљени приходи
- Купци губе поверење
- Репутацијска штета
- Као и много више
Данашње Веб окружење је склоно широком спектру проблема. Поред знања о томе како се апликација може искористити, познавање потенцијалних исхода напада ће помоћи вашој компанији да превентивно реши рањивости и да их прецизно тестира.
Контроле за ублажавање могу се применити током раних фаза СДЛЦ-а након идентификовања основног узрока рањивости. Поред тога, тест безбедности веб апликације може искористити знање о томе како ови напади функционишу за циљање познатих тачака интересовања.
Да бисте управљали ризиком ваше фирме, морате разумети утицај напада, пошто се он може користити за процену укупне озбиљности рањивости.
Као резултат безбедносног теста, одређивање озбиљности откривених проблема може вам помоћи да ефикасно и ефективно одредите приоритете напоре за санацију. Минимизирајте ризик своје фирме тако што ћете почети са питањима критичне озбиљности и прећи на питања мањег утицаја.
Процена потенцијалног утицаја сваке апликације у библиотеци апликација ваше фирме пре идентификовања проблема може помоћи у одређивању приоритета у тестирању безбедности апликације.
Када тестирање безбедности на вебу има утврђену листу апликација високог профила, можемо заказати тестирање тако да прво циља на критичне апликације ваше фирме како би се смањио ризик по ваше пословање.
Које карактеристике треба прегледати током теста безбедности веб апликације?
Неколико карактеристика би требало да се испита током безбедносног тестирања веб апликација, али листа није коначна. Ваша организација би могла бити изложена озбиљном ризику неприкладном имплементацијом сваког од њих.
- Конфигурација апликације и сервера- Дефекти могу бити повезани са конфигурацијом шифровања, конфигурацијом веб сервера итд.
- Валидација уноса и руковање грешкама- Најчешће рањивости убризгавања, укључујући СКЛ ињекцију и скриптовање на више локација (КССС), резултат су лошег руковања уносом и излазом.
- Аутентификација и управљање сесијом- Рањивости могу довести до лажног представљања корисника. Снажна политика акредитива је такође неопходна.
- Овлашћење- Провера способности апликације да спречи вертикалну и хоризонталну ескалацију привилегија.
- Пословна логика- Ова врста логике је неопходна за већину пословних апликација.
- Логика на страни клијента- Ова врста функција постаје све чешћа на модерним веб-сајтовима који користе ЈаваСцрипт, као и на веб-сајтовима који користе друге технологије на страни клијента (нпр. Силверлигхт, Фласх, Јава аплети).
10 најбољих пракси за безбедност веб апликација
Следи десет најбољих безбедносних пракси које ваша организација већ треба да примењује.
#1 Пратите своју имовину
Ако не знате шта имате, не можете то заштитити.
За које функције или апликације користите одређене сервере? У којим веб апликацијама користите компоненте отвореног кода?
Мислите ли да није важно пратити своју имовину? Веома је важно запамтити који софтвер ради у оквиру сваке апликације – само питајте Екуифак, који је кажњен са 700 милиона долара јер није заштитио податке преко 145 милиона корисника.
Један од корисничких веб портала агенције за кредитни рејтинг је компромитован након што компонента отвореног кода, Апацхе Струтс, није закрпљена. Компанија каже да није била свесна да је кориснички портал користио рањиву компоненту отвореног кода.
Што пре почнете да пратите своју имовину, касније ћете имати мање главобоља и катастрофа. Како организације повећавају свој развој, овај процес може изгледати као Сизифов задатак.
Такође би требало да класификујете своју имовину, наводећи она која су критична за функције вашег пословања и она која су од мањег значаја. Затим можете проценити претње и касније их отклонити.
#2 Извршите процену претње
Ако направите листу онога што треба да заштитите, тада можете идентификовати претње са којима се суочавате и како их можете ублажити.
Како би хакери могли да провале у вашу апликацију? Које постојеће мере безбедности имате? Који додатни алати су потребни?
Морате одговорити на ова и друга питања као део ваше процене претње.
Ипак, морате бити реални у погледу нивоа сигурности у којем можете уживати. Без обзира на то колико сигурним учините свој систем, и даље га можете хаковати. Штавише, морате бити искрени у погледу мера које ваш тим може да одржава током времена.
Можете ризиковати да се ваши безбедносни стандарди и праксе игноришу ако превише инсистирате. Схватите сигурност озбиљно и не журите.
Користите следећу формулу да процените свој ризик:
Ризик = вероватноћа напада к утицај напада.
Ризик се такође може посматрати као вероватноћа да се нешто деси у односу на тежину последица.
Иако би било катастрофално да је кит пао са неба и здробио вас, мало је вероватно да ће се то догодити.
С друге стране, ујед комарца на пешачењу је прилично вероватан, али није вероватно да ће изазвати значајну штету осим неколико избочина које сврбе.
#3 Останите на врху свог закрпања
Инсталирате најновије закрпе на вашим оперативним системима? Да ли користите софтвер треће стране? Шансе су да заостајете, што значи да сте изложени.
Један од најважнијих корака које треба да предузмете да бисте осигурали безбедност свог софтвера је ажурирање софтвера, било од комерцијалног добављача или из заједнице отвореног кода.
Када се рањивост открије и одговорно пријави власницима производа или пројекта, она се објављује на саветодавним сајтовима и базама података као што је ВхитеСоурце база података о рањивости.
Ако је могуће, исправку треба направити и објавити пре објављивања, пружајући корисницима прилику да обезбеде свој софтвер.
Међутим, ако не примените закрпу када она постане доступна, нећете имати користи од побољшане безбедности.
Ако сте забринути да ажурирање на најновију верзију може покварити ваш производ, аутоматизовани алати може много помоћи. Било који дан у недељи, требало би да дате приоритет ажурирању и закрпању као делу најбоље праксе за безбедност апликација.
#4 Управљајте својим контејнерима
Последњих година, контејнери су постали популарнији јер све више организација усваја технологију због њене флексибилности, која поједностављује процес развоја, тестирања и примене компоненти у различитим окружењима током животног циклуса развоја софтвера (СДЛЦ).
Опште је прихваћено да контејнери нуде безбедносне предности које им дају предност. Поред тога, због свог самосталног ОС окружења, они су сегментирани по дизајну, чиме се смањује ниво ризика.
Ипак, контејнери су и даље рањиви на експлоатације као што је пробојни напад, у којем је изолација прекинута. Контејнери такође могу садржати рањивост у коду ускладиштеном у њима.
За безбедност ЦИ/ЦД цевовода, требало би да скенирате рањивости од почетка до краја, укључујући и ваше регистре.
Поред ових скенирања, најбоље праксе за безбедност апликација у раду са контејнерима такође укључују важне задатке као што је потписивање сопствених слика помоћу алатки као што су Доцкер Цонтент Труст ако користите Доцкер Хуб или Схаред Аццесс Сигнатуре ако ваш тим користи Мицрософт Азуре.
#5 Дајте приоритет својим операцијама санације
Последњих година је све већи број рањивости, а овај тренд не показује знаке успоравања у скорије време.
Сходно томе, програмери су заузети санацијом. За тимове који се надају да ће њихове апликације бити безбедне, а да притом остану здраве, приоритет је од суштинског значаја.
Процене претњи се врше на основу озбиљности рањивости (ЦВСС оцена), критичности погођене апликације и низа других фактора.
Морате знати да ли рањивост отвореног кода заиста утиче на ваш власнички код када су у питању рањивости отвореног кода.
Неефикасан и није висок ризик чак и ако је ЦВСС оцена рањиве компоненте критична ако не прима позиве са вашег производа.
Паметне стратегије су оне које прво дају приоритет најхитнијим претњама, на основу присутних фактора, а оне са ниским ризиком остављају за касније.
#6 Шифровање, шифровање, шифровање
ОВАСП Топ 10 укључује шифровање података у мировању и у транзиту годинама, што га чини условом за било коју листу најбољих пракси у области безбедности апликација.
Напади човека у средини и други облици упада могу открити осетљиве податке када не успете да правилно закључате свој саобраћај.
Када чувајте лозинке и корисничке ИД-ове у обичном тексту, на пример, излажете своје клијенте ризику.
Уверите се да користите ССЛ са ажурираним сертификатом као део ваше основне контролне листе за шифровање. Не дозволите да будете остављени сада када је ХТТПС стандард. Такође се препоручује хеширање.
Поред тога, никада не би требало да „убаците сопствену криптовалуту“ како кажу. Размислите о безбедносним производима које подржава наменски тим са искуством да исправно обави посао.
#7 Управљајте привилегијама
Не морате да дате приступ свему свима у вашој организацији. Апликацијама и подацима могу приступити само они којима су потребни пратећи најбоље праксе за безбедност мреже и најбоље праксе за безбедност апликација.
Два су разлога за ово. Прва ствар коју треба да урадите је да спречите хакера да користи маркетиншке акредитиве за приступ систему који садржи друге осетљивије податке, као што су финансије или правни подаци.
Инсајдерске претње такође изазивају забринутост, било да су ненамерне – као што је губитак лаптопа или слање погрешног прилога е-поруци – или злонамерне.
Принцип најмање привилегије да се запосленима дају само подаци који су им потребни када је у питању приступ подацима могао би смањити вашу изложеност у поређењу са недостатком контроле.
#8 Пригрлите аутоматизацију за управљање рањивостима
Безбедност њихових апликација је постала све важнија за програмере у последњих неколико година, посебно када су у питању задаци попут управљања рањивостима.
Да би се позабавили померањем безбедности улево, тимови програмера рано и често тестирају, гурајући што више својих безбедносних провера у раном процесу развоја када је лакше и јефтиније поправити рањивости.
Да би управљали гломазним процесом тестирања због огромне количине рањивости, програмери захтевају аутоматизоване алате.
Да бисте пронашли потенцијалне безбедносне пропусте у вашем власничком коду, током развоја се могу користити статичко тестирање безбедности апликације (САСТ) и динамичко тестирање безбедности апликације (ДАСТ).
Сигурносне рупе су затворене са САСТ-овима и ДАСТ-овима, међутим власнички код чини релативно мали део вашег укупног кода.
У више од 92% свих модерних апликација, компоненте отвореног кода чине 60-80% ваше кодне базе. Ваша безбедносна листа за проверу апликације треба да даје приоритет обезбеђивању компоненти отвореног кода.
Користећи алате за анализу састава софтвера, тимови могу да покрену аутоматизоване безбедносне провере и извештаје у целом СДЛЦ-у, идентификујући сваку компоненту отвореног кода у свом окружењу и указујући која од њих има познату рањивост која представља безбедносни ризик за ваше апликације.
Можете боље да управљате својим рањивостима померањем аутоматског тестирања за безбедносне проблеме отвореног кода улево.
#9 Тестирање пенетрације
Листа најбољих пракси у области безбедности апликација не би била потпуна без помињања тестирања оловком, иако аутоматизовани алати помажу у откривању велике већине безбедносних проблема.
Тестирање оловком и папиром вам омогућава да гурате и гурате своју апликацију да бисте пронашли слабости. Ако одлучан хакер покуша да провали у вашу апликацију, добри тестери оловака знају тачно које кораке треба да предузму.
Хакерске фирме се могу ангажовати или слободњаци могу да учествују у програмима за награђивање грешака као што су БугЦровд и ХацкерОне. Ваша компанија би требало да спонзорише награду за грешке ако то већ нисте учинили.
Ако ангажујете тестере за оловке, далеко је боље да их платите него да се носите са последицама стварног кршења.
#10 Будите опрезни са токенима
Упркос чињеници да је ово лако обезбедити, многи програмери не обезбеђују правилно своје токене за трећа лица.
Претражујући популарне веб локације за програмере, лако можете пронаћи необезбеђене токене на мрежи. Уместо да чувају детаље токена негде другде, програмери их једноставно укључују у своја спремишта отвореног кода.
Основна најбоља пракса за безбедност апликација је да правилно обезбедите своје токене треће стране. Не би требало да остављате токене које сте купили да леже у вашем коду да их било ко узме.
Најбоље праксе за безбедност апликација као основне праксе
Свака од најбољих пракси која је овде наведена треба да буде интегрисана у процес континуираног развоја ваше организације. Апликације и подаци ваше компаније су у опасности ако не минимизирате ризик. Пратите ове кораке да бисте смањили ризик.
Избегавање грешака које ће други вероватно направити је један од начина да останете испред хакера, па вас је теже погодити за нападе. Никада неће постојати безбедносна мера периметра или апликације која је потпуно заштићена од хаковања.
Међутим, праћење ових основних најбољих пракси може увелико допринети томе да ваша апликација не вреди труда хакера.
