Predstavte si API, ktoré zákazníkovi vracia jeho faktúry. Prihlásený používateľ pošle požiadavku s číslom faktúry a dostane jej detail. Čo sa stane, keď číslo zmení na iné? Ak server neoverí, že faktúra patrí tomuto používateľovi, vráti cudzie údaje. Tejto slabine sa hovorí IDOR, z anglického Insecure Direct Object Reference.
V prehľade OWASP API Security Top 10 2023 je táto kategória na prvom mieste pod názvom Broken Object Level Authorization, skrátene BOLA. OWASP uvádza, že ide o v API rozšírený problém. Server totiž často rozhoduje podľa identifikátora, ktorý posiela klient.
Ako slabina vyzerá v praxi
Nasledujúci príklad je ilustratívny, nejde o skutočný prípad. Používateľ A je prihlásený do zákazníckeho portálu a jeho aplikácia načítava faktúru:
- Pôvodná požiadavka: GET /api/v1/faktury/10452 s prihlasovacím tokenom používateľa A.
- Upravená požiadavka: GET /api/v1/faktury/10453 s rovnakým tokenom používateľa A.
Server v oboch prípadoch odpovie kódom 200 a vráti údaje faktúry. Lenže faktúra 10453 patrí inému zákazníkovi. Server overil, že používateľ je prihlásený, ale už nie, či smie vidieť práve tento záznam.
Rovnaký problém sa môže týkať aj zmeny alebo mazania údajov, napríklad pri požiadavkách PUT alebo DELETE. Identifikátor pritom nemusí byť len v adrese. Môže byť v parametri, v tele požiadavky, v hlavičke alebo v odkaze na súbor na stiahnutie. Vo viacklientskych SaaS aplikáciách potom chyba môže otvoriť prístup k údajom inej organizácie.
Prečo ho automatický skener často nenájde
Skener vidí odpovede servera, ale nepozná obchodné pravidlá. Nemá ako zistiť, že faktúra 10453 patrí niekomu inému. Z jeho pohľadu server odpovedal správne: kódom 200 a platnými údajmi. Chyba je v tom, komu údaje patria, a to automat bez kontextu nerozlíši. Na rozdiel od chýb pri spracovaní vstupov sa IDOR prejavuje úplne platnými požiadavkami.
Pridávajú sa ďalšie dôvody:
- Skener zvyčajne pracuje s jedným účtom, takže nemá s čím porovnávať.
- Nevie, ktoré identifikátory sú citlivé a ako spolu súvisia.
- Neprejde viackrokové procesy, v ktorých sa identifikátor objaví až neskôr.
- Nerozlíši, kedy je prístup k cudziemu záznamu zámerný, napríklad pri zdieľaných dokumentoch.
Preto sa autorizácia overuje najmä manuálne. Tester používa aspoň dva účty s rovnakou rolou a ideálne aj účty v rôznych organizáciách. Systematicky skúša pristupovať k objektom druhého účtu. Postup opisuje aj OWASP Web Security Testing Guide. Pomôcť môžu nástroje, ktoré porovnávajú odpovede pre rôznych používateľov. Výsledok je však vždy potrebné posúdiť v kontexte aplikácie.
Podobná slabina existuje aj na úrovni funkcií. OWASP ju vedie samostatne ako Broken Function Level Authorization: bežný používateľ zavolá operáciu určenú administrátorovi. Pri teste autorizácie sa preto zvyčajne overujú obe úrovne.
Ako IDOR spoľahlivo opraviť
Základné pravidlo znie: o prístupe rozhoduje server, a to pri každej požiadavke. Nestačí, že je používateľ prihlásený. Nestačí ani to, že odkaz na cudzí záznam v aplikácii neuvidí.
V praxi pomáhajú tieto zásady:
- Kontrola oprávnenia pri každej operácii. Pri čítaní, zmene aj mazaní overte, že prihlásený používateľ alebo jeho organizácia má k záznamu prístup.
- Identita z relácie. Kde sa to dá, neberte identitu používateľa ani tenanta z požiadavky. Použite údaje z overenej relácie alebo tokenu.
- Filtrovanie priamo v dopyte. Hľadajte záznam podľa identifikátora a zároveň podľa vlastníka alebo tenanta. Neexistujúci aj cudzí záznam potom vráti rovnakú odpoveď.
- Centrálna autorizačná vrstva. Kontrolu na jednom mieste je ťažšie zabudnúť ako podmienku roztrúsenú po celom kóde.
- Odmietnutie ako predvolený stav. Ak pravidlo chýba, prístup sa nepovolí.
- Automatické testy autorizácie. Ku každému koncovému bodu patrí test, že používateľ B nedostane údaje používateľa A.
Pozor aj na úrovne oprávnení v rámci jednej organizácie. Používateľ môže mať prístup k firme, ale nie ku všetkým jej projektom alebo pobočkám. Autorizačné pravidlá by mali zodpovedať skutočnému obchodnému procesu, nie iba rozdeleniu na tenantov.
Náhodné identifikátory, napríklad UUID, sťažujú hádanie. Príčinu však neriešia, pretože identifikátory sa objavujú v odkazoch, logoch alebo zdieľaných e-mailoch. OWASP ich preto odporúča len ako doplnkovú vrstvu, nie ako náhradu kontroly oprávnení. Podrobnosti nájdete v OWASP Authorization Cheat Sheet a OWASP IDOR Prevention Cheat Sheet.
Kontrolný zoznam pre vývojový tím
- Každý koncový bod, ktorý pracuje s identifikátorom, overuje oprávnenie na serveri.
- Identita používateľa a tenanta sa berie z relácie, nie z parametrov požiadavky.
- Databázové dopyty filtrujú podľa vlastníka alebo tenanta.
- Autorizácia je riešená centrálne a predvoleným stavom je odmietnutie.
- Automatické testy overujú prístup medzi dvoma používateľmi a dvoma tenantmi.
- Kontrola pokrýva aj súbory, exporty, webhooky a operácie na pozadí.
- Odpoveď na cudzí záznam neprezrádza, či záznam existuje.
Ak vyvíjate API alebo SaaS aplikáciu a chcete overiť, že autorizácia funguje pri všetkých rolách a tenantoch, môžeme to preveriť penetračným testom alebo bezpečnostnou analýzou softvéru. Dohodnite si konzultáciu a spoločne určíme vhodný rozsah.
