A01:2025 Nedostatky v řízení přístupu (Broken Access Control)

Pozadí

Tato kategorie si udržuje první místo v žebříčku Top Ten. U 100 % testovaných aplikací byla zjištěna určitá forma narušeného řízení přístupu. Mezi významné související slabiny (CWE) patří zejména CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-201: Exposure of Sensitive Information Through Sent Data, CWE-918 Server-Side Request Forgery (SSRF) a CWE-352: Cross-Site Request Forgery (CSRF). Tato kategorie vykazuje v poskytnutých datech nejvyšší počet výskytů a zároveň druhý nejvyšší počet souvisejících zranitelností (CVE).

Tabulka skóre

Počet mapovaných CWE	Max míra výskytu	Průměrná míra výskytu	Max pokrytí	Průměrné pokrytí	Průměrná vážená míra zneužitelnosti	Průměrný vážený dopad	Celkový počet výskytů	Celkový počet CVE
40	20,15 %	3,74 %	100,00 %	42,93 %	7,04	3,84	1 839 701	32 654

Popis

Řízení přístupu vynucuje bezpečnostní politiku tak, aby uživatelé nemohli vykonávat činnosti mimo rozsah jim určených oprávnění. Selhání řízení přístupu typicky vedou k neoprávněnému zpřístupnění informací, k neoprávněné změně nebo zničení dat, případně k provádění aplikačních nebo obchodních funkcí mimo oprávnění daného uživatele. Mezi běžné zranitelnosti v oblasti řízení přístupu patří:

Porušení principu nejmenších oprávnění (princip „deny by default“), kdy má být přístup povolen pouze ke konkrétním funkcím, rolím nebo uživatelům, avšak ve skutečnosti je dostupný komukoli.
Obcházení kontrol řízení přístupu úpravou URL (manipulace s parametry nebo force browsing), změnou vnitřního stavu aplikace nebo HTML stránky, případně použitím nástroje, který modifikuje API požadavky.
Umožnění zobrazení nebo úpravy cizího účtu na základě znalosti jeho jedinečného identifikátoru (Insecure Direct Object Reference – IDOR).
Veřejně přístupné API s chybějícími kontrolami řízení přístupu pro metody POST, PUT a DELETE.
Eskalace oprávnění, tedy jednání jako přihlášený uživatel bez autentizace nebo získání oprávnění nad rámec oprávnění odpovídajících přihlášenému uživateli (např. administrátorský přístup).
Manipulace s metadaty, například opakované použití nebo pozměnění přístupového tokenu JSON Web Token (JWT), manipulace s cookie nebo skrytým formulářovým polem za účelem zvýšení oprávnění, případně zneužití mechanismu zneplatňování JWT.
Chybná konfigurace CORS, která umožňuje přístup k API z neoprávněných nebo nedůvěryhodných zdrojů.
Force browsing (hádání URL) umožňující přístup k autentizovaným stránkám jako neautentizovaný uživatel nebo k privilegovaným stránkám jako běžný uživatel.

Jak tomu zabránit

Řízení přístupu je účinné pouze tehdy, pokud je implementováno v důvěryhodném kódu na straně serveru nebo v serverless API, kde útočník nemůže ovlivnit samotnou kontrolu řízení přístupu ani související metadata.

S výjimkou veřejných zdrojů musí být přístup implicitně zakázán (deny by default).
Mechanismy řízení přístupu by měly být implementovány jednou a znovupoužitelné v celé aplikaci; zároveň by mělo být omezeno používání Cross-Origin Resource Sharing (CORS).
Řízení přístupu na úrovni aplikačních modelů musí vynucovat vazbu mezi uživatelem (nebo jiným subjektem) a konkrétními datovými záznamy, nikoli umožňovat uživatelům vytvářet, číst, upravovat nebo mazat libovolné záznamy.
Jedinečné byznys limity aplikace musí být vynucovány na úrovni doménových modelů.
Na webovém serveru musí být zakázán výpis adresářů a je nutné zajistit, aby se ve webovém kořeni nenacházela metadata repozitářů (např. .git) ani záložní soubory.
Porušení řízení přístupu musí být logována a v odůvodněných případech (např. při opakovaných selháních) musí být administrátoři upozorněni.
Pro přístup k API a kontrolerům musí být uplatněn rate limiting, aby se omezily dopady automatizovaných útočných nástrojů.
Stavové identifikátory relací musí být po odhlášení na straně serveru zneplatněny. Bezstavové tokeny JWT by měly mít krátkou dobu platnosti, aby se minimalizovalo časové okno pro jejich zneužití. U JWT s delší dobou platnosti je vhodné použít refresh tokeny a postupy dle standardů OAuth pro odvolání přístupu.
Doporučuje se používat zavedené knihovny nebo návrhové vzory, které poskytují jednoduché a deklarativní řízení přístupu.

Vývojáři i pracovníci QA by měli zahrnout funkční testování řízení přístupu do jednotkových i integračních testů.

Příklady scénářů útoků

Scénář #1: Aplikace používá neověřená data v SQL dotazu, který přistupuje k informacím o účtu:

pstmt.setString(1, request.getParameter("acct"));
ResultSet results = pstmt.executeQuery();

Útočník může jednoduše upravit parametr acct v prohlížeči a odeslat libovolné číslo účtu. Pokud není hodnota správně ověřena, útočník může získat přístup k účtu jiného uživatele.

https://example.com/app/accountInfo?acct=notmyacct

Scénář #2: Útočník jednoduše přistupuje k URL adresám přímo. Přístup na administrační stránku vyžaduje administrátorská oprávnění.

https://example.com/app/getappInfo
https://example.com/app/admin_getappInfo

Pokud má neautentizovaný uživatel přístup k některé z těchto stránek, jedná se o chybu. Pokud má uživatel bez administrátorských oprávnění přístup k administrační stránce, jedná se rovněž o chybu.

Scénář #3: Aplikace má veškeré řízení přístupu implementováno pouze na straně klienta (front-endu). Přestože se útočník nemůže dostat na adresu https://example.com/app/admin_getappInfo kvůli JavaScriptovému kódu spuštěnému v prohlížeči, může jednoduše spustit následující příkaz z příkazové řádky:

$ curl https://example.com/app/admin_getappInfo