Pažeisto objekto lygio autorizacija su pavyzdžiais

Šiame įraše mes tyrinėjame ir aptariame sugadinto objekto lygio autorizacijos gedimą.

Pirmiausia paaiškinsime, ką reiškia sugadinto objekto lygio įgaliojimas. Tada mes patirsime ataką ir paaiškinsime susijusius rizikos veiksnius.

Tada mes apžvelgsime kai kuriuos galimus pažeidžiamumo padarinius, kol galiausiai apžvelgsime bendrus gynybos būdus.




Kas yra sugadinto objekto lygio autorizacija

Trumpai tariant, tokio tipo ataka reiškia, kad duomenims suteikta prieigos teisė daroma ne taip, kaip turėtų. Tai reiškia, kad prieiga prie išteklių ir duomenų suteikiama tada, kai to neturėtų būti.

Anksčiau sugadinto objekto lygio autorizacija buvo žinoma kaip nesaugi tiesioginė objekto nuoroda (IDOR).


Kai tariame žodį objektas „Broken Object Level Authorization“ reiškia, kad mes turime reikšmę arba vertybių grupę. Objektas gali būti socialinės žiniasklaidos įrašas, kuriame yra autorius, turinys ir paskelbimo data.

Leidimas yra viskas, ką vartotojui leidžiama pasiekti. Todėl kalbame apie vartotoją, kuris jau yra prisijungęs.

Kai vartotojas pateikia užklausą API, užklausa naudojama norint pasiekti objektus. Būtent šiuo klausimu reikėtų priimti sprendimą dėl autorizacijos. Vartotojas turėtų turėti prieigą tik prie objektų, prie kurių jam buvo suteikta prieiga. Tai autorizacija veikia tinkamai.


Pažeidus autorizaciją, vartotojams leidžiama pasiekti duomenis ir išteklius, kurių jiems neturėtų būti leidžiama.

API palengvina įvairias operacijas su objektais. Mes galime gauti, kurti, atnaujinti ar net ištrinti objektus.

Sąveika su objektu yra visa API esmė, todėl jei prie šių objektų sutrinka autorizacijos valdikliai, turime pažeidžiamumą „Broken Object Level Access“.



Išnaudoti sugadinto objekto lygio prieigos pažeidžiamumą

Suradus šį pažeidžiamumą paprastai lengva pasinaudoti. Užpuolikas turi padaryti tik tai, kad užklausoje būtų pakeistas identifikatorius, ir jis galbūt gavo prieigą prie objektų, kuriems neturėtų būti leista.


Pažiūrėkime tai pavyzdyje.

Čia mes turime URL, kuris naudojamas paskambinti API:

https://myemail.com/messages/12345

Šis API skambutis naudojamas norint nuskaityti vartotojo asmeninius pranešimus. Naudojamas šaltinis yra žinutes .

Pranešimas yra objektas, apie kurį kalbame sutrikusio objekto lygio įgaliojime. Daroma prielaida, kad asmeninius pranešimus gali perskaityti tik numatytas gavėjas.


Tada mes turime pranešimo ID 12345. Tai yra svarbi užpuoliko dalis.

ID nurodo tarnybai, kurį įrašą grąžinti. API gauna tą įrašą iš duomenų saugyklos ir grąžina atsakyme.

Kas nutiks, jei pakeisime ID iš 12345 į 12346? pvz .:

https://myemail.com/messages/12346

Jei pranešimas su ID 12346 buvo skirtas mūsų vartotojui, turėtume sugebėti jį gauti.


Bet jei pranešimas priklausė kitam vartotojui, API niekada jo neturėtų grąžinti. Jei mums pavyko gauti pranešimą, tada įvyko sugedusio lygio objekto įgaliojimo klaida.

Kitas pavyzdys yra POST užklausos siuntimas atnaujinti šaltinį. Mes galime žaisti su JSON naudingosios apkrovos ID:

{
'userId': '12345678',
'oldPassword': 'My_0ld_Pa$$',
'newPassword': '$uperS3CurE' }

Jei turėtume įdėti kokį nors potencialą userId užklausoje ir galėjome atnaujinti kito vartotojo duomenis, tada turime didžiulę problemą.

Techninis poveikis

