01 / Riziko
Pojmenujeme, co je v sázce
Vazba mezi tokem dat, aktérem a obchodním pravidlem ukáže, proč je dané místo důležité.
Software a bezpečný vývoj
Od rizika k ověřené opravě
Nález má cenu teprve tehdy, když vede k opravě v aplikaci.
02 / Nález
Popíšeme podmínky a důkaz
Nález obsahuje dotčenou část, předpoklady a minimální reprodukci bez nadsazování dopadu.
03 / Dopad
Převedeme techniku do rozhodnutí
Dopad na data, dostupnost nebo oprávnění pomáhá určit prioritu a odpovědného vlastníka.
04 / Oprava
Navrhneme opravu a její ověření
Oprava míří na příčinu. Pokud je retest součástí nabídky, ověří původní scénář i možné regrese.
Přístup k objednávkám jiných zákazníků přes API
- Dotčené aktivum
- API objednávek, endpoint /api/orders/{id}
- Dopad
- Přihlášený uživatel změnou čísla objednávky čte data jiných zákazníků.
- Důkaz
- Reprodukční kroky a zkrácený požadavek a odpověď bez citlivých údajů.
- Doporučení
- Na serveru ověřovat vlastnictví záznamu u každého požadavku.
- Ověření
- Retest opravy podle dohodnutého rozsahu nabídky.
# přihlášen jako účet A
GET /api/orders/1044 HTTP/1.1
Authorization: Bearer ••••••••
HTTP/1.1 200 OK
{ "order": 1044, "owner": "účet B" }Různé metody odhalují různé problémy
Bezpečnostní analýza software není jeden automatický sken. Podle cíle a dostupných podkladů kombinujeme pohled na návrh, zdrojový kód, závislosti a chování aplikace. Kombinaci metod a hloubku práce určíme v zadání.
Architektura a hrozby
Toky dat, hranice důvěry, identity, oprávnění, integrace a oddělení tenantů. Odhalí rizika, která sken kódu nevidí.
Ruční code review
Kritické části implementace a obchodní logiky s odkazem na konkrétní revizi a místo v kódu.
SAST a SCA
Statická analýza kódu a kontrola závislostí jako podpora ručního review. Výsledky deduplikujeme a posoudíme v kontextu.
DAST a aplikační test
Ověření chování běžící aplikace a API včetně přihlášení, oprávnění a obchodních scénářů.
SaaS a enterprise dodávky mají specifické otázky
Jako kontrolní rámec může posloužit OWASP ASVS, jako zdroj testovacích postupů WSTG a OWASP API Security. Konkrétní pokrytí vždy popíšeme v zadání, aby bylo jasné, kde analýza končí.
- Vynucuje server oddělení tenantů u každé relevantní operace?
- Odpovídají role a oprávnění skutečnému obchodnímu procesu?
- Jak aplikace pracuje s integracemi, webhooky, tokeny a tajnými klíči?
- Rozhoduje aplikace o bezpečnosti stejně v UI, v API i na pozadí?
- Jaké riziko představují závislosti, konfigurace a cesta nasazení?
Výstupy, se kterými vývojový tým může pracovat
- Shrnutí rizik, dopadů a priorit pro vedení.
- Technický popis scénáře, důkaz a kroky reprodukce.
- Dotčené komponenty, verze a odkazy na kód nebo konfiguraci.
- Doporučená oprava a konzultace složitých nebo sporných nálezů.
- Volitelný retest původních nálezů na dohodnuté verzi.
Jaké podklady si připravit
Pro první rozhovor stačí stručný popis aplikace, technologií, důvodu analýzy a požadovaného termínu. Pro samotnou zakázku můžeme potřebovat architekturu, konkrétní revizi kódu, postup sestavení, testovací prostředí, uživatelské role a dokumentaci API.
Ne každá analýza potřebuje všechny vstupy. Co chybí, se ale vždy promítne do uvedených omezení výsledku.
