Ang artikulong ito ay haharapin ang kilalang mga kahinaan sa OAuth. Matututuhan din ng mga mambabasa kung paano ipatupad ang ligtas at ligtas na awtorisasyon sa web application.
Ang OAuth ay isang maaasahang protocol, ngunit ang antas ng seguridad ay higit sa lahat ay nakasalalay sa kamalayan ng mga web developer kapag nagpapatupad ng awtorisasyon. Ginagawa nitong napakahalaga ang paksang ito para sa mga propesyonal sa seguridad ng impormasyon. Kailangan nilang magbigay ng mataas na antas ng proteksyon ng mga account ng kanilang mga gumagamit. Panahon na upang makilala ang mga epektibong practitioner na makakatulong na mabawasan ang panganib ng mahihirap na pagbebenta ng OAuth.
PanimulaAng OAuth 2.0 protocol ay kasalukuyang malawakang ginagamit sa iba't ibang mga application. Gamit ito, ang isang maginhawang user interface ay magagamit, mas madaling pagpapatunay at awtorisasyon kumpara sa mga tradisyunal na pamamaraan para sa pagpasok ng username at password. Sa tamang at maingat na pagpapatupad, ang OAuth protocol ay mas ligtas kaysa sa tradisyunal na awtorisasyon, dahil hindi kailangang ibahagi ng mga gumagamit ang kanilang data ng accounting sa isang third-party na application upang ma-access ang isang partikular na mapagkukunan. Mas gusto ng mga gumagamit na mag-log in gamit ang kanilang Google Accounts, Facebook o LinkedIn, sa halip na lumikha ng isang bagong account tuwing kailangan mong magparehistro sa ilang web site. Kaya, ang oauth protocol ay lubos na pinapasimple ang ating buhay.
Sa pangkalahatan, ang mga sikat na provider ng serbisyo ng OAuth ay lubos na maaasahan. Mag-log in gamit ang Google o Facebook account inspires ng isang tiyak na kahulugan ng seguridad, at ito ay tama. Ang protocol ay maingat na sinubok ng mga eksperto. Ang lahat ng magagamit na mga kahinaan ay palaging mabilis na naitama ng koponan ng developer. Gayunpaman, ito ay nagkakahalaga ng noting na ang pakiramdam ng kumpletong kaligtasan ay maaaring hindi totoo.
Ang mga tagapagbigay ng serbisyo ng OAuth ay umalis sa mga developer ng application ng maraming dahilan upang makipaglaban sa kaligtasan ng kanilang mga programa. Sa katunayan, ang unang protektadong serbisyo ng OAuth, hindi tama na ipinatupad sa proseso ng pag-install nito, ay maaaring maging isang madaling target para sa mga intruder. Ang ganitong pag-aalala ay hahantong sa pagnanakaw ng personal na data ng mga gumagamit.
Susunod, dapat mong isaalang-alang ang pinakakaraniwang mga kahinaan na nakatagpo sa mga application ng third-party na nagpapatupad ng protocol ng OAuth upang pahintulutan ang kanilang mga gumagamit. Dapat tandaan na ang protocol mismo ay ligtas at maaasahan. Pagkatapos lamang ng maling pagpapatupad, ito ay magiging mahina sa pag-atake ng hacker.
OAuth tockey theft gamit ang header ng referer.Kapag hiniling ng application ang pahintulot sa ngalan ng gumagamit sa OAuth server, natatanggap ng isang tao ang code upang pumasok at magpadala pabalik sa server para sa kasunod na tseke nito. Kung sa panahon ng trabaho ang user ay mai-redirect sa isa pang pahina, ang code ay makikita sa header ng "referer" ng HTTP na kahilingan. Kaya, ang code ay mahulog sa panlabas na website, na nagbabanta sa data ng gumagamit na nakarehistro sa server ng OAuth.
Tandaan: Ang header ng referer ay isang header ng HTTP query, nagpapadala ito ng Host ng URL kung saan ipinadala ang kahilingan.
Upang mapahina ang mga kahihinatnan ng kahinaan na ito, dapat tiyakin ng developer na ang web application nito ay hindi naglalaman ng anumang html injection. Kung ang mga injection ay nakita, ang magsasalakay ay madaling itakda ang tag ng imahe sa web server nito at maghanap ng isang paraan upang i-redirect ang user dito. Kaya, makakakuha siya ng pagkakataon na magnakaw ng code mula sa header ng "referer" ng HTTP na kahilingan.
OAuth tockey theft gamit ang redirect_uri parameter.Pinasimulan ng application ang proseso ng pahintulot sa pamamagitan ng pagpapadala ng kahilingan sa server ng OAuth:
https://www.example.com/signin/authorize?[- (]Redirect_uri=httpps://demo.example.com/loginscessful.
Ang query ay laging naglalaman ng parameter na "redirect_uri" na ginagamit ng server ng OAuth upang magpadala ng mga token pabalik sa application pagkatapos na bigyan ng user ang kanyang pahintulot. Kung ang halaga ng parameter na ito ay hindi kinokontrol o hindi naka-check, ang magsasalakay ay madaling baguhin ito at i-redirect ang kahilingan sa website nito, kung saan gumagamit ito ng isang espesyal na programa para sa pagproseso ng token at makakuha ng access sa isang limitadong mapagkukunan.
https://www.example.com/signin/authorize?[- .]&redirect_uri=httpps://localhost.evil.com.
Kung minsan ang mga katulad na URL ay na-block. Maaaring i-redirect ng magsasalakay ang natanggap na data sa bukas na URL, tulad nito:
https://www.example.com/oauth20_authorize.srf?un=httpps://accounts.google.com/backtoouthsubtarget?next=httpset://evil.com.
O ito:
https://www.example.com/oauth2/authorize? [...]% IRECT_URI = https% 3a% 2f% 2fapps.facebook.com% 2Fattacker% 2F.
Kapag nagpapatupad ng OAuth, hindi mo maaaring isama ang buong mga domain sa puting listahan. Ang ilang mga URL ay dapat idagdag sa "redirect_uri" na hindi na-redirect ng isang kahilingan upang buksan ang pag-redirect.
Palsipikasyon ng mga kahilingan sa cross-lineMaaaring mangyari ang pangangasiwa ng isang intersight na kahilingan kapag ang isang magsasalakay ay nagtagumpay sa paggawa ng biktima na mag-click sa kanyang link at, kaya, upang bumuo ng isang kahilingan na hindi siya ay bubuo. Ang pagtitistis ng mga kahilingan sa cross-line ay kadalasang pinalambot sa token ng CSRF, na nauugnay sa session ng gumagamit. Tinutulungan nito ang application na suriin ang tao ng isang tao na nagpadala ng kahilingan. Ang parameter na "estado" sa protocol ng OAuth ay nagsisilbing Token ng CSRF.
Ito ay nagkakahalaga ng pagtingin kung paano isinasagawa ang pag-atake ng CSRF sa OAuth at bilang parameter na "Estado" ay maaaring magamit upang pagaanin ang mga epekto ng kahinaan.
Binubuksan ng Hacker ang isang web application at naglulunsad ng proseso ng awtorisasyon upang ma-access ang service provider gamit ang OAuth. Hinihiling ng application ang isang service provider upang ma-access ang mga kailangang ibigay. Ang Hacker ay i-redirect sa website ng service provider, kung saan karaniwan mong kailangang ipasok ang iyong username at password upang pahintulutan ang pag-access. Sa halip, ang hacker ay nakakakuha at pinipigilan ang kahilingang ito at ini-imbak ang URL nito. Ang Hacker sa paanuman ay nagiging sanhi ng biktima na buksan ang URL na ito. Kung ang biktima ay pumasok sa sistema ng service provider gamit ang account nito, pagkatapos ay ang mga kredensyal nito ay gagamitin upang mag-isyu ng isang code ng pahintulot. Ang code ng awtorisasyon ay nagpapalit ng access sa access token. Ngayon ang hacker account sa application ay pinahintulutan. Maaari itong ma-access ang account ng biktima.
Kaya, paano ko mapipigilan ang sitwasyong ito gamit ang "estado" na parameter?
Ang application ay dapat lumikha ng isang halaga na sa anumang paraan batay sa source account (halimbawa, gamitin ang user session hash key). Hindi mahalaga kung ano ito, ang pangunahing bagay ay ang halaga ay natatangi at nabuo gamit ang pribadong impormasyon tungkol sa orihinal na gumagamit. Ito ay itinalaga sa parameter na "estado".
Ang halaga na ito ay ipinapadala sa service provider kapag nagre-redirect. Ngayon ang hacker ay nag-aanyaya sa biktima upang buksan ang URL, na pinanatili niya.
Ang awtorisasyon code ay inisyu at ipinadala pabalik sa client sa session kasama ang "estado" parameter.
Ang kliyente ay bumubuo ng isang halaga ng parameter batay sa isang impormasyon ng session at inihambing ito sa "estado" na halaga, na ipinadala mula sa kahilingan ng awtorisasyon sa service provider. Ang halaga na ito ay hindi tumutugma sa parameter na "estado" sa query, dahil ito ay nabuo lamang batay sa impormasyon tungkol sa kasalukuyang sesyon. Bilang resulta, ang nakuha na halaga ay hindi tinatanggap ng sistema.
Iba pang mga kahinaan na nakita kapag ang pagpapatupad ng OAuth ay kinabibilangan ng kakayahang magsagawa ng XSS (cross-site scripting) gamit ang parameter na "Redirect_uri", ang OAuth Private Key setting (ang key ay maaaring makuha kapag ang paglabag sa code ng Awtorisasyon (kung kailan Ang code ng awtorisasyon ay maaaring magamit nang higit sa isang beses upang mag-isyu ng maramihang mga access token). Ang mga kahinaan na ito ay mas karaniwan kaysa sa mga inilarawan sa itaas, ngunit hindi ito nagiging mas mapanganib. Dapat malaman ng developer ang lahat ng kinakailangang mga kasanayan upang matiyak ang maaasahang operasyon ng web application nito.
Ang may-akda ng isinalin na artikulo: Simon Saliba.
Mahalaga! Ang impormasyon lamang para sa mga layunin ng akademiko. Mangyaring sumunod sa batas at huwag ilapat ang impormasyong ito para sa mga iligal na layunin.
Mas kawili-wiling materyal sa cisoclub.ru. Mag-subscribe sa amin: Facebook | VK | Twitter | Instagram | Telegram | Zen | Messenger | ICQ Bago | Youtube | Pulso.