See artikkel käsitleb tuntud OAUTH haavatavusi. Lugejad õpivad ka, kuidas rakendada turvalist ja turvalist luba veebirakenduses.
OAUTH on usaldusväärne protokoll, kuid selle turvalisuse tase sõltub suuresti veebiarendajate teadvusest loa rakendamisel. See muudab selle teema infoturbe spetsialistide jaoks äärmiselt oluliseks. Nad peavad pakkuma oma kasutajate kontode kõrgetasemelist kaitset. On aeg tutvuda tõhusate praktikutega, kes aitavad vähendada halva müügi ohtu OAUTH.
SissejuhatusOAUTH 2.0 protokolli kasutatakse praegu laialdaselt erinevates rakendustes. Kasutades seda, mugav kasutajaliides muutub kättesaadavaks, lihtsam autentimine ja luba võrreldes traditsiooniliste meetoditega sisenemiseks kasutajanimi ja parool. Nõuetekohase ja läbimõeldud rakendamisega on OAuth protokoll turvalisem kui traditsiooniline luba, kuna kasutajad ei pea jagama oma raamatupidamisandmeid kolmanda osapoole taotlusega konkreetse ressursi juurde pääsemiseks. Kasutajad eelistavad sageli sisse logida oma Google'i kontode, Facebooki või Linkedini abil uue konto loomise asemel iga kord, kui peate mõnele veebisaidile registreerima. Seega lihtsustab OAUTH protokoll meie elu oluliselt.
Üldiselt on populaarsed OAuth teenusepakkujad väga usaldusväärsed. Logi sisse Google'i või Facebooki kontoga inspireerib teatud turvatunnet ja see on õige. Protokolli katsetatakse hoolikalt eksperdid. Arendaja meeskonna poolt korrigeerib kõik kättesaadavad haavatavusi alati kiiresti. Siiski väärib märkimist, et täieliku ohutuse tunne võib olla vale.
OAUTH teenusepakkujad lahkusid rakenduste arendajad paljudel põhjustel oma programmide ohutuse kandmiseks. Tegelikult võib algselt kaitstud OAUTH-teenus selle paigaldamise protsessis valesti rakendatud, muutuda sissetungijate jaoks lihtsaks sihtmärgiks. Selline hõivatus toob kaasa kasutajate isikuandmete varguse.
Seejärel peaksite kaaluma kõige levinumaid haavatavusi kolmandate osapoolte rakendustes, mis rakendavad OAUTH protokolli oma kasutajatele lubama. Tuleb meeles pidada, et protokoll ise on ohutu ja usaldusväärne. Ainult pärast ebaõiget rakendamist muutub see häkkerite rünnakute suhtes haavatavaks.
Oauth Tockey varguse viidete päise abilKui taotluse taotleb luba kasutaja nimel OAUTH serveris, saab isik koodi sisestada ja saata serverisse tagasi oma hilisema kontrolli. Kui töö ajal kasutatakse kasutaja teisele lehele teisele lehele, vaadeldakse koodi HTTP-päringu "Viitar" päises. Seega langeb kood välisele veebisaidile, mis ohustab OAUTH serveril registreeritud kasutajaandmeid.
Märkus: Viide päise HTTP-päringu päis, see edastab URL-i vastuvõtva, kust taotlus saadetakse.
Selle haavatavuse tagajärgede pehmendamiseks peab arendaja veenduma, et selle veebirakendus ei sisalda HTML-i süstimist. Kui süstid tuvastati, saab ründaja pildi sildi hõlpsasti seadistada veebiserverisse ja leida viis kasutaja ümber suunamiseks. Seega saab ta võimaluse varastada HTTP-päringu "Viit" päisest.
Oauth Tockey varguse abil REDirect_uri parameetri abilTaotlus algatab autoriseerimise protsessi, saates OAUTH serverile taotluse:
https://www.example.com/signin/authorize? [&redirect_uri=httpps://demo.example.com/loginsuccessful.
Päring sisaldab alati "REDirect_uri" parameeter OAUTH server kasutab märkide saatmiseks tagasi taotlusele pärast seda, kui kasutaja andis oma nõusoleku. Kui selle parameetri väärtust ei kontrolli ega kontrollita, saab ründaja seda hõlpsasti muuta ja taotluse oma veebisaidile suunata, kus ta kasutab sümboli töötlemiseks spetsiaalset programmi ja pääseda juurdepääs piiratud ressursile.
https://www.example.com/signin/authorize? [&redirect_uri=Htttpps://localhost.evil.com.
Mõnikord on sarnased URL-id blokeeritud. Ründaja saab edastada vastuvõetud andmeid avatud URL-i kohta, nagu see:
https://www.example.com/oauth20_authorze.srf? )...[... (määrused
Või see:
https://www.example.com/oauth2/authorise? [...]% IRECT_URI = HTTPS% 3A% 2F% 2Fapps.facebook.com% 2Fatcker% 2f.
OAUTH rakendamisel saate kunagi valged domeenide hulka kuuluda valges nimekirjas. Ainult mõned URL-id tuleks lisada "ümbersuunamis_uri" ei suunata ümbersuunamise taotlust.
Piirangute võltsimineRikkumise taotluse võltsimine võib tekkida siis, kui ründaja õnnestub ohvri teha oma lingile klõpsamise ja seega, et luua taotlust, et ta ei kavatse luua. Piirangute võltsimine on tavaliselt pehmendatud CSRF-i sümboliga, mis on seotud kasutaja seansiga. See aitab taotluse kontrollida taotluse saatnud isiku isikut. "Riik" parameeter OAUTH protokollis on CSRF-i sümbol.
Tasub vaadata, kuidas CSRF rünnak toimub Oauthil ja kui "riik" parameetrit saab kasutada haavatavuse mõju leevendamiseks.
Hacker avab veebirakenduse ja käivitab autoriseerimisprotsessi OAUTH teenusepakkuja kasutamiseks. Taotluse taotleb teenusepakkuja juurdepääsu, mida tuleb esitada. Häkker suunatakse teenusepakkuja veebilehel, kus tavaliselt vajate juurdepääsu oma kasutajanime ja parooli, et lubada juurdepääsu. Selle asemel, häkker püüab ja takistab selle taotluse ja säästab oma URL-i. Hacker kuidagi põhjustab ohvri avada selle URL. Kui ohver sisenes teenusepakkuja süsteemi, kasutades oma kontot, siis selle volikirja kasutatakse loa andmise koodi väljastamiseks. Loa andmise kood vahetab juurdepääsu juurdepääsu märgist. Nüüd on rakenduses häkker konto lubatud. See pääseb ohvri kontole.
Niisiis, kuidas ma saan seda olukorda parandada "riigi" parameetri abil?
Taotlus peab looma väärtuse, mis on kuidagi põhineb allikakontol (näiteks kasutage kasutaja seansi hash-võtit). See ei ole nii oluline, mis see on, peamine asi on see, et väärtus on ainulaadne ja genereeritud privaatse teabe kasutamine algse kasutaja kohta. See on määratud "riigi" parameetrile.
See väärtus edastatakse teenusepakkujale suunamisel. Nüüd kutsub häkker ohver avama URL-i, mida ta säilitas.
Loa kood väljastatakse ja saadetakse tagasi kliendile istungil koos "riigi" parameetriga.
Klient genereerib parameetri väärtus, mis põhineb seansiteabe põhjal ja võrdleb seda "riigi" väärtusega, mis saadeti tagasi loataotlusest teenusepakkujale. See väärtus ei vasta "riigi" parameetrile päringus, kuna see on tekkinud ainult praeguse seansi kohta teabe põhjal. Selle tulemusena ei aktsepteeri süsteem saadud väärtust.
OAUTH rakendamisel tuvastatud haavatavuste hulka kuulub XSS-i teostamise võime (REDirect_uri "parameeter, OAUTH Private Key seadistuse abil Volitusjuhendi saab kasutada rohkem kui üks kord, et anda mitu juurdepääsu märgid). Need haavatavusi on vähem levinud kui eespool kirjeldatud, kuid see ei muuda neid vähem ohtlikuks. Arendaja peaks teadma kõiki vajalikke tavasid selle veebirakenduse usaldusväärse toimimise tagamiseks.
Tõlgitud artikli autor: Simon Saliba.
Oluline! Teavet üksnes akadeemilistel eesmärkidel. Palun järgige õigusakte ja ei kohalda seda teavet ebaseaduslike eesmärkide jaoks.
Huvitavamat materjali Cisoclub.ru. Telli US: Facebook | VK | Twitter | Instagram | Telegramm | Zen | Messenger | ICQ Uus | YouTube | Impulsi.