Veikleikar OAUTH | Hvernig á að innleiða örugga heimild í vefforritinu þínu

Þessi grein mun fjalla um vel þekkt OAUK veikleika. Lesendur munu einnig læra hvernig á að framkvæma öruggt og öruggt leyfi í vefforritinu.

Oauth er áreiðanlegt siðareglur, en öryggi þess veltur að miklu leyti á vitund vefur verktaki þegar framkvæmdar heimild. Þetta gerir þetta efni mjög mikilvægt fyrir fagfólk upplýsinga. Þeir þurfa að veita mikla vernd reikninga notenda sinna. Það er kominn tími til að kynnast skilvirkum sérfræðingum sem hjálpa til við að draga úr hættu á fátækum að selja Oauth.

Kynning

Oauth 2.0 samskiptareglur eru nú mikið notaðar í ýmsum forritum. Notkun þess verður þægileg notendaviðmót tiltæk, auðveldari staðfesting og heimild miðað við hefðbundnar aðferðir til að slá inn notandanafnið og lykilorðið. Með rétta og hugsi framkvæmd, mun OAuth siðareglur vera öruggari en hefðbundin leyfi, þar sem notendur þurfa ekki að deila bókhaldsgögnum sínum með forriti þriðja aðila til að fá aðgang að tilteknu auðlindum. Notendur vilja oft að skrá þig inn með Google reikningum sínum, Facebook eða LinkedIn, í stað þess að búa til nýjan reikning í hvert skipti sem þú þarft að skrá þig á vefsíðu. Þannig einfaldar Oauth Protocol mjög líf okkar.

Almennt eru vinsælar OAuth þjónustuveitendur mjög áreiðanlegar. Skráðu þig inn með Google eða Facebook reikning hvetur til ákveðins öryggisskynjunnar og það er rétt. Bókunin er vandlega prófuð af sérfræðingum. Allar lausar veikleikar eru alltaf fljótt leiðréttar af verktaki liðinu. Hins vegar er það athyglisvert að tilfinningin um fullkomið öryggi getur verið rangt.

Oauth Service Providers vinstri umsókn verktaki mikið af ástæðum til að berjast gegn öryggi áætlana sinna. Í raun er upphaflega verndað OAuth Service, rangt útfært í því ferli uppsetningar þess, getur orðið auðvelt markmið fyrir boðflenna. Slík frumsýnd mun leiða til þjófnaðar persónuupplýsinga notenda.

Næst ættir þú að íhuga algengustu veikleikana sem upp koma í forritum þriðja aðila sem framkvæma OAuth siðareglur til að heimila notendum sínum. Það verður að hafa í huga að siðareglurnar sjálft er örugg og áreiðanleg. Aðeins eftir rangar framkvæmdir verður það viðkvæm fyrir árásum á tölvusnápur.

Oauth Tockey Theft með því að nota tilvísunarhausinn

Þegar umsóknin óskar eftir leyfi fyrir hönd notandans á OAuth-miðlara fær maður kóðann til að slá inn og senda aftur á þjóninn fyrir síðari stöðva. Ef á vinnunni verður notandinn vísað til annars síðu, mun kóðinn sjást í "Tilvísun" haus HTTP beiðni. Þannig mun kóðinn falla á ytri vefsíðu, sem mun ógna notandagögnum sem skráð eru á Oauth Server.

Athugaðu: Tilvísunarhausinn er http fyrirspurnarhaus, það sendir vefslóðina sem beiðnin er send.

Til að mýkja afleiðingar þessa varnarleysi verður verktaki að ganga úr skugga um að vefforritið innihaldi ekki HTML inndælingu. Ef inndælingarnar fundust, getur árásarmaðurinn auðveldlega stillt myndmerkið á vefþjóninn og fundið leið til að beina notandanum á það. Þannig mun hann fá tækifæri til að stela kóðanum frá "Tilvísun" haus HTTP beiðni.

OAUTH TOCKEY þjófnaður með því að nota redirect_uri breytu

Umsóknin hefst heimildarferlið með því að senda beiðni til OAuth Server:

https://www.example.com/signin/authorize ?....&redirect_uri=httpps: //Demo.example.com/loginsuccessful.

Fyrirspurnin inniheldur alltaf "redirect_uri" breytu sem OAuth Server er notað til að senda tákn aftur í forritið eftir að notandinn gaf samþykki sitt. Ef gildi þessarar breytu er ekki stjórnað eða ekki skoðuð getur árásarmaðurinn auðveldlega breytt því og beina beiðninni á heimasíðu sinni, þar sem það notar sérstakt forrit til að vinna úr takkanum og fá aðgang að takmörkuðu auðlindum.

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

