Vulnerabilities Oauth | Jinsi ya kutekeleza idhini salama katika programu yako ya wavuti.

Makala hii itashughulika na udhaifu unaojulikana wa OAuth. Wasomaji pia watajifunza jinsi ya kutekeleza idhini salama katika programu ya wavuti.

OAUTH ni itifaki ya kuaminika, lakini kiwango chake cha usalama kinategemea ufahamu wa watengenezaji wa wavuti wakati wa kutekeleza idhini. Hii inafanya mada hii kuwa muhimu sana kwa wataalamu wa usalama wa habari. Wanahitaji kutoa kiwango cha juu cha ulinzi wa akaunti za watumiaji wao. Ni wakati wa kufahamu watendaji bora ambao watasaidia kupunguza hatari ya kuuza maskini oauth.

Utangulizi

Oauth 2.0 Itifaki kwa sasa inatumiwa sana katika programu mbalimbali. Kutumia, interface rahisi ya mtumiaji inapatikana, uthibitishaji rahisi na idhini ikilinganishwa na mbinu za jadi za kuingia jina la mtumiaji na nenosiri. Kwa utekelezaji sahihi na wa kufikiri, itifaki ya OAuth itakuwa salama kuliko idhini ya jadi, kwa kuwa watumiaji hawana haja ya kushiriki data zao za uhasibu na programu ya tatu ili kufikia rasilimali maalum. Watumiaji mara nyingi wanapendelea kuingia kwenye akaunti zao za Google, Facebook au LinkedIn, badala ya kuunda akaunti mpya kila wakati unahitaji kujiandikisha kwenye tovuti fulani. Kwa hiyo, itifaki ya oauth inapunguza sana maisha yetu.

Kwa ujumla, watoa huduma maarufu wa OAuth wanaaminika sana. Ingia na akaunti ya Google au Facebook inahamasisha hisia fulani ya usalama, na ni sahihi. Itifaki inajaribiwa kwa makini na wataalam. Vurugu zote zilizopo zinatumiwa haraka na timu ya msanidi programu. Hata hivyo, ni muhimu kutambua kwamba hisia ya usalama kamili inaweza kuwa uongo.

Watoa huduma wa OAuth waliacha watengenezaji wa maombi mengi ya sababu ya kushindana na usalama wa programu zao. Kwa kweli, huduma ya Oauth iliyohifadhiwa awali, kutekelezwa kwa usahihi katika mchakato wa ufungaji wake, inaweza kuwa lengo rahisi kwa wahusika. Uwakilishi kama huo utaongoza wizi wa data binafsi ya watumiaji.

Kisha, unapaswa kuzingatia udhaifu wa kawaida uliopatikana katika maombi ya tatu ambayo yanatekeleza itifaki ya OAUTH ili kuidhinisha watumiaji wao. Ni lazima ikumbukwe kwamba itifaki yenyewe ni salama na ya kuaminika. Tu baada ya utekelezaji usio sahihi, inakuwa hatari kwa mashambulizi ya hacker.

Oauth Tockey wizi kwa kutumia kichwa cha referer.

Wakati maombi yanaomba idhini kwa niaba ya mtumiaji kwenye seva ya OAuth, mtu anapata msimbo wa kuingia na kurudi kwenye seva kwa hundi yake inayofuata. Ikiwa wakati wa kazi mtumiaji ataelekezwa kwenye ukurasa mwingine, msimbo utaonekana kwenye kichwa cha "Referer" cha ombi la HTTP. Hivyo, kanuni itaanguka kwenye tovuti ya nje, ambayo itatishia data ya mtumiaji iliyosajiliwa kwenye seva ya OAuth.

Kumbuka: kichwa cha referer ni kichwa cha swala la HTTP, hupeleka jeshi la URL ambalo ombi linatumwa.

Ili kupunguza matokeo ya hatari hii, msanidi programu lazima ahakikishe kwamba programu yake ya wavuti haina sindano yoyote ya HTML. Ikiwa sindano ziligunduliwa, mshambulizi anaweza kuweka alama ya picha kwa urahisi kwenye seva yake ya wavuti na kutafuta njia ya kuelekeza mtumiaji juu yake. Kwa hiyo, atapata nafasi ya kuiba kanuni kutoka kwa kichwa cha "referer" cha ombi la HTTP.

Oauth Tockey wizi kutumia parameter redirect_uri.

Maombi huanzisha mchakato wa idhini kwa kutuma ombi kwa seva ya OAuth:

https://www.example.com/signin/authorize? [[) ])Redirect_uri=httpps://demo.example.com/loginsuccesful.

Swali la daima lina parameter ya "redirect_uri" iliyotumiwa na seva ya OAuth ili kutuma ishara nyuma ya programu baada ya mtumiaji kutoa idhini yake. Ikiwa thamani ya parameter hii haijasimamiwa au haipatikani, mshambuliaji anaweza kubadilisha kwa urahisi na kuelekeza ombi kwenye tovuti yake, ambapo hutumia mpango maalum wa usindikaji Ishara na kupata rasilimali ndogo.

