OWASP TOP 10 API Security Risks – 2023

Využití zabezpečení API je stále více používané, proto může být znalost těchto rizik klíčová pro bezpečnostní připravenost na daný rok. V seznamu naleznete druhy hrozeb, se kterými se můžete setkat a následně vhodnou reakci na jejich omezení.

1. Broken object-level authorization

Ověřování na úrovni objektů je kontrolní metoda pro omezení přístupu k objektům obvykle implementovaná na úrovni kódu pro ověřování uživatelů. Pokud není autorizace vynucena, může dojít k odhalení systémů. I při správných protokolech a konfiguracích se občas zapomíná na používání autorizační kontroly před přístupem k citlivým objektům.

Doporučujeme používat tuto metodu při každé funkci, která přijímá vstup od klienta pro přístup k objektům z úložiště dat. Jako další prostředek pro hardening, je doporučené používat kryptograficky bezpečné náhodné hodnoty GUID pro referenční ID objektů.


2. Broken authentication

Autentizační mechanismy jsou občas implementovány nesprávně a této chyby útočníci využívají ke kompromitování autentizačních tokenů a převzetí identity jiného uživatele, což celkově ohrožuje zabezpečení API.

Abychom zmírnili riziko útoku hrubou silou je nutné zavézt vícefaktorové ověření tam.

Slabé přihlašovací údaje by neměly být vůbec akceptovány. Také by se u všech tokenů měla provádět kontrola integrity z důvodu platnosti podpisových algoritmů a hodnot.

3. Broken object property level authorization

Chybějící nebo nesprávné ověření autentizace vede k odhalení informací nebo manipulaci neoprávněnými stranami. K útoku se využívají zranitelné koncové body API, které by pro útočníky neměly být dostupné.

Ověření uživatelských oprávnění by tedy mělo být ve všech koncových bodech rozhraní API zpracovávajících vlastnosti objektů. K těm by měl být jen omezený přístup, který by se měl také vztahovat k funkčnosti konkrétního koncového bodu.

4. Unrestricted resource consumption

Vyhovět požadavkům API vyžaduje využití procesoru, paměti, úložiště a dalších. Útoky jsou důsledkem nadměrné spotřeby těchto zdrojů a mohou vést k výpadkům nebo zvyšování provozních nákladů. Rozhraní API totiž často nekontrolují například časové limity, maximální povolenou paměť a další. Na počátku většinou škodlivá aktivita zůstane bez povšimnutí.

Proto je třeba zavést postup kódování, který omezuje spotřebu, například omezení počtu záznamů vrácených v odpovědí API, vynucení limitu velikosti u odesílaných souborů a zabránění vysoké spotřebě procesoru a paměti.

5. Broken function level authorization

Kvůli složitým zásadám řízení přístupu s různými hierarchiemi, skupinami a rolemi a nesprávnému oddělení správních a běžných funkcí bývají často chyby v autorizaci. Uživatelé mohou mít různé role pro různé oblasti, proto jejich sledování může být náročné. Útočníci mohou odhalit chybu v API, protože jejich metodika přístupu je předvídatelnější a strukturovanější, získají přístup k neautorizovaným funkcím.

Měla by být zajištěna pečlivá strukturalizace funkcí API a odpovídající kontrola autentizace. V případě jakýchkoli pochybností by měl být přístup odepřen a oprávnění by měla být udělována podle potřeby.

6. Unrestricted Access to Sensitive Business Flows

Pokud je citlivá funkce vystavena tak, že by při nadměrném automatizovaném použití mohlo dojít k poškození, je rozhraní API zranitelné. Nemusí se jednat o konkrétní chybu v implementaci, ale o náchylnost obchodního toku, který lze automatizovaně zneužít. Proti takovým hrozbám je důležité provádět modelování scénářů hrozeb, což je součástí celkové strategie snižování rizik. Z hlediska implementace lze na individuálním základě zavést opatření jako identifikaci zařízení, detekci lidského chování, odhalování neobvyklých toků a sekvencí v API a blokování IP adres.             

7. Server-side request forgery

K chybám dochází, když uživatel poskytne adresu URL nebo jiný vzdálený zdroj jako data rozhraní API. Jeho jménem se tak vytvoří odchozí požadavek na tuto adresu. Načítání dat se obvykle nezaznamenává ani nesleduje, útočníci najdou koncový bod API, který URL donutí aplikaci odeslat požadavek na neočekávané místo určení, i když jsou tato místa chráněna prostřednictvím firewallu nebo VPN.

Doporučuje se vyhodnocovat všechna data poskytovaná klientem. Je třeba prosadit striktní seznam povolených položek při implementaci funkcí pro načítání prostředků. Je také možné izolovat tuto funkci v rámci kontrolovaného síťového prostředí, které pečlivě monitorujeme.

8. Security misconfiguration

Rozhraní API a jejich podpůrné systémy často obsahují složité konfigurace. Jakékoli chybné nakonfigurování může vést k oslabení. Útočníci vyhledávají chyby a nechráněné soubory a útočí na běžné koncové body ke zmapování systémů a získání neoprávněného přístupu. Pro zmírnění rizika nám pomůže robustní a rychlý hardening.

Dále je třeba pravidelně sledovat a kontrolovat konfigurace API, použít řešení pro správu prostředků a správu zranitelnosti, která by tento proces automatizovala.

9. Improper inventory management

Velmi důležitá je správná a aktualizovaná dokumentace k API. Rozhraní API mohou být poměrně složitá a vzájemně provázaná napříč aplikacemi. Propojení s třetími stranami zvyšuje riziko ohrožení, a právě kvůli zastaralé nebo chybějící dokumentaci může být náročné mít o všem přehled.

Dokumentace by měla být pečlivě shromažďována a měla by být dostupná všem, kteří jsou oprávněni API používat. Integrace třetích stran by měla být taktéž kontrolována a prověřována.

10. Unsafe consumption of APIs

Převládá tendence důvěřovat datům získaných z rozhraní API třetích stran více než uživatelským vstupům. Proto mohou být použity méně přísné bezpečnostní standardy, zejména špatné omezení zdrojů, ověření přesměrování nebo validace požadavkům na data z rozhraní API před jejich zpracováním.

Je třeba zavést takové bezpečnostní postupy, aby všechna data byla validována a pečlivě kontrolována. Je dobré vyhodnotit integrace třetích stran a bezpečnostní pozice poskytovatelů služeb. Veškerá komunikace by měla probíhat přes zabezpečený kanál, například TSL. Rovněž by mělo být vynuceno vzájemné ověřování při spojení mezi službami.

 

Zdroje:

https://www.rapid7.com/blog/post/2023/06/08/owasp-top-10-api-security-risks-2023

https://owasp.org/API-Security/editions/2023/en/0x11-t10/

https://blog.barracuda.com/2023/03/17/owasp-top-10-api-security-risks-2023/

Pro více informací kontaktujte sales[@]comguard.cz.