10 најчешћих рањивости веб безбедности

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

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

Овај водич се посебно фокусира на 10 уобичајених и значајних замки веб сигурности којих треба бити свестан, укључујући препоруке о томе како их могу ублажити. Фокус је на Топ 10 веб рањивости идентификовао Отворени пројекат заштите веб апликација (ОВАСП) , међународна, непрофитна организација чији је циљ побољшати безбедност софтвера широм света.

Мали почетник за сајбер безбедност пре него што започнемо - аутентификација и ауторизација

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

Дакле, пре него што наставимо, разјаснимо разлику између ова два појма:

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

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

Уобичајена грешка у веб безбедности # 1: Ињекционе мане

Недостаци убризгавања резултат су класичног неуспеха филтрирања непоузданог уноса. То се може догодити када нефилтриране податке проследите на СКЛ сервер (СКЛ убризгавање), у прегледач (КССС - разговараћемо о томе касније ), на ЛДАП сервер (убризгавање ЛДАП-а) или било где друго. Овде је проблем у томе што нападач може да убризга команде тим ентитетима, што резултира губитком података и отмицом прегледача клијената.

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

Превенција: Добра вест је да је заштита од убризгавања „једноставно“ питање правилног филтрирања вашег уноса и размишљања о томе да ли се неком уносу може веровати. Али лоше вести су то све унос треба правилно филтрирати, осим ако му се неупитно може веровати (али овде ми на памет пада изрека „никад не реци никад“).

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

Будући да је филтрирање прилично тешко извести исправно (попут криптографије), оно што обично саветујем је да се ослањам на функције филтрирања вашег оквира: доказано раде и темељито се прегледају. Ако не користите оквире, заиста треба добро размислити да ли не њихова употреба заиста има смисла у безбедносном контексту вашег сервера. 99% времена то не чини.

Уобичајена грешка у веб безбедности # 2: Неисправна аутентификација

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

Под претпоставком да неко још увек жели да уведе сопствени код за потврду идентитета у 2014. години (о чему размишљате ??), саветујем га. Изузетно је тешко исправити се, а постоји безброј могућих замки, само да поменем неколико:

1. УРЛ може садржати ИД сесије и пропустити га у заглављу референца неком другом.
2. Лозинке се можда неће шифровати ни у складишту ни у транзиту.
3. ИД-ови сесија могу бити предвидљиви, па је добијање приступа тривијално.
4. Можда је могуће фиксирање сесије.
5. Отмица сесије је можда могућа, временска ограничења нису правилно примењена или се користи ХТТП (без ССЛ заштите) итд.

Превенција: Најједноставнији начин да се избегне ова рањивост веб безбедности је употреба оквира. Можда ћете моћи правилно да примените ово, али прво је много лакше. У случају да желите да представите свој код, будите крајње параноични и едукујте се о томе шта су замке. Има их доста.

Уобичајена грешка у веб безбедности # 3: Цросс Сите Сцриптинг (КССС)

Ово је прилично распрострањен неуспех у санацији улазних података (у основи посебан случај честа грешка # 1 ). Нападач даје ЈаваСцрипт ознаке вашој веб апликацији на уносу. Када се овај унос врати кориснику неанификованом, прегледач корисника ће га извршити. То може бити једноставно као израда везе и наговарање корисника да је кликне, или може бити нешто много злокобније. При учитавању странице скрипта се покреће и, на пример, може се користити за слање колачића нападачу.

Превенција: Постоји једноставно решење за веб заштиту: немојте враћати ХТМЛ ознаке клијенту. Ово има додатну предност одбране од убризгавања ХТМЛ-а, сличног напада при којем нападач убацује обичан ХТМЛ садржај (као што су слике или гласни невидљиви флеш плејери) - не снажно, али засигурно досадно („молим вас, зауставите!“). Обично се заобилазним путем једноставно претварају сви ХТМЛ ентитети , па се то вратило као