Ta članek se bo ukvarjal z znanimi ranljivostjo Oauth. Bralci se bodo prav tako naučili, kako izvajati varno in varno dovoljenje v spletni aplikaciji.
OAUTH je zanesljiv protokol, vendar je njegova stopnja varnosti v veliki meri odvisna od zavedanja spletnih razvijalcev pri izvajanju dovoljenja. Zaradi tega je to tema izjemno pomembna za strokovnjake za varnost informacij. Zagotoviti morajo visoko stopnjo zaščite računov svojih uporabnikov. Čas je, da se seznanite z učinkovitimi strokovnjaki, ki bodo pomagali zmanjšati nevarnost slabe prodaje Oauth.
UvodProtokol OAUTH 2.0 se trenutno uporablja v različnih aplikacijah. Uporaba ga je na voljo priročen uporabniški vmesnik, lažje preverjanje pristnosti in dovoljenje v primerjavi s tradicionalnimi metodami za vnos uporabniškega imena in gesla. Z ustrezno in premišljeno izvajanje bo protokol Oauth varnejši od tradicionalnega dovoljenja, saj uporabniki ni treba deliti svojih računovodskih podatkov s prijavo tretje osebe za dostop do določenega vira. Uporabniki se pogosto prijavijo z uporabo svojih Google Računi, Facebook ali LinkedIn, namesto da bi ustvarili nov račun vsakič, ko se morate registrirati na določenem spletnem mestu. Tako Oauth Protocol močno poenostavlja naša življenja.
Na splošno so priljubljeni ponudniki storitev OAUTH zelo zanesljivi. Prijavite se z Google ali Facebook računom navdihuje določen občutek varnosti, in je pravilen. Protokol skrbno preizkušajo strokovnjaki. Vse razpoložljive ranljivosti so vedno hitro popravljene s skupino za razvijalce. Vendar pa je vredno omeniti, da je občutek popolne varnosti lahko napačen.
Ponudniki storitev OAUTH so zapustili razvijalce aplikacij, veliko razlogov, da bi trdili varnost svojih programov. Pravzaprav lahko prvotno zaščitena služba Oauth, nepravilno izvedena v postopku njene namestitve, postala enostavna tarča za vsiljivce. Takšna preokupina bo privedla do kraje osebnih podatkov uporabnikov.
Nato morate upoštevati najpogostejše ranljivosti, ki se pojavljajo v aplikacijah tretjih oseb, ki izvajajo protokol OAUTH, da dovolijo svoje uporabnike. Ne smemo pozabiti, da je protokol sam varen in zanesljiv. Šele po napačnem izvajanju postane ranljiva za napade hekerjev.
Oauth Tockey Kraja s pomočjo glave referenceKo aplikacija zahteva dovoljenje v imenu uporabnika na strežniku OAUTH, oseba prejme kodo, da vnese in pošlje nazaj na strežnik za njen naknadni ček. Če bo med delom uporabnik preusmerjen na drugo stran, bo koda vidna v glavi "Reference" na zahtevo HTTP. Zato bo koda padla na zunanje spletne strani, ki bo ogrozila uporabniške podatke, registrirane na strežniku OAUTH.
Opomba: Glava Reference je glava poizvedbe HTTP, prenaša gostitelj URL, iz katerega je bila poslana zahteva.
Za mehčanje posledic te ranljivosti mora razvijalec zagotoviti, da njegova spletna aplikacija ne vsebuje injekcij HTML. Če je bilo zaznavanje injekcij, lahko napadalec preprosto nastavi sliko slikovnemu strežniku in poišče način preusmeritve uporabnika nanj. Tako bo dobil priložnost, da ukrade kodo iz glave "Reference" na zahtevo HTTP.
Oauth Tockey Kraja s parametrom Redirect_URIAplikacija sproži postopek avtorizacije s pošiljanjem zahteve na strežnik OAuth:
https://www.example.com/signn/authorize ?[...]&/demo.example.com/LogiNeclucceful.
Poizvedba vedno vsebuje parameter "REDIRECT_URI", ki ga uporablja OAUTH strežnik za pošiljanje žetonov nazaj na aplikacijo, potem ko je uporabnik dal soglasje. Če vrednost tega parametra ni nadzorovana ali ni preverjena, ga napadalca lahko enostavno spremeni in preusmerite zahtevo na njegovo spletno stran, kjer uporablja poseben program za obdelavo žetona in dostop do omejenega vira.
https://www.example.com/signn/authorize?[...]&drarect_uri=https://localhost.evil.com.
Včasih so podobni URL-ji blokirani. Napadalec lahko preusmeri prejete podatke na odprt URL, kot je ta:
https://www.example.com/oauth20_Authorize.srf?[&Reredirect_uri=Https://accounts.google.com/backtouthsubtarget?Next=HTTPET://evil.com.
Ali to:
https://www.example.com/oauth2/authorize? [...]% irect_uri = https% 3a% 2f% 2fapps.facebook.com% 2Fattecker% 2f.
Pri izvajanju Oauth, nikoli ne morete vključiti celotnih domen na belem seznamu. Samo nekaj URL-jev je treba dodati na "Redirect_uri", ki ni preusmerjen zahtevek za odprtje preusmeritve.
Ponarejanje prostih prošenjPoenotenje zahteve za kris se lahko pojavi, ko napadalec uspe narediti žrtev, da klikne na svojo povezavo in tako ustvari zahtevo, da ne bo ustvaril. Ponarejanje medsebojnih zahtev je običajno mehčano z žetonom CSRF, ki je povezana z uporabniško sejo. Pomaga pri prijavi, da preveri osebo osebe, ki je poslala zahtevo. Parameter »State« v protokolu OAUTH služi kot žeton CSRF.
Oglejte si, kako se napadu CSRF izvaja na OAUTH in ker se lahko "državni" parameter uporabi za ublažitev učinkov ranljivosti.
Hacker odpre spletno aplikacijo in sproži postopek avtorizacije za dostop do ponudnika storitev z uporabo Oauth. Aplikacija zahteva, da ponudnik storitev dostopa do tega, da je treba zagotoviti. Hacker bo preusmerjen na spletno stran ponudnika storitev, kjer morate običajno vnesti svoje uporabniško ime in geslo, da odobri dostop. Namesto tega heker ujame in preprečuje to zahtevo in prihrani URL. Hacker nekako povzroča žrtev, da odpre ta URL. Če je žrtev vpisala sistem ponudnika storitev, ki uporablja svoj račun, se bodo njene poverilnice uporabile za izdajo dovoljenja. Navorna koda izmenjuje dostop do žetona za dostop. Zdaj je dovoljen račun hekerja v aplikaciji. Dostop do žrtve.
Torej, kako lahko preprečim to situacijo z uporabo parametra "države"?
Aplikacija mora ustvariti vrednost, ki je nekako na podlagi izvora računa (na primer, uporabite tipko za zasedanje uporabnika). Ni tako pomembno, kaj je, glavna stvar je, da je vrednost edinstvena in ustvarjena z uporabo zasebnih informacij o izvirnem uporabniku. Dodeljen je parameter "State".
Pri preusmeritvi se ta vrednost posreduje ponudniku storitev. Zdaj heker vabi žrtev, da odpre URL, ki ga je ohranil.
Avtorizacijska koda se izda in pošlje stranki na sejo skupaj z "državnim" parametrom.
Stranka ustvari vrednost parametra na podlagi informacij o seji in jo primerja z vrednostjo "države", ki je bila poslana nazaj iz zahteve za avtorizacijo na ponudnika storitev. Ta vrednost se v poizvedbi ne ujema s parametrom "stanja", saj je bila ustvarjena le na podlagi informacij o trenutni seji. Posledično s sistemom ne sprejme dobljene vrednosti.
Druge ranljivosti, ki so bile ugotovljene pri izvajanju Oauth, vključujejo možnost izvedbe XSS (skriptiranje navzkrižnega kraja) z uporabo parametra "Redirect_uri", nastavitev zasebnega ključa OAuth (tipka lahko včasih dobimo pri razgradnji mobilne aplikacije) in kršitev pravila o pooblastitvi kode (Kdaj Koda dovoljenja se lahko uporablja več kot enkrat za izdajo večkratnih žetonov dostopa). Te ranljivosti so manj pogoste od zgoraj opisanih zgoraj, vendar jih ne pomeni manj nevarnih. Razvijalec mora poznati vse potrebne prakse, da se zagotovi zanesljivo delovanje svoje spletne aplikacije.
Avtor prevedenega članka: Simon Saliba.
POMEMBNO! Informacije izključno za akademske namene. Upoštevajte zakonodajo in ne uporabljajte teh informacij za nezakonite namene.
Bolj zanimivo gradivo na Cisoclub.ru. Naročite se na nas: Facebook | VK | Twitter | Instagram | Telegram | Zen | Messenger | ICQ novo | YouTube | Pulse.