Kas yra IDOR ir kodėl būtina teisių kontrolė?
Autorius: Domeny.ForSale redakcija Paskelbta
Trumpai: IDOR (Insecure Direct Object Reference) – tai saugumo spraga, kai programa leidžia pasiekti kitam naudotojui priklausantį išteklių nurodžius jo identifikatorių, bet tinkamai nepatikrinus prieigos teisių. Pavyzdžiui, naudotojas pakeičia sąskaitos faktūros numerį adrese ir pamato kito kliento dokumentą. Problema yra ne pats numeris adrese, o tai, kad serveris netikrina, ar šis asmuo turi teisę pasiekti tą sąskaitą faktūrą.
Kaip veikia IDOR: paprastas pavyzdys
Įsivaizduokite kliento savitarnos sistemą, kurioje prisijungę atsisiunčiate savo sąskaitą faktūrą. Naršyklė siunčia serveriui užklausą su keliu /saskaitos/481, o programa grąžina dokumentą, kurio numeris 481.
Toks adresas savaime yra įprastas sprendimas. Spraga atsiranda tada, kai pakeitus kelią į /saskaitos/482 galima atsisiųsti kito kliento sąskaitą faktūrą, nors prieiga prie jos jums nesuteikta.
Tai primena drabužinę, kurioje darbuotojas atiduoda paltą kiekvienam, pasakiusiam pakabos numerį, užuot patikrinęs, ar žmogus turi teisę jį atsiimti. Numeris nurodo daiktą, bet nepatvirtina teisės jį gauti.
Žodis „objektas“ pavadinime IDOR čia reiškia programos išteklių: dokumentą, užsakymą, nuotrauką, pranešimą ar paskyrą. „Tiesioginė nuoroda“ reiškia šio ištekliaus nurodymą pagal identifikatorių. Tai nebūtinai turi būti eilės numeris – identifikatoriumi gali būti failo pavadinimas, el. pašto adresas ar ilga ženklų seka.
Kodėl vien prisijungti nepakanka
Tapatumo nustatymas atsako į klausimą „Kas jūs esate?“. Autorizavimas, arba teisių tikrinimas, atsako į kitą klausimą: „Ką jums leidžiama daryti?“. Programa gali tinkamai atpažinti prisijungusį naudotoją, tačiau vis tiek suteikti jam prieigą prie svetimų duomenų.
Saugus serveris turi patikrinti ne tik tai, ar sąskaita faktūra egzistuoja, bet ir tai, ar naudotojui leidžiama ją skaityti. Prieigos teisę gali suteikti dokumento nuosavybė, naudotojo vaidmuo organizacijoje arba sąmoningas dokumento bendrinimas su kitu asmeniu.
IDOR neapsiriboja svetimos informacijos peržiūra. Netikrinant teisių taip pat gali būti įmanoma pakeisti ar pašalinti kitam naudotojui priklausantį išteklių, pavyzdžiui, pristatymo adresą užsakyme. Teisė skaityti savaime nesuteikia teisės redaguoti, todėl kiekvienam veiksmui reikia atitinkamos kontrolės.
Jei programa naudojasi kelios įmonės, svarbu atskirti ir jų prieigos teises. Vienos įmonės administratorius neturėtų gauti prieigos prie kitos įmonės duomenų vien todėl, kad žino jos dokumento identifikatorių.
Kur gali slypėti nesaugiai naudojamas identifikatorius
Identifikatorius nebūtinai matomas adreso juostoje. Jis gali būti užklausos parametruose, per formą siunčiamos užklausos turinyje arba API – programų tarpusavio ryšiui skirtos sąsajos – iškvietime.
Teisių kontrolės paprastai reikia atliekant šiuos veiksmus:
- atsisiunčiant sąskaitas faktūras, priedus ir eksportuotus duomenis;
- skaitant pranešimus, užklausas ir užsakymus;
- atnaujinant profilį ar paskyros nustatymus;
- šalinant failus ir kitus išteklius.
Ne kiekvienas atvejis, kai pakeitus identifikatorių gaunama prieiga, reiškia klaidą. Viešas tinklaraščio įrašas turi būti pasiekiamas visiems, o bendrinamas dokumentas – atitinkamas teises turintiems bendradarbiams. Spragą lemia numatytų prieigos taisyklių pažeidimas, o ne pati galimybė nurodyti kitą objektą.
Panašios API klaidos kartais vadinamos BOLA (Broken Object Level Authorization), tai yra netinkama teisių kontrolė konkretaus objekto lygmeniu. Šie pavadinimai glaudžiai susiję, o praktinis klausimas išlieka tas pats: ar serveris tikrina naudotojo teisę pasiekti nurodytą išteklių ir atlikti norimą veiksmą?
Kas iš tiesų apsaugo nuo IDOR
Pagrindinė apsauga – teisių tikrinimas serveryje kiekvieną kartą, kai kreipiamasi į išteklių. Paslėpti mygtuką sąsajoje nepakanka, nes užklausą galima išsiųsti ir tuo mygtuku nepasinaudojus.
Sąskaitų faktūrų pavyzdyje programa turėtų ieškoti dokumento tarp tam naudotojui prieinamų dokumentų arba patikrinti teises prieš jį grąžindama. Naršyklės atsiųsto lauko „savininkas“ ji neturėtų laikyti nuosavybės įrodymu.
Atsitiktiniai identifikatoriai, tokie kaip UUID, apsunkina adresų spėjimą, bet nepakeičia autorizavimo. Jei identifikatorius nutekėtų, pavyzdžiui, per pasidalytą nuorodą, serveris vis tiek privalėtų nesuteikti prieigos asmeniui, neturinčiam reikiamų teisių.
Verta laikytis numatytojo draudimo principo: jei programa negali patvirtinti teisės atlikti veiksmą, ji jo neatlieka. Kontrolė turi apimti ir failų atsisiuntimą bei duomenų eksportą, o ne tik pagrindinį dokumento peržiūros langą.
Kaip saugiai patikrinti savo programą
Tokį bandymą atlikite tik jums priklausančioje sistemoje arba turėdami leidimą ją testuoti. Geriausia naudoti testavimo aplinką ir fiktyvius duomenis, ypač tikrinant keitimo ir šalinimo veiksmus.
- Sukurkite dvi bandomąsias paskyras – A ir B, kurių ištekliai nebūtų bendrinami tarpusavyje.
- Naudodamiesi paskyra A sukurkite dokumentą ir užsirašykite jo identifikatorių.
- Prisijunkite prie paskyros B ir pabandykite perskaityti tą dokumentą per tam skirtą sąsają arba API.
- Atskirai patikrinkite, ar galima jį redaguoti, atsisiųsti ir pašalinti, jei tokie veiksmai numatyti.
- Patikrinkite ne tik atsisakymo suteikti prieigą pranešimą, bet ir tai, ar jokie duomenys nebuvo atskleisti arba pakeisti.
Serveris turi neleisti atlikti neleistino veiksmo; jis taip pat gali sąmoningai neatskleisti, ar dokumentas egzistuoja. Tokį scenarijų verta įtraukti į automatinius testus, kad pakeitus kodą spraga neatsirastų iš naujo.
Taip pat skaitykite
