[ BROKEN_ACCESS_CONTROL ]

Kliknutím se vrátíš zpět.

Kritické riziko č. 1

Broken Access Control (BAC) nastává, když aplikace selže v prosazování pravidel pro přístup k datům a funkcím. Útočník tak může obejít autorizační mechanismy a jednat jako jiný uživatel nebo jako administrátor.

Základní pilíře bezpečné autorizace:

  • Principle of Least Privilege (PoLP): Uživatel má mít pouze ta práva, která nezbytně potřebuje (minimální privilegia).
  • Deny by Default: Pokud přístup není explicitně povolen, systém ho musí automaticky zamítnout.
  • Fail Securely: Pokud autorizační mechanismus selže (např. chyba v DB), musí se aplikace přepnout do stavu "přístup zamítnut", nikoliv "přístup povolen".

Hloubkové scénáře eskalace práv

Jako bug hunter se musíš dívat na to, jakým směrem se můžeš v hierarchii práv "probourat".

Horizontální eskalace (IDOR)

Útočník přistupuje k datům uživatele na stejné úrovni.
Příklad: Změna /api/users/123 na /api/users/124. Pokud uvidíš cizí profil, máš IDOR.

Vertikální eskalace

Uživatel získá práva nadřízené role (např. Admina).
Příklad: Přidání parametru &admin=true do požadavku nebo přístup k /admin/panel v Cookies bez validace role.

Techniky manipulace s metadaty

Aplikace často věří informacím, které jí posílá klient. To je zásadní chyba. Bug hunteři manipulují s:

Prevence pro vývojáře (Security Checklist)

Zlaté pravidlo: Kontrola oprávnění musí probíhat na serveru při každém jednotlivém požadavku. Nikdy nespoléhejte na schovávání prvků v UI.

  • Používejte UUID (např. 550e8400-e29b-41d4...) místo sekvenčních ID, aby nešlo data "vytěžit" (insecure enumerace).
  • Implementujte ACL (Access Control Lists) centrálně, ne rozeseté po celém kódu.
  • Vypněte Directory Listing na úrovni webového serveru (Nginx/Apache).