https://www.example.com/signin/authorize? [[)]&Redirect_uri=httpps://localhost.evil.com.

Wakati mwingine URL zinazofanana zimezuiwa. Mshambuliaji anaweza kuelekeza data iliyopokea kwenye URL ya wazi, kama hii:

https://www.example.com/oauth20_authorize.srf?

Au hii:

https://www.example.com/oauth2/authorize? [...]% Irect_uri = https% 3a% 2f% 2fapps.facebook.com% 2Fattacker% 2f.

Wakati wa kutekeleza OAuth, huwezi kamwe kuingiza domains nzima katika orodha nyeupe. URL chache tu zinapaswa kuongezwa kwa "redirect_uri" haijaelekezwa ombi la kufungua kuelekeza.

Upasuaji wa maombi ya mstari wa msalaba.

Upasuaji wa ombi la maingiliano huweza kutokea wakati mshambulizi anafanikiwa kufanya mhasiriwa kubonyeza kiungo chake na kwa hiyo, ili kuzalisha ombi ambalo hakuwa na kuzalisha. Ufafanuzi wa maombi ya mstari wa msalaba hupunguzwa na ishara ya CSRF, ambayo inahusishwa na kikao cha mtumiaji. Inasaidia maombi kuangalia mtu wa mtu aliyepeleka ombi hilo. Kipimo cha "hali" katika itifaki ya OAuth hutumika kama ishara ya CSRF.

Ni muhimu kutazama jinsi mashambulizi ya CSRF yanafanywa kwa OAuth na kama parameter ya "hali" inaweza kutumika kupunguza madhara ya hatari.

Hacker inafungua maombi ya wavuti na huzindua mchakato wa idhini ya kufikia mtoa huduma kwa kutumia OAuth. Programu ya maombi ya mtoa huduma ili kufikia mahitaji ya kutolewa. Hacker itaelekezwa kwenye tovuti ya mtoa huduma, ambapo kwa kawaida unahitaji kuingia jina lako la mtumiaji na nenosiri ili kuidhinisha upatikanaji. Badala yake, hacker huchukua na kuzuia ombi hili na huokoa URL yake. Hacker kwa namna fulani husababisha mwathirika kufungua URL hii. Ikiwa mwathirika aliingia mfumo wa mtoa huduma kwa kutumia akaunti yake, basi sifa zake zitatumika kutoa msimbo wa idhini. Msimbo wa idhini unabadilisha upatikanaji wa Ishara ya Access. Sasa akaunti ya hacker katika programu imeidhinishwa. Inaweza kufikia akaunti ya mwathirika.

Kwa hiyo, ninawezaje kuzuia hali hii kwa kutumia parameter ya "hali"?

Programu inapaswa kuunda thamani ambayo kwa namna fulani inategemea akaunti ya chanzo (kwa mfano, tumia somo la mtumiaji hashi). Sio muhimu sana ni nini, jambo kuu ni kwamba thamani ni ya kipekee na imezalishwa kwa kutumia maelezo ya kibinafsi kuhusu mtumiaji wa awali. Ni kwa ajili ya parameter ya "hali".

Thamani hii inaambukizwa kwa mtoa huduma wakati unapoelekeza. Sasa hacker anakaribisha mwathirika kufungua URL, ambayo aliendelea.

Msimbo wa idhini hutolewa na kurejeshwa kwa mteja katika kikao pamoja na parameter ya "hali".

Mteja huzalisha thamani ya parameter kulingana na maelezo ya kikao na kulinganisha na thamani ya "hali", ambayo ilirejeshwa kutoka kwa ombi la idhini kwa mtoa huduma. Thamani hii hailingani na parameter ya "hali" katika swala, kwani imezalishwa tu kwa misingi ya habari kuhusu kikao cha sasa. Matokeo yake, thamani ya kupatikana haikubaliki na mfumo.

Uharibifu mwingine unaona wakati utekelezaji wa OAuth ni pamoja na uwezo wa kufanya XSS (scripting ya tovuti ya msalaba) kwa kutumia parameter ya "redirect_uri", mipangilio ya ufunguo wa OAuth (ufunguo wakati mwingine unaweza kupatikana wakati wa kufuta maombi ya simu) na ukiukwaji wa kanuni ya idhini (wakati Nambari ya idhini inaweza kutumika zaidi ya mara moja kutoa ishara nyingi za kufikia). Uvunjaji huu ni wa kawaida kuliko wale walioelezwa hapo juu, lakini haiwafanya kuwa hatari zaidi. Msanidi programu anapaswa kujua mazoea yote muhimu ili kuhakikisha uendeshaji wa kuaminika wa programu yake ya wavuti.

Mwandishi wa makala iliyotafsiriwa: Simon Saliba.

Muhimu! Habari tu kwa madhumuni ya kitaaluma. Tafadhali kuzingatia sheria na usitumie habari hii kwa madhumuni haramu.

Vifaa vya kuvutia zaidi kwenye cisoclub.ru. Kujiunga na sisi: Facebook | Vk | Twitter | Instagram | Telegram | Zen | Mtume | ICQ Mpya | YouTube | Pulse.