Овај чланак ће се бавити добро познатим рањивости ОАутх. Читаоци ће такође научити како да имплементирају сигурна и сигурна овлашћење у веб апликацији.
Оаутх је поуздан протокол, али његов степен безбедности у великој мери зависи од свести веб програмера приликом спровођења ауторизације. То чини ову тему изузетно важну за професионалце за безбедност информација. Они морају да дају висок ниво заштите рачуна својих корисника. Време је да се упознате са ефективним практичарима који ће вам помоћи да смањи опасност од лошег продаје ОАУТХ.
УвођењеОАУТХ 2.0 протокол се тренутно широко користи у различитим апликацијама. Користећи га, погодан кориснички интерфејс постаје доступан, лакша аутентификација и ауторизација у поређењу са традиционалним методама за унос корисничког имена и лозинке. С правилном и промишљеном имплементацијом, протокол ОАУТХ биће сигурнији од традиционалног одобрења, јер корисници не морају да деле своје рачуноводствене податке са захтевом треће стране да би приступили одређеном ресурсу. Корисници се често радије пријављују користећи своје Гоогле налоге, Фацебоок или ЛинкедИн, уместо да креирају нови налог сваки пут када се морате регистровати на неку веб локацију. Стога, протокол ОАУТХ увелике поједностављује наше животе.
Генерално, Популарни добављачи услуга ОАутх су веома поуздани. Пријавите се Гоогле или Фацебоок налогом надахњују одређени осећај сигурности и тачно је. Протокол пажљиво тестирају стручњаци. Све доступне рањивости увек брзо исправља тим програмера. Међутим, вреди напоменути да осећај потпуне сигурности може бити лажан.
ОАУТХ пружаоци услуга оставили су програмерима апликације много разлога да би се заштитили сигурност својих програма. У ствари, првобитно заштићена ОАУТХ услуга, погрешно спроведена у процесу његове инсталације, може постати лака мета уљеза. Таква преокупација ће довести до крађе личних података корисника.
Затим бисте требали размотрити најчешће рањивости које се сусрећу у трећим апликацијама које имплементирају ОАУТХ протокол да одобре своје кориснике. Мора да се сети да је сам протокол сигуран и поуздан. Тек након нетачне примене, постаје рањиво на хакерски напади.
ОАУТХ ТОЦКЕИ крађа помоћу наслова рефератораКада апликација захтијева овлашћење у име корисника на ОАУТХ серверу, особа прима код за улазак и повратак на сервер за његов наредни чек. Ако ће током рада корисник бити преусмерен на другу страницу, код ће се видети на "реферира" заглавље ХТТП затраженог захтева. Дакле, код ће пасти на спољној веб страници, што ће угрозити корисничке податке регистроване на ОАУТХ серверу.
НАПОМЕНА: Заглавље рефератора је ХТТП заглавље упита, преноси УРЛ хост са којих се захтев шаље.
Да би ублажили последице ове рањивости, програмер мора да се увери да његова веб апликација не садржи ХТМЛ ињекције. Ако су откривене ињекције, нападач може лако да постави ознаку слике на свој веб сервер и пронађе начин да преусмери корисника на њему. Стога ће добити прилику да украде код са "реферира" заглавље ХТТП захтева.
Оаутх ТОЦКЕИ крађа помоћу параметра Редирецт_уриАпликација покреће поступак ауторизације слањем захтева за ОАУТХ серверу:
хттпс: //ввв.екампле.цом/сигнин/аутхоризе? евиденце...Сен.Сен.Сенен.нДен.НеДирецт_ури = Хттп: //демо.екампле.цом/логинсуццессфул.
Упит увек садржи параметар "Редирецт_ури" који је ОАУТХ сервер користио да би се токенс вратио на захтев након што је корисник дао пристанак. Ако вредност овог параметра не контролише или није проверена, нападач га може лако променити и преусмерити на његову веб страницу, где користи посебан програм за обраду токена и добитак приступа ограниченом ресурсу.
хттпс: //ввв.екампле.цом/сигнин/Аутхоризе? евиденце...Сен.Сен.Сенен.нДен.Слеаде & Адирецт_ури = Хттп: //лоцалхост.евил.цом.
Понекад су слични УРЛ-ови блокирани. Нападач може преусмерити примљене податке на отвореном УРЛ-у, попут ове:
хттпс: //ввв.екампле.цом/оаутх20_аутхоризе.срф? евидент ... еиндитуре & редирецт_ури = хттп: //аццоунтс.гоогле.цом/БацкТоутХСубТаргет? нект = ХттпСет: //евил.цом.
Или ово:
хттпс: //ввв.екампле.цом/оаутх2/Ауторизе? [...]% иРецт_ури = хттпс% 3а% 2Ф% 2фаппс.фацебоок.цом% 2фаттацкер% 2ф.
Када имплементирате ОАУТХ, никада не можете да укључите читаве домене на белој листи. Само неколико УРЛ-ова треба додати "Редирецт_ури" није преусмерен захтев за отварање преусмеравања.
Фалсификовање унакрсних захтеваНапласник захтјева за престоље може се појавити када нападач успе да учини жртву да кликне на своју везу и, на тај начин да створи захтев да он неће генерисати. Фасферирање унакрсних захтева обично се омекшава ЦСРФ токен, који је повезан са седницом корисника. Помаже апликацији да провери особу особе која је послала захтев. Параметар "Државни" у протоколу ОАУТХ служи као ЦСРФ токен.
Вриједно је гледати како се напад ЦСРФ изводи на ОАУТХ и док се параметар "држава" може користити за ублажавање ефеката рањивости.
Хакер отвара веб апликацију и покреће поступак ауторизације за приступ провајдеру сервиса користећи ОАУТХ. Апликација захтева да провајдера сервиса приступи ономе да се мора пружити. Хакер ће бити преусмерен на веб страницу провајдера сервиса, где обично морате да унесете своје корисничко име и лозинку за одобрење приступа. Уместо тога, хакер хвата и спречава овај захтев и штеди његов УРЛ. Хакер некако изазива жртву да отвори овај УРЛ. Ако је жртва ушла у систем провајдера сервиса користећи свој рачун, тада ће се њени акредитиви користити за издавање кода ауторизације. Код ауторизације размјењује приступ приступу токену. Сада је хакерски рачун у апликацији овлашћен. Може да приступи рачуну жртве.
Па, како могу да спречим ову ситуацију користећи параметар "државни"?
Апликација мора да створи вредност која је некако заснована на изворном рачуну (на пример, користите тастер Хасх Хасх сессион). Није толико важно шта је то, главна ствар је да је вредност јединствена и генерисана помоћу приватних информација о оригиналном кориснику. Додељен је параметру "државни".
Ова вредност се преноси на провајдера сервиса приликом преусмеравања. Сада хакер позива жртву да отвори УРЛ адресу, коју је задржао.
Код ауторизације издаје се и враћа клијенту на седници, заједно са "државним" параметром.
Клијент ствара вредност параметра заснован на информацијама о сесији и упоређује га са "државном" вриједношћу, која је послата од захтева за ауторизацију добављачу услуга. Ова вредност не одговара параметру "држава" у упиту, јер је генерисана само на основу информација о тренутној седници. Као резултат, добијена вредност није прихваћена од стране система.
Остале рањивости откривене су када имплементирајући ОАУТХ укључују могућност извођења КССС-а (скриптације са "Редирецт_ури", поставком "Редирецт_ури", поставке ОАУТХ-а (кључ се може понекад добити када декомпилише мобилну апликацију) и прекршај кодекса о ауторизацији (када Код ауторизације може се користити више пута да издаје вишеструко приступних токена). Ове рањивости су мање обичне од оних описаних горе, али то их не чини мање опасним. Програмер би требао знати све потребне праксе како би се осигурало поуздан рад своје веб апликације.
Аутор преведеног чланка: Симон Салиба.
Важно! Информације искључиво у академске сврхе. Молимо у складу са законодавством и не примењујте ове информације у илегалне сврхе.
Још занимљивији материјал на Цисоцлуб.ру. Претплатите се на нас: Фацебоок | ВК | Твиттер | Инстаграм | Телеграм | Зен | Мессенгер | ИЦК НОВО | ИоуТубе | Пулсе.