Nefunkční autorizace na úrovni objektu s příklady

V tomto příspěvku prozkoumáme a probereme selhání autorizace Broken Object Level.

Začneme vysvětlením, co znamená autorizace na úrovni poškozeného objektu. Poté projdeme útokem a vysvětlíme související rizikové faktory.

Poté se podíváme na některé z možných dopadů zranitelnosti, než se konečně podíváme na běžné obrany.




Co je to Broken Object Level Authorization

Stručně řečeno, tento typ útoku znamená, že autorizace aplikovaná na data neprobíhá tak, jak by měla. To vede k udělení přístupu ke zdrojům a datům, pokud by to nemělo být.

Zlomená autorizace na úrovni objektu byla v minulosti známá jako Insecure Direct Object Reference (IDOR).


Když řekneme slovo objekt v Broken Object Level Authorization máme na mysli hodnotu nebo skupinu hodnot. Objektem může být příspěvek na sociálních médiích, který obsahuje autora, obsah a datum zveřejnění.

Povolení je o tom, k čemu má uživatel přístup. Mluvíme tedy o uživateli, který je již přihlášen.

Když uživatel zadá požadavek na API, použije se požadavek na přístup k objektům. O tomto bodě by mělo být rozhodnuto o povolení. Uživatel by měl mít přístup pouze k objektům, ke kterým jim byl udělen přístup. Toto oprávnění funguje správně.


Pokud dojde k porušení autorizace, uživatelé mají přístup k datům a zdrojům, ke kterým by neměli mít přístup.

API usnadňuje různé operace s objekty. Můžeme získat, vytvářet, aktualizovat nebo dokonce mazat objekty.

Interakce s objektem je celým bodem API, proto pokud jsou ovládací prvky autorizace kolem těchto objektů rozbité, máme zranitelnost Broken Object Level Access.



Zranitelnost přístupu na úrovni poškozeného objektu

Jakmile je tato chyba zabezpečení nalezena, je obecně snadné ji zneužít. Útočníkovi stačí změnit identifikátor v požadavku a potenciálně má přístup k objektům, ke kterým by neměl mít povolení.


Podívejme se na příklad.

Zde máme URL, která se používá k volání API:

https://myemail.com/messages/12345

Toto volání API se používá k načtení soukromých zpráv uživatele. Používaný prostředek je zprávy .

Zpráva je objekt, na který odkazujeme v Broken Object Level Authorization. Předpokládá se, že soukromé zprávy může číst pouze zamýšlený příjemce.


Dále máme ID zprávy 12345. To je pro útočníka důležitá součást.

ID říká službě, který záznam má vrátit. API načte tento záznam z úložiště dat a vrátí jej v odpovědi.

Co se stane, když změníme ID z 12345 do 12346? např:

https://myemail.com/messages/12346

Pokud je zpráva s ID 12346 byl určen pro našeho uživatele, měli bychom být schopni jej získat.


Pokud ale zpráva patřila jinému uživateli, rozhraní API by ji nikdy nemělo vrátit. Pokud se nám podařilo zprávu načíst, došlo k chybě Broken Level Object Authorization.

Dalším příkladem je odeslání požadavku POST na aktualizaci zdroje. Můžeme si hrát s ID v užitečném obsahu JSON:

{
'userId': '12345678',
'oldPassword': 'My_0ld_Pa$$',
'newPassword': '$uperS3CurE' }

Pokud bychom měli dát nějaký potenciál userId v požadavku a byli schopni aktualizovat podrobnosti jiného uživatele, pak máme obrovský problém.

Technický dopad

Jakmile zjistíme, že zranitelnost existuje, můžeme ji využívat všemi možnými způsoby. Jak již bylo zmíněno dříve, na API můžeme použít různé metody HTTP. Můžeme použít ID k aktualizaci nebo dokonce smazání zpráv!

Co se stane, pokud budeme schopni iterovat všemi ID? Mohli bychom být schopni odstranit každou uloženou zprávu. To je velký dopad.



Běžná zranitelnost

Toto je velmi běžná chyba zabezpečení. Jak již bylo zmíněno dříve, API se používají k přístupu k objektům a ve většině případů používáme ID v požadavku k identifikaci zdrojů. Otázkou je, zda existují kontroly oprávnění pro tento přístup?

Existují hlavně dva důvody, proč v kódu skončíme s chybami zabezpečení autorizace na zlomenou úroveň objektu.

První je, že bezpečnostní kontrola jednoduše nebyla implementována. Kód nebyl napsán, aby bylo možné provádět autorizační kontroly žádostí.

Druhým důvodem je lidská chyba. Lidé dělají chyby. Dobrým příkladem je rozhraní API, které zpracovává citlivá data i necitlivá. Některé žádosti by měly mít kontrolu autorizace a jiné ne. Při psaní kódu tedy může být snadné vynechat šek.



Jak detekovat

Automatizované nástroje tento typ zranitelnosti normálně nenajdou, protože mají tendenci vyžadovat alespoň trochu mozkové síly.

Pro člověka je relativně snadné tuto chybu zabezpečení odhalit. Jediné, co musíme udělat, je najít identifikátor, který se používá k načtení objektů.

Poznámka: identifikátor může být v adrese URL, v těle požadavku nebo v záhlaví.

Také musíme analyzovat a interpretovat odezvu, která se vrací, abychom zjistili, zda existuje zranitelnost nebo ne.

Nástroje

Můžeme použít jakýkoli nástroj, který kontroluje požadavky a odpovědi HTTP. Některé z nich jsou:

  • Nástroje pro vývojáře Google
  • Burp Suite
  • Listonoš

Burp Suite lze také použít k automatizaci některých požadavků.



Obrana proti rozbitému oprávnění na úrovni objektu

Máme tady dvě obrany.

První obranou je použití nepředvídatelné ID, jako jsou GUID . Když v kódu použijeme po sobě jdoucí čísla, např. 12345, to znamená, že ID jsou velmi předvídatelná. Útočník nepotřebuje velké úsilí, aby procházel čísly, aby našel předměty.

Příklad identifikátoru GUID:

d3b773e6-3b44-4f5f-9813-c39844719fc4

Identifikátory GUID jsou složité a velmi těžké uhodnout a nejsou postupné.

Další obranou je skutečně mít nějaký kód zkontrolovat autorizaci . K této kontrole často nedochází.

Ke kontrole autorizace by mělo dojít kdykoli, když uživatel předloží API v rámci ID, které se bude používat. Základním principem zde je, že bychom nikdy neměli důvěřovat datům, která uživatel dává API.

Je třeba zkontrolovat požadované ID, aby se potvrdilo, že uživatel má oprávnění k přístupu k objektu.

Tyto kontroly mohou být jen jednoduché kontroly kódu během vývoje softwaru a / nebo automatizované kontroly, které kontrolují selhání autorizace během vývoje.



Závěr

Jak jsme viděli, Broken Object Level Authorization je běžná zranitelnost, kterou lze snadno odhalit a zaútočit. Potenciální dopady jsou obrovské.

Skutečným zdrojem této chyby zabezpečení jsou důvěryhodné údaje, které klient předá rozhraní API.

Velkou součástí obrany je zajistit, abychom těmto údajům nedůvěřovali. Musíme se tedy ujistit, že jsou zavedeny autorizační kontroly.