Kas yra IDOR? Kodėl kūrėjams tai turėtų rūpėti?
Kas yra IDOR? Nesaugi tiesioginė objektų nuoroda (IDOR) yra kritinė saugumo spraga, atsirandanti, kai programos atskleidžia vidinius objektus, pvz., vartotojo ID, failus ar duomenų bazės raktus, neįgyvendindamos tinkamos prieigos kontrolės. „DevSecOps“ aplinkoje, kurioje saugumas yra integruotas į visą kūrimo gyvavimo ciklą, IDOR pažeidžiamumų prevencija yra būtina norint apsaugoti jautrius duomenis ir išlaikyti sistemos vientisumą.
IDOR pažeidžiamumas leidžia užpuolikams manipuliuoti objektų nuorodomis (pvz., pakeisti vartotojo ID URL adrese), kad pasiektų neleistinus išteklius. Tai gali sukelti duomenų nutekėjimą, privatumo pažeidimus ir neleistinus veiksmus sistemoje. Pavyzdžiui, jei API galinis taškas, pvz., /api/user/123 grąžina slaptą informaciją nepatikrinus, ar prašytojas turi teisę ją peržiūrėti, programa susiduria su nesaugia tiesiogine objekto nuoroda.
IDOR pažeidžiamumo supratimas ir prevencija yra labai svarbi ne tik saugumo komandoms, bet ir kūrėjams bei „DevOps“ inžinieriams. Tvirtų prieigos kontrolės mechanizmų ir saugių projektavimo šablonų užtikrinimas nuo pat pradžių padeda sušvelninti šią riziką dar prieš joms pasiekiant gamybos aplinką. Atsakymas į klausimą „Kas yra IDOR?“ yra esminis žingsnis link saugios pagal numatytuosius nustatymus architektūros.
Kodėl IDOR vis dar naudojamas šiuolaikinėse API ir Pipelines?
Nepaisant šiuolaikinių saugumo sistemų, tokių kaip, plitimo "OAuth, J.W.T.ir RBACIDOR pažeidžiamumai išlieka paplitę.
Dažniausios IDOR pažeidžiamumų priežastys:
- Objekto identifikatorių patvirtinimas nereikalaujant autorizacijos: Kūrėjai gali patvirtinti, kad objektas egzistuoja (pvz., naudotojas, kompiliavimo versija arba žurnalo failas), bet pamiršti patvirtinti, ar dabartiniam prašančiajam leidžiama jį peržiūrėti arba modifikuoti.
- Vidaus atskleidimas dashboardbe prieigos patikrinimų: Vidinės programos dažnai laikomos „saugiomis pagal numatytuosius nustatymus“ ir diegiamos su ribotais arba be jokių prieigos apribojimų, pagrįstų vaidmenimis.
- Darant prielaidą, kad vidinis lygus saugumui: Pasikliaujant tinklo ribomis (pvz., IP baltuoju sąrašu, VPN prieiga), o ne įgyvendinant patikrinimus pagal vartotoją arba vaidmenį, galima išlikti nesaugioms tiesioginių objektų nuorodoms.
Šios klaidos dažnai kyla dėl neteisingo IDOR supratimo, kai objekto ID buvimas traktuojamas kaip leidimo pakaitalas.
Realaus pasaulio scenarijų pavyzdžiai:
- CI sistema pateikia URL adresus, skirtus atsisiųsti kūrimo artefaktus, bet netikrina, ar prašytojas yra įgaliotosios komandos dalis.
- Vidinė parama dashboard leidžia darbuotojams ieškoti klientų profilių naudojant lengvai atspėjamus ID, netikrinant prieigos pagal vaidmenis.
- Viduje sukurti papildiniai arba scenarijai pateikia duomenis per neautentifikuotus galinius taškus, kad būtų patogiau derinimo metu.
Kiekvienas iš šių atvejų rodo tikrą IDOR pažeidžiamumą, kylantį dėl praleistos prieigos kontrolės.
Dažni IDOR poveikio taškai realiuose darbo eigose
IDOR pažeidžiamumai dažnai iškyla į paviršių vystymosi metu pipelines, vidinius įrankius ir API, kai objekto lygio prieigos patikrinimai nepaisomi.
Realaus pasaulio pavyzdžiai:
- Sukurti artefaktus: CI/CD Platformos gali saugoti artefaktus nuspėjamuose URL adresuose. Jei trūksta prieigos patikrinimų, šie galiniai taškai gali tapti nesaugiomis tiesioginėmis objektų nuorodomis.
- Prisijungti failai: Įrankiai, grąžinantys žurnalus pagal identifikatorius, nepatikrindami užklausos pateikėjo vaidmens, gali sukelti dar vieną IDOR pažeidžiamumą.
- Palaikymo įrankiai: Sistemos, kurios vidinę prieigą tapatina su autorizacija, yra pažeidžiamos netinkamo naudojimo dėl atspėjamų objektų nuorodų.
Teoriniai spąstai:
- Konfigūracijos failai: Atskleisti /config/production ar panašių galinių taškų naudojimas be autentifikavimo ir autorizacijos užtikrinimo sukuria nesaugią tiesioginę objekto nuorodą, ypač kai įterpti slapti kodai.
Visais atvejais trūkumas slypi tame, kad daroma prielaida, jog pakanka žinoti asmens tapatybę; būtent tai IDOR praktiškai ir reiškia.
Kaip aptikti ir patikrinti IDOR kūrėjų įrankiuose, CI papildiniuose ir vidinėse API sąsajose
Aptikimas apima IDOR supratimą ir kaip prielaidos apie objektų prieigą pasireiškia kode.
IDOR pažeidžiamumo požymiai:
- Galiniai taškai, kurie grąžina jautrius duomenis, pagrįstus tik objektų ID.
- Galimi objektų išvardijimo modeliai.
- Vidiniai įrankiai su minimaliais arba visai be prieigos apribojimų, pagrįstų vartotojo vaidmeniu.
Aptikimo strategija:
- Įvertinkite, kaip galiniai taškai remiasi vartotojo pateiktomis objektų nuorodomis.
- Nustatykite, kur trūksta prieigos logikos arba ji taikoma netiksliai.
- Imituokite užklausas naudodami perėmimo įrankius arba API testuotojus, kad patvirtintumėte, ar blokuojama neteisėta prieiga.
Realaus pasaulio audito tikslai:
- Tokie galiniai taškai kaip /build/{id}/artifact.
- Dashboards pateikia konfigūracijos informaciją iš atidarytų užklausų parametrų.
- Žurnalai arba metrikų skydai, kuriuose naudojami ID be prieigos patvirtinimo.
Supratimas, kas yra IDOR? leidžia kūrimo komandoms iš anksto patikrinti objektų saugumą.
Kaip išvengti IDOR pažeidžiamumų Pipelineir API
Užkirsti kelią an IDOR pažeidžiamumas yra pagrindinis „DevSecOps“ tikslas. Užuot pasikliaujant perimetro apsauga, užtikrinimas turėtų būti vykdomas kiekviename kūrimo gyvavimo ciklo etape.
Į „DevSecOps“ orientuotos priemonės:
- Automatinis testavimas CI/CD: Imituokite neteisėtą prieigą, kad užtikrintumėte savo pipeline laimikiai ir iškeltos vėliavos nesaugios tiesioginės objekto nuorodos.
- SAST bei SCA su sujungimo blokavimu: Naudokite statinės ir sudėties analizės įrankius, kad blokuotumėte pokyčius, kurie sukelia arba pablogina IDOR pažeidžiamumai.
- Galinių taškų auditai kūrimo metu: Reikalauti objekto lygio prieigos pagrindimo ir dokumentavimo kodo peržiūrose.
- Vidinių įrankių vadovų apžvalgos: Nepraleiskite atsiliepimų vien dėl to, kad įrankis yra vidinis. Daugelis nesaugios tiesioginių objektų nuorodos yra paslėpti vidinėse sistemose.
Kaip „Xygeni“ automatizuoja IDOR aptikimą ir prevenciją
Norint užkirsti kelią IDOR pažeidžiamumams dideliu mastu, reikia pereiti nuo rankinių peržiūrų prie nuolatinio, automatizuoto vykdymo užtikrinimo. Būtent tam ir yra skirta. Ksigeni ateina
Štai kaip „Xygeni“ padeda aptikti ir blokuoti nesaugias objektų nuorodas prieš joms išsiunčiant:
- Aptinka IDOR šablonus realiuoju laiku
„Xygeni“ analizuoja galinių taškų elgseną ir šaltinio kodo pakeitimus jūsų sistemoje CI/CD Darbo eigosJei aptinkama tiesioginė prieiga prie objektų be tinkamų autorizacijos patikrinimų, pvz. /api/user/123 jei jis rodomas nepatvirtinus vaidmens, jis nedelsdamas sukelia įspėjimą. - Blokuoja nesaugius galinius taškus prieš diegimą
Guardrails jūsų CI pipelinesustabdo kūrimą, kai aptinkama neautentifikuota objekto nuoroda. Galite nustatyti šiuos guardrails norint nutraukti kompiliavimą, atmesti PR arba pažymėti jį peržiūrai. Tai veikia su „GitHub Actions“, „GitLab CI“, „Jenkins“ ir kt. - Susieja išvadas su ataskaitų ataskaitomis ir audito takeliais
Kiekvienas atradimas yra susijęs su pull request, commitir prisidedantį kūrėją. Tai suteikia aiškų atsekamumą, kas pristatė pakeitimą, kas jį peržiūrėjo ir ar jis atitinka politiką.
Realaus pasaulio pavyzdys
Kūrėjas įkelia naują galinį tašką:
GET /build/7020/artifact.zip
„Xygeni“ patikrina, ar versijos ID yra apsaugotas prieigos kontrolės. Jei ne:
- PR pažymėtas įspėjimu
- CI pipeline blokuoja diegimą
- Audito žurnale įrašomas įvykis, nurodant, kas atliko pakeitimą ir ką reikia ištaisyti.
„Xygeni“ automatinė apsauga užtikrina, kad sustabdytumėte IDOR pažeidžiamumus ten, kur jie atsiranda – jūsų kode ir... pipelines.
Išvada: IDOR paverčia pažeidimus neatitikimais
Taigi, kas yra IDOR? Tai pažeidžiamumas, atsirandantis, kai kodas daro prielaidą, kad ID turėjimas yra lygus prieigai. Jis veikia tiek vidinius įrankius, tiek viešai prieinamus galinius įrenginius.
Apsauga nuo nesaugių tiesioginių objektų nuorodų reiškia prieigos patvirtinimą kiekvieną kartą. Automatizuokite aptikimą, blokuokite nesaugius diegimus ir vykdykite saugos politikas visame jūsų duomenų rinkinyje.
Pagrindinių praktikų santrauka:
- Įgyvendinti objekto lygio autorizavimą.
- Niekada nemanykite, kad vidinis ryšys yra lygus saugumui.
- Supraskite, kas yra IDOR ir kaip jis pasireiškia jūsų kode.
- Stebėkite IDOR pažeidžiamumus visame pipeline.
- Automatizuokite apsaugą naudodami tokius įrankius kaip „Xygeni“.
IDOR pažeidžiamumui nereikia sudėtingo išnaudojimo, pakanka nepastebėtos nuorodos. Apsaugokite jį, kol kas nors kitas jo nesuras!
