У гэтым артыкуле пойдзе гаворка пра вядомых уразлівасцях OAuth. Чытачы таксама даведаюцца, як можна рэалізаваць бяспечную і абароненую аўтарызацыю ў вэб-дадатку.
OAuth - гэта надзейны пратакол, але яго ступень абароненасці ў значнай ступені залежыць ад дасведчанасці вэб-распрацоўнікаў пры рэалізацыі аўтарызацыі. Гэта робіць дадзеную тэму надзвычай важнай для спецыялістаў у сферы інфармацыйнай бяспекі. Ім неабходна забяспечыць высокі ўзровень абароны уліковых запісаў сваіх карыстальнікаў. Надышла пара пазнаёміцца з эфектыўнымі практыкамі, якія дапамогуць знізіць небяспеку дрэнны рэалізацыі OAuth.
ўвядзеннеПратакол OAuth 2.0 ў цяперашні час шырока выкарыстоўваецца ў розных прыкладаннях. З дапамогай яго становіцца даступным зручны карыстацкі інтэрфейс, больш лёгкая аўтэнтыфікацыя і аўтарызацыя у параўнанні з традыцыйнымі метадамі ўводу імя карыстальніка і пароля. Пры правільнай і прадуманай рэалізацыі пратакол OAuth будзе больш бяспечным, чым традыцыйная аўтарызацыя, паколькі карыстальнікам не трэба дзяліцца сваімі ўліковымі дадзенымі са іншым дадаткам для атрымання доступу да вызначанага рэсурсу. Карыстальнікі часта аддаюць перавагу ўваходзіць у сістэму з дапамогай іх акаўнтаў Google, Facebook або LinkedIn замест таго, каб ствараць новы ўліковы запіс кожны раз, калі трэба зарэгістравацца на нейкім вэб-сайце. Такім чынам, пратакол OAuth значна спрашчае наша жыццё.
У цэлым, папулярныя пастаўшчыкі паслуг OAuth вельмі надзейныя. Уваход у сістэму з дапамогай акаўнта Google або Facebook выклікае карыстальнікам пэўны пачуццё бяспекі, і гэта правільна. Пратакол старанна пратэставаны спецыялістамі. Усе наяўныя уразлівасці заўсёды хутка выпраўляюцца камандай распрацоўшчыкаў. Аднак, варта адзначыць, што пачуццё поўнай бяспекі можа быць ілжывым.
Пастаўшчыкі паслуг OAuth пакінулі распрацоўнікам прыкладанняў шмат прычын пахвалявацца аб бяспецы сваіх праграм. На самай справе, першапачаткова абаронены сэрвіс OAuth, няправільна рэалізаваны ў працэсе яго ўстаноўкі, можа стаць лёгкай мішэнню для зламыснікаў. Падобная бязладнасць прывядзе да крадзяжу асабістых дадзеных карыстальнікаў.
Далей варта разгледзець найбольш распаўсюджаныя ўразлівасці, якія сустракаюцца ў іншых прыкладаннях, якія рэалізуюць пратакол OAuth для аўтарызацыі сваіх карыстальнікаў. Трэба памятаць, што сам пратакол бяспечны і надзейны. Толькі пасля няслушнай рэалізацыі ён становіцца ўразлівым для нападаў хакераў.
Крадзеж токена OAuth з дапамогай загалоўку RefererКалі праграма запытвае аўтарызацыю ад імя карыстальніка ў сервера OAuth, чалавек атрымлівае код, які варта ўвесці і адправіць назад на сервер для яго наступнай праверкі. Калі падчас прац карыстальнік будзе перанакіраваны на іншую старонку, то код будзе бачны ў загалоўку «Referer» HTTP-запыту. Такім чынам, код патрапіць на знешні вэб-сайт, што паставіць пад пагрозу зарэгістраваныя на сэрвэры OAuth дадзеныя карыстальнікаў.
Заўвага: загаловак «Referer» - гэта загаловак HTTP-запыту, ён перадае хасту Адрас URL, з якога адпраўляецца запыт.
Каб змякчыць наступствы дадзенай уразлівасці, распрацоўніку неабходна пераканацца, што яго веб-дадатак не ўтрымлівае якіх-небудзь html-ін'екцый. Калі ін'екцыі былі выяўленыя, то зламыснік з лёгкасцю можа ўсталяваць тэг выявы на свой вэб-сервер і знайсці спосаб перанакіраваць карыстальніка на яго. Такім чынам, ён атрымае магчымасць скрасці код з загалоўка «Referer» HTTP-запыту.
Крадзеж токена OAuth з дапамогай параметру redirect_uriДадатак ініцыюе працэс аўтарызацыі, адпраўляючы запыт на сервер OAuth:
https://www.example.com/signin/authorize?[...]&redirect_uri=https://demo.example.com/loginsuccessful
Запыт заўсёды ўтрымлівае параметр «redirect_uri», які выкарыстоўваецца серверам OAuth для адпраўкі токена назад у дадатак пасля таго, як карыстальнік даў сваю згоду. У выпадку, калі значэнне гэтага параметру не кантралюецца ці не правяраецца, зламыснік можа лёгка змяніць яго і перанакіраваць запыт на свой вэб-сайт, дзе ён выкарыстоўвае спецыяльную праграму для апрацоўкі токена і атрымання доступу да абмежаванага рэсурсу.
https://www.example.com/signin/authorize?[...]&redirect_uri=https://localhost.evil.com
Часам падобныя URL блакуюцца. Зламыснік можа перанакіраваць атрыманыя дадзеныя на адкрыты URL, як гэты:
https://www.example.com/oauth20_authorize.srf?[...]&redirect_uri=https://accounts.google.com/BackToAuthSubTarget?next=https://evil.com
Ці гэты:
https://www.example.com/oauth2/authorize?[...]&redirect_uri=https%3A%2F%2Fapps.facebook.com%2Fattacker%2F
Пры рэалізацыі OAuth ніколі нельга ўключаць у белы спіс цэлыя дамены. Варта дадаваць толькі некалькі URL-адрасоў, каб «redirect_uri" не перанакіроўваў запыт на Open Redirect.
Падробка межсайтовый запытаўПадробка межсайтовый запыту можа адбыцца, калі зламысніку ўдасца прымусіць ахвяру націснуць на яго спасылку і, такім чынам, згенераваць запыт які ён не збіраўся генераваць. Падробка межсайтовый запытаў звычайна мякчэе з дапамогай токена CSRF, які звязаны з сеансам карыстальніка. Ён дапамагае дадаткам праверыць асобу чалавека, адправіць запыт. Параметр «state» ў пратаколе OAuth служыць токенаў CSRF.
Варта зірнуць, як ажыццяўляецца CSRF-атака на OAuth і як параметр «state» можа быць выкарыстаны для змякчэння наступстваў уразлівасці.
Хакер адкрывае вэб-дадатак і запускае працэс аўтарызацыі для атрымання доступу да пастаўшчыка паслуг з дапамогай OAuth. Прыкладанне запытвае ў пастаўшчыка паслуг дазвол на доступ, які неабходна падаць. Хакер будзе перанакіраваны на вэб-сайт пастаўшчыка паслуг, дзе звычайна трэба ўвесці сваё імя карыстальніка і пароль для аўтарызацыі доступу. Замест гэтага хакер ловіць і прадухіляе гэты запыт і захоўвае яго URL-адрас. Хакер нейкім чынам прымушае ахвяру адкрыць гэты URL. Калі ахвяра ўвайшла ў сістэму пастаўшчыка паслуг, выкарыстоўваючы свой рахунак, то яе ўліковыя дадзеныя будуць выкарыстаны для выдачы кода аўтарызацыі. Код аўтарызацыі абменьваецца на токен доступу. Цяпер уліковы запіс хакера ў дадатку аўтарызаваныя. Ён можа атрымаць доступ і да ўліковага запісу ахвяры.
Такім чынам, як можна прадухіліць гэту сітуацыю з дапамогай параметру «state»?
Прыкладанне павінна стварыць значэнне, якое нейкім чынам заснавана на зыходнай ўліковага запісу (напрыклад, задзейнічаць хэш-ключ сеансу карыстальніка). Не гэтак важна, якое яно, галоўнае, што значэнне унікальна і генеруецца з выкарыстаннем прыватнай інфармацыі аб першапачатковым карыстальніку. Яно і прысвойваецца параметры «state».
Гэта значэнне перадаецца пастаўшчыку паслуг пры перанакіраванні. Цяпер хакер запрашае ахвяру адкрыць URL-адрас, які ён захаваў.
Код аўтарызацыі выдаецца і адпраўляецца назад кліенту ў сеансе разам з параметрам «state».
Кліент генеруе значэнне параметру на аснове інфармацыі пра сеанс і параўноўвае яго са значэннем «state», які быў адпраўлены назад з запыту аўтарызацыі пастаўшчыку паслуг. Гэта значэнне не адпавядае параметру «state» ў запыце, бо яно было згенеравана толькі на аснове інфармацыі аб бягучым сеансе. У выніку, атрыманае значэнне не прымаецца сістэмай.
Іншыя ўразлівасці, выяўленыя пры рэалізацыі OAuth, ўключаюць у сябе магчымасць выканання XSS (межсайтовый скріптінга) з выкарыстаннем параметру «redirect_uri», раскрыццё OAuth Private Key (ключ часам можа быць атрыманы пры дэкампіляцыя мабільнага прыкладання) і Authorization Code Rule Violation (калі код аўтарызацыі можа быць выкарыстаны больш за адзін раз для выдачы некалькіх токенаў доступу). Гэтыя ўразлівасці сустракаюцца радзей, чым апісаныя вышэй, але гэта не робіць іх меней небяспечнымі. Распрацоўшчык павінен ведаць усе неабходныя практыкі, каб забяспечыць надзейную працу свайго вэб-прыкладанні.
Аўтар перакладзенай артыкулы: Simon Saliba.
Важна! Інфармацыя выключна ў навучальных мэтах. Калі ласка, шануйце заканадаўства і не ўжывайце гэтую інфармацыю ў незаконных мэтах.
Больш цікавага матэрыялу на cisoclub.ru. Падпісвайцеся на нас: Facebook | VK | Twitter | Instagram | Telegram | дзэн | мессенджер | ICQ New | YouTube | Pulse.