Co je IDOR a proč nestačí pouhé přihlášení
Autor: Redakce Domeny.ForSale Zveřejněno
Stručně: IDOR (Insecure Direct Object Reference) je zranitelnost, při které aplikace umožňuje přístup k cizímu prostředku na základě jeho identifikátoru, aniž by řádně ověřila oprávnění. Uživatel například změní číslo faktury v adrese a zobrazí se mu dokument jiného zákazníka. Problémem není samotné číslo v adrese, ale to, že server neověřuje, zda má daná osoba k faktuře přístup.
Jak funguje IDOR — jednoduchý příklad
Představte si zákaznický portál, ve kterém si po přihlášení stáhnete vlastní fakturu. Prohlížeč odešle serveru požadavek na cestu /faktury/481 a aplikace vrátí dokument s číslem 481.
Taková adresa je sama o sobě běžným řešením. Zranitelnost vzniká tehdy, když změna cesty na /faktury/482 umožní stáhnout fakturu jiného zákazníka, přestože vám k ní nebyl udělen přístup.
Připomíná to šatnu, ve které zaměstnanec vydá kabát každému, kdo uvede číslo věšáku, místo aby ověřil nárok na jeho vyzvednutí. Číslo označuje předmět, ale nepotvrzuje oprávnění k jeho převzetí.
„Objekt“ v názvu IDOR zde označuje prostředek aplikace: dokument, objednávku, fotografii, zprávu nebo účet. „Přímý odkaz“ znamená určení tohoto prostředku pomocí identifikátoru. Nemusí jít o pořadové číslo — může to být název souboru, e-mailová adresa nebo dlouhý řetězec znaků.
Proč samotné přihlášení nestačí
Autentizace odpovídá na otázku: „Kdo jste?“ Autorizace neboli ověřování oprávnění odpovídá na jinou: „Co smíte dělat?“ Aplikace může správně rozpoznat přihlášeného uživatele, a přesto mu zpřístupňovat cizí data.
Zabezpečený server by měl ověřit nejen to, zda faktura existuje, ale také to, zda ji uživatel smí číst. Právo přístupu může vyplývat z vlastnictví dokumentu, role v organizaci nebo záměrného sdílení dokumentu s jinou osobou.
IDOR se neomezuje na prohlížení informací. Chybějící kontrola může umožnit také změnu nebo odstranění cizího prostředku, například doručovací adresy v objednávce. Oprávnění ke čtení automaticky neznamená právo upravovat, proto každá operace vyžaduje odpovídající kontrolu.
Pokud aplikace slouží více firmám, je důležité také oddělení jednotlivých organizací. Správce jedné firmy by neměl získat přístup k datům druhé jen proto, že zná identifikátor jejího dokumentu.
Kde se může skrývat identifikátor zneužitelný při útoku
Identifikátor nemusí být viditelný v adresním řádku. Může se nacházet v parametrech dotazu, v těle požadavku odesílaného formulářem nebo ve volání API, tedy rozhraní pro komunikaci mezi programy.
Kontrolu obvykle vyžadují tyto operace:
- stahování faktur, příloh a exportů dat;
- čtení zpráv, hlášení a objednávek;
- aktualizace profilu nebo nastavení účtu;
- odstraňování souborů a dalších prostředků.
Ne každý přístup po změně identifikátoru znamená chybu. Veřejný příspěvek na blogu má být dostupný všem a sdílený dokument oprávněným spolupracovníkům. O zranitelnost jde tehdy, když jsou porušena zamýšlená pravidla přístupu, nikoli jen proto, že lze určit jiný objekt.
Podobné chyby v API se někdy označují jako BOLA (Broken Object Level Authorization), tedy nesprávná kontrola oprávnění na úrovni konkrétního objektu. Tyto pojmy spolu úzce souvisejí; praktická otázka zůstává stejná: ověřuje server právo uživatele na přístup k danému prostředku a provedení požadované operace?
Co skutečně chrání před IDOR
Základním zabezpečením je kontrola oprávnění na straně serveru při každém přístupu k prostředku. Skrýt tlačítko v rozhraní nestačí, protože požadavek lze odeslat i bez jeho použití.
V příkladu s fakturami by aplikace měla hledat dokument mezi těmi, ke kterým má daný uživatel přístup, nebo před jeho vrácením ověřit oprávnění. Pole „vlastník“ odeslané prohlížečem by neměla považovat za důkaz vlastnictví.
Náhodné identifikátory, například UUID, ztěžují hádání adres, ale nenahrazují autorizaci. Pokud identifikátor unikne, například prostřednictvím sdíleného odkazu, server musí i nadále odepřít přístup osobě bez oprávnění.
Vhodnou zásadou je výchozí zamítnutí: pokud aplikace nedokáže potvrdit oprávnění k operaci, neprovede ji. Kontrola by se měla vztahovat také na stahování souborů a exporty, nejen na hlavní obrazovku dokumentu.
Jak bezpečně otestovat vlastní aplikaci
Takový test provádějte pouze v systému, který vám patří nebo k jehož testování máte souhlas. Nejlepší je použít testovací prostředí a smyšlená data, zejména při operacích změny a odstranění.
- Vytvořte dva testovací účty: A a B, které mezi sebou nesdílejí žádné prostředky.
- Pod účtem A vytvořte dokument a poznamenejte si jeho identifikátor.
- Přihlaste se jako B a zkuste tento dokument přečíst prostřednictvím určeného rozhraní nebo API.
- Samostatně ověřte možnost úprav, stažení a odstranění, pokud jsou tyto operace k dispozici.
- Ověřte nejen zprávu o odepření přístupu, ale také to, že nedošlo k odhalení ani změně žádných dat.
Server by měl nepovolenou operaci odmítnout; může také záměrně neprozradit, zda dokument existuje. Tento scénář je vhodné přidat do automatizovaných testů, aby změna v kódu zranitelnost znovu nezavedla.
Přečtěte si také