Stundum eru svipaðar vefslóðir læstir. Árásarmaðurinn getur beitt mótteknum gögnum á opnum vefslóðinni, svona:

https://www.example.com/oauth20_authorize.sRF? *...

Eða þetta:

https://www.example.com/ouhuth2/authorize? [...]% irect_uri = https% 3A% 2f% 2fapps.facebook.com% 2fattacker% 2f.

Þegar þú framkvæmir OAUTH geturðu aldrei falið í sér heil lén á hvítum listanum. Aðeins nokkrar vefslóðir ættu að bæta við "Redirect_URi" ekki beint beiðni um að opna tilvísunina.

Fölsun um beiðnir um kross-línu

Fölsun í beiðni um atkvæði getur komið fram þegar árásarmaður tekst að gera fórnarlambið að smella á tengilinn hans og þannig að búa til beiðni um að hann væri ekki að fara að búa til. Fölsun á beiðnum um krossferð er venjulega mildaður með CSRF tákninu, sem tengist notendahópnum. Það hjálpar forritinu að athuga manninn sem sendi beiðnina. The "ástand" breytu í Oauth siðareglur þjónar sem CSRF tákn.

Það er þess virði að skoða hvernig CSRF árásin er framkvæmd á Oauth og eins og "ástand" breytu er hægt að nota til að draga úr áhrifum varnarleysi.

Hacker opnar vefforrit og kynnir heimildarferlið til að fá aðgang að þjónustuveitunni með Oauth. Forritið óskar eftir þjónustuveitanda að fá aðgang að því þarf að veita. Hacker verður vísað til þjónustuveitunnar, þar sem þú þarft venjulega að slá inn notandanafnið þitt og lykilorð til að heimila aðgang. Þess í stað veiðir tölvusnápur og kemur í veg fyrir þessa beiðni og sparar vefslóðina. Hacker veldur einhvern veginn fórnarlambið að opna þessa vefslóð. Ef fórnarlambið kom inn í kerfið þjónustuveitunnar með því að nota reikninginn sinn, þá verður persónuskilríki þess notað til að gefa út heimildarkóða. Leyfisnúmerið skiptast á aðgangsmanninum. Nú er tölvusnápur reikningurinn í umsókn heimilað. Það getur fengið aðgang að reikningi fórnarlambsins.

Svo, hvernig get ég komið í veg fyrir þetta ástand með því að nota "ástand" breytu?

Umsóknin verður að skapa gildi sem er einhvern veginn byggt á uppruna reikningnum (til dæmis, notaðu notendahópinn Hash lykillinn). Það er ekki svo mikilvægt hvað það er, aðalatriðið er að verðmæti er einstakt og myndað með því að nota einkaupplýsingar um upphaflega notandann. Það er úthlutað til "ástand" breytu.

Þetta gildi er send til þjónustuveitunnar þegar beina. Nú býður tölvusnápur fórnarlambið að opna slóðina, sem hann hélt.

Leyfisnúmerið er gefið út og send til viðskiptavinarins á fundinum ásamt "ástand" breytu.

Viðskiptavinurinn býr til breytuverðmæti á grundvelli fundarupplýsinga og samanstendur af því með "ástand" gildi, sem var sent frá heimildarbeiðni til þjónustuveitunnar. Þetta gildi passar ekki við "ástand" breytu í fyrirspurninni, þar sem það hefur verið myndað aðeins á grundvelli upplýsinga um núverandi fundi. Þar af leiðandi er það ekki samþykkt af kerfinu.

Önnur veikleikar fundust þegar framkvæmd OAuth felur í sér hæfni til að framkvæma XSS (Scripting Cross-Site) með því að nota "endurvísun Leyfisnúmerið er hægt að nota meira en einu sinni til að gefa út marga aðgangsmerki). Þessar veikleikar eru sjaldgæfar en þær sem lýst er hér að ofan, en það gerir þeim ekki minna hættulegt. Framkvæmdaraðili ætti að vita allar nauðsynlegar venjur til að tryggja áreiðanlega rekstur vefforritsins.

Höfundur þýddar greinar: Simon Saliba.

Mikilvægt! Upplýsingar eingöngu til fræðilegra nota. Vinsamlegast uppfylla löggjöf og ekki beita þessum upplýsingum til ólöglegra nota.

Meira áhugavert efni á cisoclub.ru. Gerast áskrifandi að okkur: Facebook | VK | Twitter | Instagram | Telegram | Zen | Messenger | ICQ NEW | YouTube | Púls.