Žinodami, kad pažeidžiamumas egzistuoja, galime jį išnaudoti visais būdais. Kaip minėta anksčiau, API galime naudoti įvairius HTTP metodus. Mes galime naudoti ID, norėdami atnaujinti ar net ištrinti pranešimus!

Kas atsitiks, jei mums pavyko pakartoti visus ID? Galbūt galėsime ištrinti kiekvieną išsaugotą pranešimą. Tai didelis poveikis.



Bendras pažeidžiamumas

Tai labai dažnas pažeidžiamumas. Kaip minėta anksčiau, API yra naudojamos prieigai prie objektų ir daugeliu atvejų mes naudojame ID prašyme nustatyti išteklius. Kyla klausimas, ar atliekami prieigos patikrinimai?

Iš esmės yra dvi priežastys, kodėl kode atsiranda pažeidžiamų objektų lygio autorizacijos pažeidžiamumų.

Pirmasis yra tas, kad saugumo kontrolė paprasčiausiai nebuvo įgyvendinta. Kodas nebuvo parašytas norint atlikti užklausų įgaliojimų patikrinimus.

Antroji priežastis yra žmogaus klaida. Žmonės daro klaidų. Geras pavyzdys yra API, kuris tvarko abu neskelbtinus duomenis. Kai kurios užklausos turėtų būti patikrintos dėl autorizacijos, o kitos - ne. Taigi gali būti lengva praleisti patikrinimą rašant kodą.



Kaip aptikti

Automatizuoti įrankiai paprastai neranda šio tipo pažeidžiamumo, nes tai paprastai reikalauja bent šiek tiek smegenų jėgos.

Žmogui palyginti lengva aptikti šį pažeidžiamumą. Viskas, ką turime padaryti, yra surasti identifikatorių, kuris naudojamas objektams nuskaityti.

Atkreipkite dėmesį, kad identifikatorius gali būti URL, užklausos tekste arba antraštėje.

Taip pat turime išanalizuoti ir interpretuoti grįžusį atsakymą, kad pamatytume, ar yra pažeidžiamumas.

Įrankiai

Mes galime naudoti bet kokį įrankį, kuris tikrina HTTP užklausas ir atsakymus. Kai kurie iš jų yra:

  • „Google“ kūrėjo įrankiai
  • Liukso numeris „Burp“
  • Paštininkas

„Burp Suite“ taip pat gali būti naudojamas kai kurioms užklausoms automatizuoti.



Gynyba nuo sugadinto objekto lygio leidimo

Čia turime dvi gynybas.

Pirmoji gynyba yra naudoti nenuspėjami ID, pvz., GUID . Kai kode naudojame iš eilės einančius skaičius, pvz. 12345, tai reiškia, kad ID yra labai nuspėjami. Užpuolikui nereikia daug pastangų norint pereiti numerius, norint rasti objektus.

GUID pavyzdys:

d3b773e6-3b44-4f5f-9813-c39844719fc4

GUID yra sudėtingi, juos labai sunku atspėti ir jie nėra nuoseklūs.

Kita gynyba yra iš tikrųjų turėti tam tikrą kodą patikrinti įgaliojimą . Šis patikrinimas dažnai tiesiog neįvyksta.

Patvirtinimas turėtų būti tikrinamas bet kuriuo metu, kai vartotojas pateikia API naudodamas ID. Pagrindinis principas yra tai, kad mes niekada neturėtume pasitikėti duomenimis, kuriuos vartotojas pateikia API.

Prašomas ID turi būti patikrintas, kad būtų patvirtinta, kad vartotojas turi prieigą prie objekto.

Šie patikrinimai gali būti tik paprastos kodų peržiūros programinės įrangos kūrimo metu ir (arba) automatizuotos patikros, kuriomis tikrinama, ar kūrimo metu nėra autorizacijos klaidų.



Išvada

Kaip matėme, sugadinto objekto lygio autorizavimas yra dažnas pažeidžiamumas, kurį lengva pastebėti ir užpulti. Galimas poveikis yra didžiulis.

Tikrasis šio pažeidžiamumo šaltinis yra pasitikėjimas duomenimis, kuriuos klientas perduoda API.

Didelė gynybos dalis yra įsitikinti, kad nepasitikime tais duomenimis. Taigi turime įsitikinti, kad atliekami autorizacijos patikrinimai.