У већини случајева, сервери веб апликација морају бити јавно доступни, што значи да су изложени свим врстама претњи.
Многе од ових претњи су предвидиве и лако се могу избећи, док су друге непознате и могу вас затећи неспремне. Да бисмо минимизирали могућност овог последњег случаја, нудимо листу основних савета како би сервери веб апликација били што безбеднији.
Пре него што почнете са листом савета, морате схватити да сервер веб апликација није острво. Сервер је централна компонента фарме веб апликација која омогућава хостовање и рад веб апликације. Стога, да бисте обезбедили, морате узети у обзир све компоненте које га окружују и обезбедити цело окружење веб апликације.
Основно окружење за хостовање и покретање веб апликација укључује оперативни систем (Линук, Виндовс), софтвер веб сервера (Апацхе, Нгинк), сервер базе података. Ако се било која од ових компоненти провали, нападачи би могли да добију приступ и изврше све злонамерне радње које желе.
Први и основни савет за обезбеђење окружења као што је горе описано је да прочитате безбедносне смернице и листу најбољих пракси за сваку од компоненти. Узимајући то у обзир, хајде да прегледамо низ здраворазумских безбедносних смерница које се примењују на скоро свако окружење веб апликација.
Преглед садржаја
Заштитни зид је демистификовао
Можда ћете бити у искушењу да брзо проверите ову ставку, мислећи: „Срећом, већ имам заштитни зид који штити моју мрежу.“ Али боље је задржати своје коње.
Ваш заштитни зид се можда брине о границама ваше мреже, држећи лоше момке напољу и добре момке унутра, али сигурно оставља широм отворена врата нападачима да провале у ваш сервер веб апликација.
Како?
Једноставно: ваш мрежни заштитни зид мора барем да дозволи долазни саобраћај на портовима 80 и 443 (то су ХТТП и ХТТПС) и не зна ко или шта пролази кроз те портове.
Оно што вам је потребно да заштитите своју апликацију је заштитни зид веб апликације (ВАФ) који посебно анализира веб саобраћај и блокира сваки покушај искоришћавања рањивости као што су скриптовање на више локација или убризгавање кода. ВАФ функционише као типичан антивирус и антималвер: тражи познате обрасце у току података и блокира га када открије злонамерни захтев.
Да би био ефикасан, ВАФ треба да своју базу података стално ажурира новим обрасцима претњи, како би могао да их блокира. Проблем са превенцијом напада на основу шаблона је у томе што ваша веб апликација може бити једна од првих мета нове претње које ваш ВАФ још увек није свестан.
Из ових разлога, вашој веб апликацији су потребни додатни заштитни слојеви поред мрежног заштитног зида.
Скенирајте рањивости специфичне за веб
Опет, немојте мислити да је ваш сервер веб апликација без рањивости само зато што ваш мрежни безбедносни скенер тако каже.
Мрежни скенери не могу да открију рањивости специфичне за апликацију. Да бисте открили и елиминисали ове рањивости, морате да ставите апликације под серију тестова и ревизија, као што су тестови пенетрације, скенирање црне кутије и ревизија изворног кода. Међутим, ниједна од ових метода није отпорна на метке. У идеалном случају, требало би да их извршите што је више могуће да бисте елиминисали све рањивости.
На пример, безбедносни скенери, као Инвицти, обезбедите да ниједан експлоатативни код не дође у производно окружење. Али могу постојати логичке рањивости које се могу открити само ручном ревизијом кода. Ручна ревизија, осим што кошта много, је људска метода и стога је склона грешкама. Добра идеја да урадите ову врсту ревизије без трошења много новца јесте да је уградите у процес развоја, углавном едукацијом ваших програмера.
Образујте своје програмере
Програмери имају тенденцију да мисле да њихове апликације раде у идеалним световима, где су ресурси неограничени, корисници не праве грешке и не постоје људи са немилосрдним намерама. Нажалост, у неком тренутку морају да се суоче са проблемима из стварног света, посебно онима који се тичу безбедности информација.
Када развијају веб апликације, кодери морају знати и имплементирати сигурносне механизме како би осигурали да нема рањивости. Ти безбедносни механизми треба да буду део водича за најбоље праксе које развојни тим мора да поштује.
Ревизија квалитета софтвера се користи да би се осигурала усклађеност са најбољим праксама. Најбоља пракса и ревизија су једини начини да се открију логичке рањивости, као што је (на пример) прослеђивање нешифрованих и видљивих параметара унутар УРЛ-а, које нападач може лако да промени да би урадио оно што жели.
Искључите непотребне функције
Под претпоставком да су веб апликације без грешака што је више могуће и да је веб фарма обезбеђена, хајде да видимо шта се може учинити на самом серверу да би се заштитио од напада.
Основни, здраворазумски савет је да се смањи број потенцијално рањивих улазних тачака. Ако нападачи могу да искористе било коју компоненту веб сервера, цео веб сервер би могао бити у опасности.
Направите листу свих отворених портова и покренутих сервиса или демона на вашем серверу и затворите, онемогућите или искључите непотребне. Сервер не би требало да се користи у било коју другу сврху осим за покретање ваших веб апликација, па размислите о премештању свих додатних функција на друге сервере у вашој мрежи.
Користите одвојена окружења за развој, тестирање и производњу
Програмерима и тестерима су потребне привилегије у окружењима у којима раде, а које не би требало да имају на серверу апликација уживо. Чак и ако им слепо верујете, њихове лозинке би лако могле да процуре и падну у нежељене руке.
Поред лозинки и привилегија, у окружењима за развој и тестирање обично постоје бацкдоорс, датотеке евиденције, изворни код или друге информације за отклањање грешака које би могле да открију осетљиве податке, као што су корисничка имена базе података и лозинке. Процес постављања веб апликације треба да обави администратор, који мора да се увери да ниједна осетљива информација није изложена након инсталирања апликације на сервер уживо.
Исти концепт сегрегације треба применити на податке апликације. Тестери и програмери увек више воле стварне податке за рад, али није добра идеја да им се одобри приступ производној бази података, па чак ни њеној копији. Поред очигледних забринутости за приватност, база података може да садржи конфигурационе параметре који откривају интерна подешавања сервера — као што су адресе крајњих тачака или имена путања, да наведемо пар.
Ажурирајте софтвер вашег сервера
Колико год очигледно изгледало, ово је један од задатака који се највише занемарује. СУЦУРИ је открио да је 59% ЦМС апликација застарело, што је подложно ризику.
Нове претње се појављују сваког дана, а једини начин да их спречите да угрозе ваш сервер је да увек инсталирате најновије безбедносне закрпе.
Раније смо споменули да мрежни заштитни зидови и мрежни безбедносни скенери нису довољни да спрече нападе на веб апликације. Али они су неопходни за заштиту вашег сервера од уобичајених претњи по сајбер безбедности, као што су ДДоС напади. Зато се побрините да такве апликације увек буду ажуриране и да ефикасно штите вашу пословну апликацију.
Ограничите приступ и привилегије
Основна безбедносна мера је да се саобраћај са удаљеног приступа — као што су РДП и ССХ — задржи шифрованим и тунелираним. Такође је добра идеја да задржите смањену листу ИП адреса са којих је дозвољен даљински приступ, водећи рачуна да сваки покушај даљинског пријављивања са било које друге ИП адресе буде блокиран.
Администратори повремено дају сервисним налозима све могуће привилегије јер знају да ће на тај начин „све функционисати“. Али ово није добра пракса јер нападачи могу користити рањивости у услугама да би продрли на сервер. Ако те услуге раде са администраторским привилегијама, могу да заузму цео сервер.
Добар баланс између сигурности и практичности захтева да сваки налог – и налози за пријаву и налози за услуге – има привилегије које су му потребне за обављање свог посла, и ништа друго.
На пример, можете да дефинишете различите налоге за администратора да обавља различите задатке: један да прави резервне копије, други да чисти датотеке евиденције, други да мења конфигурацију услуга итд. Исто важи и за налоге базе података: апликацији су обично потребне само дозволе за читање и писање података, а не за креирање или испуштање табела. Стога би требало да ради са налогом са ограниченим привилегијама за обављање задатака које треба да изврши.
Пазите на записнике сервера
Датотеке евиденције су ту са разлогом.
Администратори би требало да их редовно надгледају како би открили било какво сумњиво понашање пре него што нанесе штету. Анализом датотека евиденције можете открити много информација које ће вам помоћи да боље заштитите апликацију. Ако дође до напада, фајлови евиденције могу да вам покажу када и како је почео, помажући у бољој контроли штете.
Такође морате имати аутоматизовану процедуру за брисање старих датотека евиденције или за уклањање застарелих информација, како бисте спречили да троше сав расположиви простор за складиштење на серверу.
Бонус савет: будите информисани
На Интернету постоји много бесплатних и корисних информација које можете користити за добробит ваше веб апликације. Не пропустите ниједан нови пост на угледним безбедносним блоговима (попут овог) и будите информисани о томе шта се дешава у безбедносној и веб индустрији.
Туториали, курсеви, видео записи и књиге су такође извори корисног знања. Вежбајте да проводите један или два сата недељно само да бисте били информисани о вестима из индустрије — То ће вам дати мир када знате да радите праву ствар како бисте своје апликације заштитили.