Představte si API, které zákazníkovi vrací jeho faktury. Přihlášený uživatel pošle požadavek s číslem faktury a dostane její detail. Co se stane, když číslo změní na jiné? Pokud server neověří, že faktura patří tomuto uživateli, vrátí cizí data. Této slabině se říká IDOR, z anglického Insecure Direct Object Reference.
V přehledu OWASP API Security Top 10 2023 je tato kategorie na prvním místě pod názvem Broken Object Level Authorization, zkráceně BOLA. OWASP uvádí, že jde o v API rozšířený problém. Server totiž často rozhoduje podle identifikátoru, který posílá klient.
Jak slabina vypadá v praxi
Následující příklad je ilustrativní, nejde o skutečný případ. Uživatel A je přihlášen do zákaznického portálu a jeho aplikace načítá fakturu:
- Původní požadavek: GET /api/v1/faktury/10452 s přihlašovacím tokenem uživatele A.
- Upravený požadavek: GET /api/v1/faktury/10453 se stejným tokenem uživatele A.
Server v obou případech odpoví kódem 200 a vrátí data faktury. Jenže faktura 10453 patří jinému zákazníkovi. Server ověřil, že uživatel je přihlášen, ale už ne, zda smí vidět právě tento záznam.
Stejný problém se může týkat i změny nebo mazání dat, třeba u požadavků PUT nebo DELETE. Identifikátor přitom nemusí být jen v adrese. Může být v parametru, v těle požadavku, v hlavičce nebo v odkazu na soubor ke stažení. Ve víceklientských SaaS aplikacích pak chyba může otevřít přístup k datům jiné organizace.
Proč ho automatický skener často nenajde
Skener vidí odpovědi serveru, ale nezná obchodní pravidla. Nemá jak poznat, že faktura 10453 patří někomu jinému. Z jeho pohledu server odpověděl správně: kódem 200 a platnými daty. Chyba je v tom, komu data patří, a to automat bez kontextu nerozliší. Na rozdíl od chyb ve zpracování vstupů se IDOR projevuje zcela platnými požadavky.
K tomu přistupují další důvody:
- Skener obvykle pracuje s jedním účtem, takže nemá s čím porovnávat.
- Neví, které identifikátory jsou citlivé a jak spolu souvisejí.
- Neprojde vícekrokové procesy, ve kterých se identifikátor objeví až později.
- Nerozliší, kdy je přístup k cizímu záznamu záměrný, například u sdílených dokumentů.
Proto se autorizace ověřuje hlavně ručně. Tester používá alespoň dva účty se stejnou rolí a ideálně i účty v různých organizacích. Systematicky zkouší přistupovat k objektům druhého účtu. Postup popisuje i OWASP Web Security Testing Guide. Pomoci mohou nástroje, které porovnávají odpovědi pro různé uživatele. Výsledek je ale vždy potřeba posoudit v kontextu aplikace.
Podobná slabina existuje i na úrovni funkcí. OWASP ji vede samostatně jako Broken Function Level Authorization: běžný uživatel zavolá operaci určenou administrátorovi. Při testu autorizace se proto obvykle ověřují obě úrovně.
Jak IDOR spolehlivě opravit
Základní pravidlo zní: o přístupu rozhoduje server, a to u každého požadavku. Nestačí, že je uživatel přihlášen. Nestačí ani to, že odkaz na cizí záznam v aplikaci neuvidí.
V praxi pomáhají tyto zásady:
- Kontrola oprávnění u každé operace. Při čtení, změně i mazání ověřte, že přihlášený uživatel nebo jeho organizace má k záznamu přístup.
- Identita z relace. Kde to jde, neberte identitu uživatele ani tenantu z požadavku. Použijte údaje z ověřené relace nebo tokenu.
- Filtrování přímo v dotazu. Hledejte záznam podle identifikátoru a zároveň podle vlastníka nebo tenantu. Neexistující i cizí záznam pak vrátí stejnou odpověď.
- Centrální autorizační vrstva. Kontrolu na jednom místě je těžší zapomenout než podmínku rozesetou po celém kódu.
- Odmítnutí jako výchozí stav. Pokud pravidlo chybí, přístup se nepovolí.
- Automatické testy autorizace. Ke každému koncovému bodu patří test, že uživatel B nedostane data uživatele A.
Pozor také na úrovně oprávnění uvnitř jedné organizace. Uživatel může mít přístup k firmě, ale ne ke všem jejím projektům nebo pobočkám. Autorizační pravidla by měla odpovídat skutečnému obchodnímu procesu, ne jen rozdělení na tenanty.
Náhodné identifikátory, například UUID, ztěžují hádání. Příčinu ale neřeší, protože identifikátory se objevují v odkazech, logech nebo sdílených e-mailech. OWASP je proto doporučuje jen jako doplňkovou vrstvu, ne jako náhradu kontroly oprávnění. Podrobnosti najdete v OWASP Authorization Cheat Sheet a OWASP IDOR Prevention Cheat Sheet.
Kontrolní seznam pro vývojový tým
- Každý koncový bod, který pracuje s identifikátorem, ověřuje oprávnění na serveru.
- Identita uživatele a tenantu se bere z relace, ne z parametrů požadavku.
- Databázové dotazy filtrují podle vlastníka nebo tenantu.
- Autorizace je řešená centrálně a výchozím stavem je odmítnutí.
- Automatické testy ověřují přístup mezi dvěma uživateli a dvěma tenanty.
- Kontrola pokrývá i soubory, exporty, webhooky a operace na pozadí.
- Odpověď na cizí záznam neprozrazuje, zda záznam existuje.
Pokud vyvíjíte API nebo SaaS aplikaci a chcete ověřit, že autorizace funguje u všech rolí a tenantů, můžeme to prověřit penetračním testem nebo bezpečnostní analýzou software. Domluvte si konzultaci a společně určíme vhodný rozsah.
