За превише компанија то није тек после дошло је до нарушавања безбедности да најбоље праксе веб безбедности постану приоритет. Током година рада као професионалца за ИТ безбедност, видео сам изнова и изнова колико свет безбедности веб развоја може бити нејасан многим мојим особама колеге програмери .
Учинковит приступ пријетњама безбједности на мрежи мора по дефиницији бити проактиван и одбрамбени. У том циљу, овај пост има за циљ да потакне сигурносни начин размишљања, надам се да ће читаоцу убризгати здраву дозу параноје.
Овај водич се посебно фокусира на 10 уобичајених и значајних замки веб сигурности којих треба бити свестан, укључујући препоруке о томе како их могу ублажити. Фокус је на Топ 10 веб рањивости идентификовао Отворени пројекат заштите веб апликација (ОВАСП) , међународна, непрофитна организација чији је циљ побољшати безбедност софтвера широм света.
Када разговарам са другим програмерима и ИТ професионалцима, често наилазим на забуну у погледу разлике између ауторизације и аутентификације. И наравно, чињеница скраћеница аутх се често користи за обоје помаже у погоршању ове уобичајене забуне. Ова забуна је толико честа да би ово питање требало уврстити у овај пост као „Нула заједничке рањивости интернета“.
Дакле, пре него што наставимо, разјаснимо разлику између ова два појма:
Речено на други начин, Аутентикација је знати ко је ентитет, док овлашћење је знати шта дати ентитет може да уради. Имајући ово на уму, уђимо у првих 10 проблема са безбедношћу интернета.
Недостаци убризгавања резултат су класичног неуспеха филтрирања непоузданог уноса. То се може догодити када нефилтриране податке проследите на СКЛ сервер (СКЛ убризгавање), у прегледач (КССС - разговараћемо о томе касније ), на ЛДАП сервер (убризгавање ЛДАП-а) или било где друго. Овде је проблем у томе што нападач може да убризга команде тим ентитетима, што резултира губитком података и отмицом прегледача клијената.
Све што ваша апликација добије из непоузданих извора мора бити филтрирано, по могућности према белој листи. Готово никада не бисте требали користити црну листу, јер је постизање тог права врло тешко и обично је лако заобићи. Антивирусни софтверски производи обично нуде звездане примере неуспелих црних листа. Подударање образаца не функционише.
Превенција: Добра вест је да је заштита од убризгавања „једноставно“ питање правилног филтрирања вашег уноса и размишљања о томе да ли се неком уносу може веровати. Али лоше вести су то све унос треба правилно филтрирати, осим ако му се неупитно може веровати (али овде ми на памет пада изрека „никад не реци никад“).
На пример, у систему са 1.000 улаза, успешно филтрирање њих 999 није довољно, јер ово и даље оставља једно поље које може служити као лечење Ахила да сруши ваш систем. И можда бисте помислили да је стављање резултата СКЛ упита у други упит добра идеја, јер се има поверење у базу података, али ако периметар није, улаз индиректно долази од момака са злонамерном намером. Ово се зове СКЛ Ињецтион другог реда у случају да сте заинтересовани.
Будући да је филтрирање прилично тешко извести исправно (попут криптографије), оно што обично саветујем је да се ослањам на функције филтрирања вашег оквира: доказано раде и темељито се прегледају. Ако не користите оквире, заиста треба добро размислити да ли не њихова употреба заиста има смисла у безбедносном контексту вашег сервера. 99% времена то не чини.
Ово је скуп вишеструких проблема који се могу појавити током неисправне аутентификације, али не потичу сви из истог основног узрока.
Под претпоставком да неко још увек жели да уведе сопствени код за потврду идентитета у 2014. години (о чему размишљате ??), саветујем га. Изузетно је тешко исправити се, а постоји безброј могућих замки, само да поменем неколико:
Превенција: Најједноставнији начин да се избегне ова рањивост веб безбедности је употреба оквира. Можда ћете моћи правилно да примените ово, али прво је много лакше. У случају да желите да представите свој код, будите крајње параноични и едукујте се о томе шта су замке. Има их доста.
Ово је прилично распрострањен неуспех у санацији улазних података (у основи посебан случај честа грешка # 1 ). Нападач даје ЈаваСцрипт ознаке вашој веб апликацији на уносу. Када се овај унос врати кориснику неанификованом, прегледач корисника ће га извршити. То може бити једноставно као израда везе и наговарање корисника да је кликне, или може бити нешто много злокобније. При учитавању странице скрипта се покреће и, на пример, може се користити за слање колачића нападачу.
Превенција: Постоји једноставно решење за веб заштиту: немојте враћати ХТМЛ ознаке клијенту. Ово има додатну предност одбране од убризгавања ХТМЛ-а, сличног напада при којем нападач убацује обичан ХТМЛ садржај (као што су слике или гласни невидљиви флеш плејери) - не снажно, али засигурно досадно („молим вас, зауставите!“). Обично се заобилазним путем једноставно претварају сви ХТМЛ ентитети , па се то вратило као . Други често коришћени начин санације је коришћење регуларних израза за уклањање ХТМЛ ознака помоћу регуларних израза на
<
и >
, али ово је опасно, јер ће многи прегледачи сасвим добро протумачити озбиљно покварени ХТМЛ. Боље претворити све знакове у одбегле колеге.
Ово је класичан случај поверења корисничком уносу и плаћања цене настале сигурносне рањивости. Директна референца објекта значи да је интерни објекат као што је датотека или кључ базе података изложен кориснику. Проблем је у томе што нападач може пружити ову референцу и, ако се ауторизација или не изврши (или је неисправна), нападач може приступити или учинити ствари из којих треба бити онемогућен.
На пример, код има download.php
модул који чита и омогућава кориснику да преузме датотеке, користећи ЦГИ параметар да наведе име датотеке (нпр. download.php?file=something.txt
). Било грешком или због лењости, програмер је изоставио овлашћење из кода. Нападач то сада може користити за преузимање било којих системских датотека којима корисник који користи ПХП има приступ, попут самог кода апликације или других података који су остали на серверу, попут сигурносних копија. Ух Ох.
Још један уобичајени пример рањивости је функција ресетовања лозинке која се ослања на унос корисника да би одредила чију лозинку ресетујемо. Након што кликне на важећу УРЛ адресу, нападач може само изменити username
у УРЛ-у да кажете нешто попут „админ“.
Узгред, оба ова примера су ствари које сам и сама видела да се често појављују „у дивљини“.
Превенција: Извршите овлашћење корисника правилно и доследно и ставите изборе на белу листу. Ипак, чешће се не може цео проблем избећи интерним складиштењем података и не ослањањем на њихово прослеђивање од клијента путем ЦГИ параметара. У ту сврху су погодне променљиве сесије у већини оквира.
Према мом искуству, веб сервери и апликације који су погрешно конфигурисани су много чешћи од оних који су правилно конфигурисани. Можда то зато што не недостаје начина да се зезну. Неки примери:
Превенција: Имајте добар (по могућности аутоматизовани) процес „израде и примене“, који може да покреће тестове приликом примене. Решење безбедносне погрешне конфигурације сиромашног човека чине куке после предавања, како би се спречило да код изађе са подразумеваним лозинкама и / или уграђеним развојним стварима.
Ова рањивост веб заштите односи се на крипто и заштиту ресурса. Осетљиви подаци треба да буду шифровани у сваком тренутку, укључујући у транзиту и у мировању. Без изузетака. Подаци о кредитној картици и корисничке лозинке би требало никад путујте или се чувајте нешифровани, а лозинке увек треба хеширати. Очигледно је да алгоритам крипто / хеширања не сме бити слаб - када сте у недоумици, препоручују стандарди безбедности на мрежи АЕС (256 бита и више) и РСА (2048 бита и више) .
И иако се подразумева да ИД-ови сесија и осетљиви подаци не би требало да путују у УРЛ-овима, а осетљиви колачићи треба да имају сигурну заставицу, ово је веома важно и не може се превише нагласити.
Превенција:
У пролазу: Користите ХТТПС са одговарајућом потврдом и ПФС (Савршена прослеђена тајност) . Не прихватајте ништа преко веза које нису ХТТПС. Имајте сигурну заставицу на колачићима.
На складишту: Ово је теже. Прво и најважније, морате смањити изложеност. Ако вам нису потребни осетљиви подаци, исеците их. Подаци које немате не могу бити украден . Не чувајте податке о кредитној картици икад , јер вероватно не желите да имате посла са бићем ПЦИ усклађен . Региструјте се са процесором плаћања као што је Стрипе или Браинтрее . Друго, ако имате осетљиве податке који су вам заиста потребни, сачувајте их шифровано и побрините се да су све лозинке хеширане. За хеширање користите бцрипт препоручује. Ако не користите бцрипт, едукујте се о томе сољење и дугини столови .
И ризикујући да кажем очигледно, не чувајте кључеве за шифровање поред заштићених података . То је попут складиштења бицикла са бравом у којој је кључ. Заштитите своје резервне копије шифрирањем и држите своје кључеве врло приватним. И наравно, не губите кључеве!
Ово је једноставно неуспех ауторизације. То значи да када се функција позове на серверу, није извршена одговарајућа ауторизација. Пуно пута програмери се ослањају на чињеницу да је страна сервера генерисала кориснички интерфејс и мисле да клијент не може да приступи функционалности коју сервер не пружа. То није тако једноставно, јер нападач увек може фалсификовати захтеве за „скривену“ функционалност и неће га одвратити чињеница да корисничко сучеље не чини ову функцију лако доступном. Замислите да постоји /admin
, а дугме је присутно у корисничком интерфејсу само ако је корисник заправо администратор. Ништа не спречава нападача да открије ову функцију и злоупотреби је ако недостаје ауторизација.
Превенција: На страни сервера, ауторизација мора увек бити урађено. Да, увек. Ниједан изузетак или рањивост неће резултирати озбиљним проблемима.
Ово је леп пример а збуњени заменик напад којим је нека друга страна преварила прегледач да злоупотребљава своја овлашћења. На пример, веб локација треће стране може да учини да корисников прегледач злоупотреби овлашћење да учини нешто за нападача.
У случају ЦСРФ-а, независна веб локација издаје захтеве циљаној веб локацији (нпр. Вашој банци) помоћу прегледача са колачићима / сесијом. Ако сте, на пример, пријављени на једној картици на почетној страници банке и они су подложни овом нападу, друга картица може да учини да ваш прегледач злоупотреби поверљиве податке у име нападача, што ће довести до збуњеног проблема заменика. Заменик је прегледач који злоупотребљава своја овлашћења (колачићи сесије) да би урадио нешто што му нападач нареди.
Размотрите овај пример:
Нападач Алице жели да олакша циљни Тодов новчаник тако што ће јој пребацити део свог новца. Тодова банка је осетљива на ЦСРФ. Да би послао новац, Тодд мора да приступи следећем УРЛ-у:
имг / бацк-енд / 29/10-најчешће-веб-безбедност-рањивости.јпг
Након отварања ове УРЛ адресе, Тодду се приказује страница за успех и пренос је готов. Алице такође зна да Тод често посећује веб локацију под њеном контролом на блог.алицеисавесоме.цом, где поставља следећи исечак:
Након посете Алице-ином веб сајту, Тодов прегледач мисли да се Алице повезује са сликом и аутоматски издаје ХТТП ГЕТ захтев за преузимање слике, али ово заправо налаже Тоддовој банци да пребаци Алице на 1500 долара.
Узгред, поред демонстрације ЦСРФ рањивости, овај пример такође показује и промену стања сервера са идемпотентним ХТТП ГЕТ захтевом, што је само по себи озбиљна рањивост. ХТТП ГЕТ захтеви мора бити идемпотентан (сигурно), што значи да не могу мењати ресурс којем се приступа. Никада, никада, никада немојте користити идемпотентне методе за промену стања сервера.
Забавна чињеница: ЦСРФ је такође метода коју су људи раније користили за пуњење колачића док подружнице нису постале мудрије.
Превенција: Похраните тајни токен у поље скривеног обрасца којем није могуће приступити са независне веб локације. Наравно, увек морате да верификујете ово скривено поље. Неке веб локације траже вашу лозинку и приликом мењања осетљивих подешавања (на пример, е-адреса за подсетник на лозинку), мада претпостављам да је ово ту да спречи злоупотребу напуштених сесија (на пример у интернет кафићу).
Наслов све говори. Поново бих ово класификовао као већи проблем одржавања / примене. Пре него што уградите нови код, обавите неко истраживање, можда и ревизију. Користећи код који сте добили од случајне особе ГитХуб или неки форум може бити врло згодан, али није без ризика од озбиљне рањивости веб безбедности.
Видео сам много случајева, на пример, где су веб локације дошле власништво (тј. тамо где аутсајдер добија административни приступ систему), не зато што су програмери били глупи, већ зато што је софтвер независних произвођача годинама остао закрпан у производњи. То се, на пример, стално дешава са ВордПресс додатцима. Ако мислите да неће пронаћи ваш скривени phpmyadmin
инсталација, дозволите ми да вас упознам са дирбустером.
Овде је поука да се развој софтвера не завршава када се апликација примени. Мора постојати документација, тестови и планови како да се одржава и ажурира, посебно ако садржи компоненте независних произвођача или отвореног кода.
Превенција:
Будите опрезни. Осим очигледне опрезности при коришћењу таквих компоненти, немојте бити цопи-пасте кодер. Пажљиво прегледајте део кода који ћете ставити у свој софтвер, јер би могао бити покварен без поправке (или у неким случајевима намерно злонамерно - напади веб безбедности се понекад несвесно позивају на овај начин).
Остану у току. Обавезно користите најновије верзије свега у шта имате поверења и планирајте да их редовно ажурирате. Барем се претплатите на билтен нових сигурносних пропуста у вези са производом.
Ово је још један проблем са улазним филтрирањем. Претпоставимо да циљна локација има redirect.php
модул који узима УРЛ као GET
параметар. Манипулација параметром може створити УРЛ на targetsite.com
која преусмерава прегледач на malwareinstall.com
. Када корисник види везу, видеће targetsite.com/blahblahblah
за коју корисник мисли да му се верује и да је сигурно кликнути на њу. Они мало знају да ће их ово заправо пребацити на испуштање малвера (или било коју другу злонамерну) страницу. Алтернативно, нападач може преусмерити прегледач на targetsite.com/deleteprofile?confirm=1
.
Вреди напоменути да уметање несанификованог корисничког уноса у ХТТП заглавље може довести до тога убризгавање заглавља што је прилично лоше.
Превенција: Опције укључују:
Надам се да сам успео да вам мало заголица мозак овим постом и да уведем здраву дозу параноје и свести о угрожености веб локација.
Суштинско решење овде је да прастаре праксе софтвера постоје с разлогом и оно што се примењивало у то време за преливе међуспремника, и данас важи за укисељене низове у Питхону. Сигурносни протоколи помажу вам да напишете (више) исправне програме, којима би сви програмери требало да теже.
Молимо користите ово знање одговорно и не тестирајте странице без дозволе!
За више информација и више специфични напади на страни сервера , Погледајмо: хттпс://ввв.овасп.орг/индек.пхп/Цатегори:Аттацк .
Повратне информације о овом посту и саветима за његово ублажавање су добродошле и цењене. Планирају се будућа радна места, посебно по питању дистрибуирано ускраћивање услуге (ДДоС) и рањивости информатичке безбедности (не на мрежи). Ако имате одређени захтев о каквој врсти веб заштите да пишете, слободно ме контактирајте директно на [емаил заштићен]
Ево заштите веб страница! Живели.
Повезан:Претње безбедношћу на Интернету су методе злоупотребе веб технологије на штету веб локације, њених корисника или чак интернета у целини. Настају на веб локацијама које су погрешно конфигурисане, које су нехотице програмиране са рањивостима или се ослањају на компоненте које су саме по себи рањиве.
Првих 10 безбедносних претњи на Интернету су недостаци убризгавања и аутентификације, КССС, несигурне референце директних објеката, погрешна конфигурација безбедности, изложеност осетљивих података, недостатак ауторизације на нивоу функције, ЦСРФ, несигурне компоненте и нефилтрирана преусмеравања.
Уверите се да се било која преусмеравања која ваша веб локација (преко ХТТП заглавља, метатагова, ЈаваСцрипт-а итд.) Не ослањају на унос корисника, или ако јесу, да је унос корисника саниран, на пример путем беле листе.
ЦСРФ токен даје серверу до знања да је захтев стигао од корисника његове сопствене веб локације, а не од неке друге веб локације коју корисник посећује. То је зато што се прослеђује уз сваки захтев путем скривеног поља обрасца, спречавајући злонамерне веб локације да делују у име својих гледалаца путем ЦСРФ напада.
Такође познат под називом „прљав“ или „непоуздан“ унос, неовлашћени унос је сваки улаз који се пошаље на ваш сервер. Било који део кода који користи такав улаз, а да га претходно не санира, представља сигурносну рањивост која се може окренути против вас, ваших корисника, па чак и невиних пролазника.
СКЛ убризгавање је када ваш код стави неваљани унос директно у СКЛ израз, уместо да користи параметарски упит (тј. Онај са резервираним местима.) Срећом, напади СКЛ убризгавања један су од најлакших за ублажавање, јер је параметарска подршка уграђена у сваку базу података. приступ библиотеци.
КССС користи погрешно вођене имплементације уобичајене „функције“ веб апликације: за примање ХТМЛ-а од једног корисника и представљање другим корисницима. Будући да нефилтрирани ХТМЛ може садржати ЈаваСцрипт, нападач тада може покретати код у име других корисника када следећи пут користи дотичну веб апликацију.
Погрешна конфигурација безбедности често укључује коришћење подразумеваних вредности које би требало променити: кључеви и лозинке, приступ подацима и услугама који је у почетку био либералан за подешавање и тестирање погодности и занемаривање текућих безбедносних исправки.
То је када сервер није програмиран да верификује ауторизацију за дату функцију. То често долази из начина размишљања „заштита кроз опскурност“: Погрешно се претпоставља да ако осетљива функција није приказана свима, потенцијални нападачи никада неће сазнати за њу.
Изложеност осетљивим подацима је када апликација (било због сопствене мане, било због злоупотребе рањивости од стране нападача) открива корисникове приватне податке (нпр. Бројеве кредитних картица) неовлашћеној трећој страни: другим корисницима, пословним партнерима, запосленима или јавно.