Gwendidau oauth | Sut i weithredu awdurdodiad diogel yn eich cais ar y we

Bydd yr erthygl hon yn delio â'r gwendidau wydr adnabyddus. Bydd darllenwyr hefyd yn dysgu sut i weithredu awdurdodiad diogel yn y cais ar y we.

Mae OAuth yn brotocol dibynadwy, ond mae ei lefel o ddiogelwch yn dibynnu i raddau helaeth ar ymwybyddiaeth datblygwyr gwe wrth weithredu awdurdodiad. Mae hyn yn gwneud y pwnc hwn yn hynod o bwysig i weithwyr proffesiynol diogelwch gwybodaeth. Mae angen iddynt ddarparu lefel uchel o ddiogelwch cyfrifon eu defnyddwyr. Mae'n bryd dod yn gyfarwydd ag ymarferwyr effeithiol a fydd yn helpu i leihau'r perygl o werthu gwael.

Chyflwyniad

Mae Protocol Oauth 2.0 yn cael ei ddefnyddio'n eang ar hyn o bryd mewn gwahanol gymwysiadau. Gan ddefnyddio TG, mae rhyngwyneb defnyddiwr cyfleus yn dod ar gael, yn haws dilysu ac awdurdodi o'i gymharu â dulliau traddodiadol ar gyfer mynd i mewn i'r enw defnyddiwr a chyfrinair. Gyda gweithrediad priodol a meddylgar, bydd y protocol OAuth yn fwy diogel nag awdurdodiad traddodiadol, gan nad oes angen i ddefnyddwyr rannu eu data cyfrifyddu gyda chais trydydd parti i gael gafael ar adnodd penodol. Yn aml mae'n well gan ddefnyddwyr fewngofnodi gan ddefnyddio eu cyfrifon Google, Facebook neu LinkedIn, yn hytrach na chreu cyfrif newydd bob tro y bydd angen i chi gofrestru ar rai gwefan. Felly, mae'r protocol oauth yn symleiddio ein bywydau yn fawr.

Yn gyffredinol, mae darparwyr gwasanaeth poblogaidd poblogaidd yn ddibynadwy iawn. Mewngofnodi gyda Google neu Facebook Account yn ysbrydoli ymdeimlad penodol o ddiogelwch, ac mae'n gywir. Caiff y protocol ei brofi'n ofalus gan arbenigwyr. Mae'r holl wendidau sydd ar gael bob amser yn cael eu cywiro'n gyflym gan dîm y datblygwr. Fodd bynnag, mae'n werth nodi y gall y teimlad o ddiogelwch llwyr fod yn ffug.

Darparwyr Gwasanaeth OAuth Gadawodd datblygwyr ymgeisio lawer o resymau i ddadlau diogelwch eu rhaglenni. Yn wir, mae'r gwasanaeth OAuth a warchodir i ddechrau, a weithredwyd yn anghywir yn y broses o'i osod, yn dod yn darged hawdd i dresbaswyr. Bydd gweithrediad o'r fath yn arwain at ddwyn data personol defnyddwyr.

Nesaf, dylech ystyried y gwendidau mwyaf cyffredin a welir mewn ceisiadau trydydd parti sy'n gweithredu Protocol OAuth i awdurdodi eu defnyddwyr. Rhaid cofio bod y Protocol ei hun yn ddiogel ac yn ddibynadwy. Dim ond ar ôl gweithredu anghywir, daw'n agored i ymosodiadau haciwr.

Dwyn Oauth Tockey gan ddefnyddio'r Pennawd Cyfeiriwr

Pan fydd y cais yn gofyn am awdurdodiad ar ran y defnyddiwr yn y gweinydd OAuth, mae person yn derbyn y cod i fynd i mewn ac yn anfon yn ôl at y gweinydd ar gyfer ei wiriad dilynol. Os yn ystod y gwaith, bydd y defnyddiwr yn cael ei ailgyfeirio i dudalen arall, bydd y cod yn cael ei weld yn y "fforter" pennawd y cais HTTP. Felly, bydd y cod yn disgyn ar y wefan allanol, a fydd yn bygwth y data defnyddwyr a gofrestrwyd ar y gweinydd OAuth.

Sylwer: Mae'r pennawd cyfeirwyr yn header http ymholiad, mae'n trosglwyddo'r gwesteiwr URL y mae'r cais yn cael ei anfon ohono.

Er mwyn meddalu canlyniadau'r bregusrwydd hwn, rhaid i'r datblygwr sicrhau nad yw ei gais ar y we yn cynnwys unrhyw bigiadau HTML. Os canfuwyd y pigiadau, gall yr ymosodwr osod tag delwedd yn hawdd i'w weinydd gwe a dod o hyd i ffordd o ailgyfeirio'r defnyddiwr arno. Felly, bydd yn cael y cyfle i ddwyn y cod gan y "rhwyllwyr" pennawd cais HTTP.

Dwyn Oauth Tockey gan ddefnyddio'r paramedr Redirect_uri

Mae'r cais yn cychwyn y broses awdurdodi trwy anfon cais at y gweinydd OAuth:

https://www.example.com/signin/authorize?...ent&redirect_uri=httppsks://demo.example.com/logaustuccessful.

Mae'r ymholiad bob amser yn cynnwys y paramedr "Redirect_uri" a ddefnyddir gan y gweinydd Oauth i anfon tocynnau yn ôl i'r cais ar ôl i'r defnyddiwr roi ei ganiatâd. Os na chaiff gwerth y paramedr hwn ei reoli neu heb ei wirio, gall yr ymosodwr ei newid yn hawdd ac ailgyfeirio'r cais i'w wefan, lle mae'n defnyddio rhaglen arbennig ar gyfer prosesu'r tocyn a chael mynediad i adnodd cyfyngedig.

