Оваа статија ќе се занимава со познатите OAUTH слабости. Читателите исто така ќе научат како да спроведат безбедно и сигурно овластување во веб апликацијата.
ОУТ е сигурен протокол, но нејзиниот степен на безбедност во голема мера зависи од свеста на веб програмерите при спроведување на овластување. Ова ја прави оваа тема исклучително важна за професионалците за информациска безбедност. Тие треба да обезбедат високо ниво на заштита на сметките на нивните корисници. Време е да се запознаат со ефективни практичари кои ќе помогнат во намалувањето на опасноста од сиромашните продаваат ОУ.
ВоведOAuth 2.0 протоколот во моментов е широко користен во различни апликации. Користејќи го, пригоден кориснички интерфејс станува достапен, полесно автентикација и овластување во споредба со традиционалните методи за внесување на корисничкото име и лозинката. Со правилно и внимателно спроведување, OAUT протоколот ќе биде побезбеден од традиционалното овластување, бидејќи корисниците не треба да ги споделуваат своите сметководствени податоци со апликација од трети лица за пристап до посебен ресурс. Корисниците честопати претпочитаат да се логираат со користење на нивните сметки на Google, Фејсбук или LinkedIn, наместо да создадат нова сметка секогаш кога треба да се регистрирате на некоја веб-страница. Така, OAUT протоколот во голема мера го поедноставува нашиот живот.
Во принцип, популарните OAuth даватели на услуги се многу сигурни. Пријавете се со сметката на Google или Facebook инспирира одредено чувство за сигурност, и тоа е точно. Протоколот внимателно тестиран од експерти. Сите достапни слабости секогаш брзо се коригираат од тимот на инвеститорот. Сепак, вреди да се напомене дека чувството на целосна безбедност може да биде неточно.
ОАУТ даватели на услуги ги напуштија развивачите на апликации многу причини да ја консумираат безбедноста на нивните програми. Всушност, првично заштитената OAuth услугата, неправилно имплементирана во процесот на нејзина инсталација, може да стане лесна цел за натрапниците. Таквата преокупација ќе доведе до кражба на лични податоци на корисниците.
Следно, треба да ги разгледате најчестите пропусти кои се соочуваат во апликации од трети страни кои го спроведуваат OAUT протоколот за да ги овластат своите корисници. Мора да се запомни дека самиот протокол е безбеден и сигурен. Само по неточна имплементација, станува ранлива на хакерски напади.
Oouth tokkey кражба со помош на референт заглавиеКога барањето бара овластување во име на корисникот на ОАУТ серверот, лицето го прима кодот за внесување и испраќање на серверот за следната проверка. Ако за време на работата корисникот ќе биде пренасочен на друга страница, кодот ќе се види во насловот "Референца" на HTTP-барањето. Така, кодот ќе падне на надворешната веб-страница, која ќе ги загрози корисничките податоци регистрирани на OAuth серверот.
Забелешка: Насловот на референцата е заглавието на HTTP, го пренесува URL-то домаќинот од кој е испратено барањето.
За да ги омекне последиците од оваа ранливост, инвеститорот мора да осигура дека неговата веб апликација не содржи никакви натписи на HTML. Ако биле откриени инјекции, напаѓачот лесно може да ја постави ознаката за слика на својот веб сервер и да најде начин да го пренасочи корисникот на него. Така, тој ќе добие можност да го украде кодот од заглавието "Референт" на HTTP-барањето.
Oouth tokkey кражба користејќи го параметарот Redirect_uriАпликацијата го иницира процесот на овластување со испраќање на барање до ОАУТ серверот:
https://www.example.com/signin/oothorize?[ ... dredirect_uri=httpps://demo.example.com/loginsucsucty.
Барањето секогаш го содржи параметарот "Redirect_uri" што го користи OAuth серверот за да испрати токени назад кон апликацијата откако корисникот ја даде својата согласност. Ако вредноста на овој параметар не е контролирана или не е проверена, напаѓачот лесно може да го промени и да го пренасочи барањето до својата веб-страница, каде што користи специјална програма за обработка на токен и добива пристап до ограничен ресурс.
https://www.example.com/signin/oothorize forums[ts_httpps://localhost.evil.com.
Понекогаш слични URL-адреси се блокирани. Напаѓачот може да ги пренасочи добиените податоци на отворениот URL, вака:
https://www.example.com/oauth20_authorize.srf foothlation...[.
Или ова:
https://www.example.com/OAuth2/oothorize? [...]% irect_uri = https% 3a% 2f% 2fapps.facebook.com% 2fattacker% 2f.
При спроведувањето на ОУ, никогаш не можете да ги вклучите целите домени во белата листа. Треба да се додадат само неколку URL адреси во "Redirect_uri" не пренасочени на барање за отворање на пренасочување.
Фалсификување на крос-линија барањаФалсификувањето на еднородно барање може да се случи кога напаѓачот успее да ја направи жртвата да кликне на неговата врска и, со што, да генерира барање дека нема да генерира. Фалсификувањето на крос-линиски барања обично се омекнува со токенот на CSRF, кој е поврзан со корисничката сесија. Тоа му помага на апликацијата да го провери лицето на лице кое го испратил барањето. Параметарот "државен" во OAUT протоколот служи како CSRF токен.
Вреди да се гледа како нападот на CSRF се врши на ОУТ и како "државен" параметар може да се користи за ублажување на ефектите од ранливоста.
Хакер отвора веб апликација и го отвора процесот на овластување за пристап до давателот на услуги користејќи OAuth. Апликацијата бара давател на услуги за пристап што треба да се обезбеди. Хакер ќе биде пренасочен на веб-страницата на давателот на услуги, каде што обично треба да го внесете вашето корисничко име и лозинка за да го овластите пристапот. Наместо тоа, хакерот го фаќа и го спречува ова барање и го зачувува својот URL. Хакер некако ја предизвикува жртвата да го отвори овој URL. Ако жртвата влезе во системот на давателот на услуги користејќи ја својата сметка, тогаш нејзините ингеренции ќе се користат за издавање на код за овластување. Кодот за одобрение го разменува пристапот до токен за пристап. Сега хакерската сметка во апликацијата е овластена. Тоа може да пристапи до сметката на жртвата.
Значи, како можам да ја спречам оваа ситуација со користење на "државниот" параметар?
Апликацијата мора да создаде вредност што е некако врз основа на изворната сметка (на пример, користете го клучот за кориснички сесии). Не е толку важно што е тоа, главната работа е дека вредноста е уникатна и генерирана со користење на приватни информации за оригиналниот корисник. Таа е доделена на "државниот" параметар.
Оваа вредност се пренесува на давателот на услуги кога се пренасочува. Сега хакерот ја поканува жртвата да го отвори URL-то, што го задржал.
Кодексот за авторизација се издава и се враќа на клиентот на седницата заедно со "државниот" параметар.
Клиентот генерира вредност на параметар врз основа на информации за сесија и го споредува со "државната" вредност, која беше вратена од барањето за овластување до давателот на услуги. Оваа вредност не се совпаѓа со "државниот" параметар во барањето, бидејќи е генерирана само врз основа на информации за тековната сесија. Како резултат на тоа, добиената вредност не е прифатена од системот.
Други ранливости откриени при спроведувањето на ОУТ вклучуваат способност за извршување на XSS (скриптирање на крос-сајт) со користење на параметарот "Redirect_uri", поставувањето на приватното копче на OAUT (клучот понекогаш може да се добие при декомпилирање на мобилната апликација) и правило за правило за овластување (кога Кодексот за авторизација може да се користи повеќе од еднаш за да издаде повеќе токени за пристап). Овие слабости се поретки од оние опишани погоре, но тоа не ги прави помалку опасни. Инвеститорот треба да ги знае сите потребни практики за да обезбеди сигурно работење на својата веб апликација.
Авторот на преведениот член: Симон Салиба.
Важно! Информации исклучиво за академски цели. Ве молиме усогласете со законодавството и не ги применувајте овие информации за нелегални цели.
Повеќе интересен материјал на cisoclub.ru. Претплатете се на нас: Фејсбук | VK | Твитер | Instagram | Телеграма | Зен | Messenger | ICQ New | YouTube | Пулс.