[ INSECURE_DESIGN ]

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

Chyba v základech

Insecure Design není o špatně napsaném kódu (bug), ale o špatně vymyšleném postupu (flaw). Aplikace může mít 100% testy pokrytý kód bez jediné injekce, a přesto být naprosto nebezpečná, protože její architektura dovoluje útočníkovi zneužít legitimní funkce k nelegitímním cílům.

Klíčové rozdíly pro Bug Bounty:

  • Implementation Flaw: SQL injection v přihlašovacím poli (chyba programátora).
  • Design Flaw: Možnost vyčerpat slevové kupóny díky chybějícímu ověření limitu na uživatele (chyba návrhu).
  • Trust Boundary Violation: Server slepě věří datům, která by měla být validována (např. cena produktu zaslaná z frontendu).

Pokročilé scénáře Business Logic chyb

V BBP hledáme tzv. "Edge Cases" – situace, na které designér zapomněl.

Race Conditions

Návrh nepočítá s paralelními požadavky. Příklad: Útočník pošle 10 požadavků na vyplacení 100 Kč z peněženky ve stejnou milisekundu. Pokud návrh nezamyká databázi, může vybrat 1000 Kč, i když má na účtu jen stovku.

Step Skipping

Obcházení workflow. Příklad: E-shop má kroky: 1. Košík, 2. Doprava, 3. Platba, 4. Potvrzení. Útočník zkusí skočit přímo z kroku 1 na krok 4 (přes přímou URL), čímž objedná zboží bez placení.

Klientská strana vs. Serverová realita

Jeden z nejčastějších projevů Insecure Designu je přenesení odpovědnosti na uživatele. Nikdy nesmíme zapomenout: Client-side is attacker-controlled.

api_request — checkout_process
POST /api/order/submit
{
  "item_id": "premium_vpn_sub",
  "price": "0.01", // Hacker přepsal původních 1000.00
  "currency": "CZK"
}
# Pokud server neověří cenu v DB, objednávka projde.

Analýza workflow: Zneužití obnovy hesla

Špatný návrh "Security Questions" (jméno psa, matky za svobodna) je dnes brán jako kritické selhání. Moderní útočník tyto informace získá z OSINT (Open Source Intelligence). Bezpečný design vyžaduje:

Prevence: Threat Modeling & SDLC

Bezpečnost musí být vryta do DNA aplikace od první schůzky s klientem.

Koncept Popis Cíl
Shift LeftZapojení bezpečnosti do fáze analýzy.Odhalení chyb dříve, než se napíše kód.
Fail SecurelyPři chybě se systém uzavře.Zamezení nechtěnému povolení přístupu.
Abuse Case TestingTestování, jak lze funkci zneužít (negativní scénáře).Zablokování útočných cest v logice.

Shrnutí OWASP (A06:2025)

OWASP zdůrazňuje, že Insecure Design nelze opravit patchem (záplatou). Vyžaduje to změnu logiky aplikace. Pokud navrhnete systém, který dovoluje uživateli "vysát" API bez rate-limitingu, není to bug v kódu API, ale v jeho definici.