Šis straipsnis bus susijęs su gerai žinomais oauth pažeidžiamumu. Skaitytojai taip pat sužinos, kaip įgyvendinti saugų ir saugų leidimą interneto paraiškoje.
OAuth yra patikimas protokolas, tačiau jo saugumo laipsnis daugiausia priklauso nuo žiniatinklio kūrėjų informuotumo įgyvendinant leidimą. Tai daro šią temą labai svarbi informacijos saugumo specialistams. Jie turi pateikti aukštą jų naudotojų sąskaitų apsaugos lygį. Atėjo laikas susipažinti su veiksmingais praktikais, kurie padės sumažinti blogo pardavimo oauth pavojų.
ĮVADAS. \ T"OAuth 2.0" protokolas šiuo metu plačiai naudojamas įvairiose programose. Naudojant jį, patogi vartotojo sąsaja tampa prieinama, lengviau autentifikavimo ir leidimo, palyginti su tradiciniais metodais įvesti vartotojo vardą ir slaptažodį. Su tinkamu ir įmanomu įgyvendinimu, OAuth protokolas bus saugesnis už tradicinį leidimą, nes vartotojai neturi pasidalinti savo apskaitos duomenimis su trečiosios šalies prašymu gauti konkrečią šaltinį. Vartotojai dažnai nori prisijungti naudodami savo "Google" paskyras, "Facebook" ar "LinkedIn", o ne kiekvieną kartą, kai reikia užsiregistruoti kai kuriose svetainėje, kur nors reikia užsiregistruoti. Taigi OAuth protokolas labai supaprastina mūsų gyvenimą.
Apskritai, populiarūs OAuth paslaugų teikėjai yra labai patikimi. Prisijunkite naudodami "Google" arba "Facebook" paskyrą įkvepia tam tikrą saugumo jausmą, ir tai yra teisinga. Protokolui kruopščiai išbando ekspertai. Visiems prieinamiems pažeidžiamumams visada greitai koreguoja kūrėjo komanda. Tačiau verta pažymėti, kad visiško saugumo jausmas gali būti klaidingas.
OAuth Paslaugų teikėjai išvyko iš paraiškų kūrėjams daug priežasčių, dėl kurios susidaro jų programų saugumas. Tiesą sakant, iš pradžių apsaugota OAuth paslauga, neteisingai įgyvendinta jo įrengimo procese, gali tapti paprastu tikslu įsibrovėliams. Toks rūpestis paskatins naudotojų asmens duomenų vagystę.
Be to, turėtumėte apsvarstyti dažniausiai pasitaikančius trečiųjų šalių programų pažeidžiamumus, įgyvendinančius OAUT protokolą, kad būtų galima leisti naudotojams. Reikia prisiminti, kad pats protokolas yra saugus ir patikimas. Tik po neteisingo įgyvendinimo jis tampa pažeidžiamas įsilaužėlių atakoms.
Oauth tockey vagystė naudojant referento antraštęKai paraiška prašo leidimo naudotojo vardu "Oauth Server" vardu, asmuo gauna kodą, kad įvestų ir atsiųstų į serverį savo vėlesniam patikrinimui. Jei darbo metu vartotojas bus nukreiptas į kitą puslapį, kodas bus vertinamas į HTTP užklausos "referencinį" antraštę. Taigi kodas patenka į išorinę svetainę, kuri kelia grėsmę OAUTH serveryje registruotu naudotojo duomenis.
Pastaba: referencinis antraštė yra HTTP užklausos antraštė, ji perduoda URL kompiuterį, iš kurio siunčiamas prašymas.
Siekiant sušvelninti šio pažeidžiamumo pasekmes, kūrėjas turi įsitikinti, kad jos interneto paraiškoje nėra HTML injekcijų. Jei injekcijos buvo aptiktos, užpuolikas gali lengvai nustatyti vaizdo žymą į savo žiniatinklio serverį ir rasti būdą, kaip nukreipti naudotoją. Taigi jis gaus galimybę pavogti kodą iš "Referad" antraštės HTTP užklausos.
Oauth tockey vagystė naudojant redirect_uri parametrąParaiška inicijuoja leidimų išdavimo procesą, siunčiant užklausą "OAuth Server":
https://www.example.com/signin/Authorize?[.... ]&redirect_uri=httpps://demo.example.com/Loginsuccessful.
Užklausoje visada yra "redirect_uri" parametras, kurį naudoja "OAuth Server", kad išsiųstų žetonus atgal į paraišką po to, kai vartotojas davė savo sutikimą. Jei šio parametro vertė nėra kontroliuojama arba nėra tikrinama, užpuolikas gali lengvai jį pakeisti ir peradresuoti užklausą į savo svetainę, kur ji naudoja specialią programą tvarkant raktą ir įgyti prieigą prie riboto išteklių.
https://www.example.com/signin/Authorize?[.... ]&redirect_uri=httpps://localhost.evil.com.
Kartais panašūs URL yra užblokuoti. Užpuolikas gali nukreipti gautus duomenis apie atvirą URL, kaip:
https://www.example.com/oauth20_authorize.srf?[....[&redirect_uri=httpps://accounts.google.com/backtouthsubtarget?next=httpset://evil.com.
Arba tai:
https://www.example.com/oauth2/authorize? [...]% irect_uri = https% 3A% 2f% 2faps.facebook.com% 2fattacker% 2f.
Įgyvendinant OUTH, jūs niekada negalėsite įtraukti visų baltųjų sąrašų. Tik keletas URL turėtų būti įtraukta į "redirect_uri", nesudaro peradresuoti prašymą pradėti peradresuoti.
Kryžminio užklausų klastojimasGydytojo užklausos klastojimas gali pasireikšti, kai užpuolikas pavyksta padaryti auką paspausti savo nuorodą ir, todėl generuoti prašymą, kad jis nesiruošia generuoti. Kryžminio užklausų klastojimas paprastai yra sušvelnintas su CSRF rakzu, kuris yra susijęs su vartotojo sesija. Tai padeda prašymui patikrinti asmenį, kuris išsiuntė prašymą asmenį. "Valstybė" parametras "OAuth" protokole yra CSRF raktas.
Verta žiūrėti, kaip CSRF ataka yra vykdoma OAuth ir kaip "valstybės" parametras gali būti naudojamas siekiant sušvelninti pažeidžiamumo poveikį.
"Hacker" atidaro žiniatinklio programą ir pradeda leidimų išdavimo procesą, kad pasiektumėte paslaugų teikėją naudodami "Outh". Paraiška prašo paslaugų teikėjo, kad galėtų naudotis. "Hacker" bus nukreipta į paslaugų teikėjo svetainę, kur paprastai reikia įvesti savo naudotojo vardą ir slaptažodį, kad galėtumėte pasiekti prieigą. Vietoj to, įsilaužėlis sugauna ir neleidžia šiam prašymui ir išsaugo savo URL. Hacker kažkaip sukelia auką atidaryti šį URL. Jei nukentėjusysis atvyko į paslaugų teikėjo sistemą naudodami savo sąskaitą, tada jo įgaliojimai bus naudojami leidimo kodui išduoti. Leidimų kodo keitimasis prieiga prie prieigos rakto. Dabar yra leidžiama naudoti įsilaužėlių sąskaitą. Jis gali pasiekti nukentėjusiojo sąskaitą.
Taigi, kaip galiu užkirsti kelią šiam situacijai naudodami "valstybės" parametrą?
Paraiška turi sukurti vertę, kuri yra kažkaip remiantis šaltinio sąskaita (pavyzdžiui, naudokite vartotojo sesiją maišos raktą). Tai nėra taip svarbu, kas tai yra, svarbiausia yra tai, kad vertė yra unikali ir sukurta naudojant asmeninę informaciją apie pradinį vartotoją. Jis priskiriamas parametrai "Valstybiniam".
Ši vertė perduodama paslaugų teikėjui, kai nukreipiamas. Dabar įsilaužėlis kviečia auką atidaryti URL, kurį jis išlaikė.
Leidimo kodas išduodamas ir siunčiamas atgal į klientą sesijoje kartu su "valstybės" parametro.
Klientas generuoja parametrų vertę, pagrįstą sesijos informacija ir lygina jį su "valstybės" vertės, kuri buvo išsiųsta nuo leidimo prašymo paslaugų teikėjui. Ši vertė neatitinka "valstybės" parametro užklausoje, nes ji buvo sukurta tik remiantis informacija apie dabartinę sesiją. Kaip rezultatas, gauta vertė nepriima sistemos.
Kiti pažeidžiamumai, aptikti "Outh" yra gebėjimas atlikti XSS (scenarijų scenarijus), naudojant "redirect_uri" parametrą, oauth privataus rakto nustatymas (raktas kartais gali būti gautas dekompiliuojant mobiliąją paraišką) ir autorizacijos kodo taisyklės pažeidimą (kai Leidimo kodas gali būti naudojamas daugiau kaip vieną kartą, kad išlaikytumėte daugybę prieigos žetonų). Šie pažeidžiamumai yra mažiau paplitę nei pirmiau aprašyti, bet tai nedaro mažiau pavojingų. Kūrėjas turėtų žinoti visą reikalingą praktiką, kad užtikrintų patikimą savo interneto paraiškos veikimą.
Išversto straipsnio autorius: Simon Saliba.
SVARBU! Informacija tik akademiniais tikslais. Prašome laikytis teisės aktų ir netaikykite šios informacijos neteisėtiems tikslams.
Įdomesnė medžiaga cisoclub.ru. Prenumeruokite mums: "Facebook" VK | Twitter | Instagram | Telegrama | Zen | Messenger |. ICQ New | "YouTube" | Pulsas.