https://www.example.com/signin/authorize? \ t

Weithiau mae URLau tebyg yn cael eu blocio. Gall yr ymosodwr ailgyfeirio'r data a dderbyniwyd ar yr URL agored, fel hyn:

https://www.example.com/oauth20_authorize.srf? z.....suri=httpps://acounts.google.com/backtogoushsubtarget?next=httpet ://evil.com.

Neu hyn:

https://www.example.com/oAutth2/authorize? [...]% i retrect_uri = https% 3a% 2f% 2fapps.facebook.com% 2fattacker% 2f.

Wrth weithredu OAuth, ni allwch byth gynnwys parthau cyfan yn y rhestr wen. Dim ond ychydig o URLs y dylid eu hychwanegu at "Redirect_uri" heb eu hailgyfeirio cais i agor ailgyfeirio.

Ffugio ceisiadau traws-lein

Gall ffugio cais Intersight ddigwydd pan fydd ymosodwr yn llwyddo i wneud y dioddefwr i glicio ar ei ddolen ac, felly, i gynhyrchu cais nad oedd yn mynd i gynhyrchu. Fel arfer, mae ffugio ceisiadau traws-lein yn cael ei feddalu gyda'r tocyn CSRF, sy'n gysylltiedig â'r sesiwn defnyddiwr. Mae'n helpu'r cais i wirio person person a anfonodd y cais. Mae'r paramedr "wladwriaeth" yn y protocol oauth yn gwasanaethu fel tocyn CSRF.

Mae'n werth edrych ar sut mae'r ymosodiad CSRF yn cael ei wneud ar OAuth ac fel y gall y paramedr "wladwriaeth" yn cael ei ddefnyddio i liniaru effeithiau bregusrwydd.

Haciwr yn agor cais ar y we ac yn lansio'r broses awdurdodi i gael mynediad i'r darparwr gwasanaeth gan ddefnyddio OAuth. Mae'r cais yn gofyn i ddarparwr gwasanaeth gael mynediad i hynny. Bydd Haciwr yn cael ei ailgyfeirio i wefan Darparwyr Gwasanaeth, lle mae angen i chi nodi eich enw defnyddiwr a'ch cyfrinair i awdurdodi mynediad. Yn lle hynny, mae'r Hacker yn dal ac yn atal y cais hwn ac yn arbed ei URL. Mae Hacker rywsut yn achosi i'r dioddefwr agor yr URL hwn. Pe bai'r dioddefwr yn mynd i mewn i system y darparwr gwasanaeth gan ddefnyddio ei gyfrif, yna defnyddir ei gymwysterau i gyhoeddi cod awdurdodi. Mae'r cod awdurdodi yn cyfnewid mynediad at y tocyn mynediad. Nawr bod y cyfrif haciwr yn y cais wedi'i awdurdodi. Gall gael mynediad i gyfrif y dioddefwr.

Felly, sut y gallaf atal y sefyllfa hon gan ddefnyddio'r paramedr "Wladwriaeth"?

Rhaid i'r cais greu gwerth sydd rywsut yn seiliedig ar y cyfrif ffynhonnell (er enghraifft, defnyddiwch Allwedd Hash Sesiwn Defnyddiwr). Nid yw mor bwysig beth ydyw, y prif beth yw bod y gwerth yn unigryw ac yn cael ei gynhyrchu gan ddefnyddio gwybodaeth breifat am y defnyddiwr gwreiddiol. Caiff ei neilltuo i'r paramedr "Wladwriaeth".

Mae'r gwerth hwn yn cael ei drosglwyddo i'r darparwr gwasanaeth wrth ailgyfeirio. Nawr mae'r haciwr yn gwahodd y dioddefwr i agor yr URL, a gadawodd.

Cyhoeddir y Cod Awdurdodi a'i anfon yn ôl i'r cleient yn y sesiwn ynghyd â'r paramedr "Wladwriaeth".

Mae'r cleient yn cynhyrchu gwerth paramedr yn seiliedig ar wybodaeth am sesiwn ac yn ei chymharu â'r gwerth "wladwriaeth", a anfonwyd yn ôl o'r cais awdurdodi i'r darparwr gwasanaeth. Nid yw'r gwerth hwn yn cyfateb i'r paramedr "wladwriaeth" yn yr ymholiad, gan ei fod wedi cael ei gynhyrchu ar sail gwybodaeth am y sesiwn gyfredol yn unig. O ganlyniad, ni dderbynnir y gwerth a gafwyd gan y system.

Mae gwendidau eraill a ganfuwyd wrth weithredu OAuth yn cynnwys y gallu i berfformio XSS (sgriptio traws-safle) gan ddefnyddio'r paramedr "Redirect_uri", y gosodiad Allwedd Preifat OAuth (gellir cael yr allwedd weithiau wrth ddadgomisiynu cais symudol) a Throsglwyddo Cod Awdurdodi (pryd Gellir defnyddio'r Cod Awdurdodi fwy nag unwaith i gyhoeddi tocynnau mynediad lluosog). Mae'r gwendidau hyn yn llai cyffredin na'r rhai a ddisgrifir uchod, ond nid yw'n eu gwneud yn llai peryglus. Dylai'r datblygwr wybod yr holl arferion angenrheidiol i sicrhau gweithrediad dibynadwy o'i gymhwysiad ar y we.

Awdur yr erthygl wedi'i chyfieithu: Simon Saliba.

PWYSIG! At ddibenion academaidd yn unig. Os gwelwch yn dda yn cydymffurfio â deddfwriaeth ac nid ydynt yn cymhwyso'r wybodaeth hon at ddibenion anghyfreithlon.

Gwendidau oauth | Sut i weithredu awdurdodiad diogel yn eich cais ar y we

Darllen mwy