Penetrační testování webových aplikací a API

Rámcem je OWASP ASVS ve verzi 5.0 z května 2025, tedy katalog požadavků na bezpečnost aplikace, a OWASP Web Security Testing Guide ve stabilní verzi 4.2, který popisuje, jak se každý požadavek ověřuje. Díky tomu je test opakovatelný a vy víte, co se dělo. U rozhraní API k tomu přidáváme OWASP API Security Top 10 ve verzi 2023, protože API selhává jinak než webové rozhraní: chybí mu obrazovka, která by uživatele omezila.

Prakticky to znamená sedm skupin, pojmenovaných podle toho, co se v nich láme, ne podle deseti kategorií OWASP Top 10: autentizace a správa relací, autorizace mezi rolemi, práce se vstupy (injekce, XSS, nahrávání souborů), business logika, konfigurace serveru a hlaviček, práce s citlivými daty a rozhraní na třetí strany. U každé skupiny testujeme ručně a nález ověřujeme, než ho napíšeme do reportu.

Aplikaci nikdy netestujeme jen jako anonymní návštěvník. Pro každou roli, kterou aplikace zná, potřebujeme vlastní účet, protože největší nálezy vznikají mezi rolemi, ne před přihlašovací obrazovkou.

Tahle stránka pokrývá webovou aplikaci a její API z prohlížeče; mobilní aplikaci a její backend testujeme zvlášť, protože mobilní klient se testuje jinými technikami než webové rozhraní.

Skener najde chybějící hlavičku a starou verzi knihovny. Nenajde, že se cizí objednávka schválí přehozením jednoho identifikátoru v požadavku, ani že reset hesla vydá platný token bez ověření vlastnictví schránky. Tomu prvnímu se říká nezabezpečený přímý odkaz na objekt, zkratkou IDOR, a OWASP tutéž chybu vede u rozhraní API pod názvem narušení autorizace na úrovni objektu jako položku API1:2023. Skener na ni nemá jak přijít: nerozumí tomu, co má která role ve vaší aplikaci smět.

Takhle vypadá chyba v autorizaci na úrovni objektu. Uživatel s rolí účetní otevře detail faktury, v adrese je číslo dokladu, po jeho změně se zobrazí doklad jiné pobočky. Aplikace kontroluje, že je uživatel přihlášený, ale už ne, že mu doklad patří. Do reportu jde požadavek, odpověď, snímek obrazovky a čtyři kroky, kterými si to vývojář zopakuje.

Druhá skupina je business logika, kde je každá chyba jiná. Sleva se dá uplatnit dvakrát, objednávka se dá potvrdit bez zaplacení, limit na převod se obejde záporným číslem. Tohle nejde automatizovat, protože správné chování zná jen ten, kdo aplikaci rozumí.

Grey box doporučujeme jako výchozí volbu. Dostaneme účty pro každou roli a základní popis aplikace, ale ne zdrojový kód. Za stejný počet dní projdeme výrazně víc funkcí než u black boxu, kde první dva dny padnou na hledání toho, co aplikace vlastně umí.

Black box má smysl, když chcete vidět, kam se dostane útočník bez jediného účtu, typicky u veřejného portálu nebo e-shopu. Zdrojový kód se vyplatí přidat u aplikace, kde je hodně vlastní kryptografie nebo složitá autorizační logika: nenahradí test, ale zrychlí hledání a zvýší pokrytí. Co ty tři varianty znamenají obecně a proč u sítě znamenají něco jiného než u aplikace, popisují tři varianty znalosti a co která odhalí.

Pět věcí, a je dobré je mít připravené před podpisem rozsahu. Za prvé seznam rolí, které aplikace zná, a k nim dva účty na roli, aby šlo testovat přístup k cizím datům v rámci téže role. Za druhé prostředí, na kterém se testuje, a informaci, jestli je v něm produkční kopie dat. Za třetí kontakt na vývojáře nebo dodavatele pro případ, že něco přestane fungovat.

Za čtvrté rozhodnutí o WAF. Když necháte aplikační firewall zapnutý, testujeme přes něj a část nálezů se schová za blokovaná pravidla. Doporučujeme dvoufázový postup: nejdřív test s naší IP adresou na výjimce, aby se ukázal skutečný stav aplikace, potom krátké ověření, co z toho WAF v ostrém provozu zachytí. Bez výjimky měříte kvalitu filtru, ne kvalitu aplikace.

Za páté termín. Test běží v pracovní dny, a pokud aplikace posílá zákazníkům e-maily nebo SMS, vypněte na dobu testu odesílání ven, nebo nám to řekněte. Průběh testu, klasifikaci nálezů a podobu reportu máme společné pro všechny testy a popsané na jednom místě: jak u nás probíhá test od scopingu po retest.

Nejlepší je testovací prostředí, které je věrnou kopií produkce. Testujeme naplno, včetně zápisů, a nikdo neřeší, že v objednávkách přibylo dvě stě testovacích záznamů. Podmínka je jediná: musí obsahovat stejnou verzi kódu a stejnou konfiguraci, jinak testujete něco, co u zákazníků neběží.

Na produkci testujeme také, ale s omezením. Operace, které by poškodily nebo smazaly data, ověřujeme jen čtením a zápis zkoušíme na vlastních testovacích účtech. Vše, co vytvoříme, si značíme a na konci vám pošleme seznam, abyste to mohli uklidit. Rizikové kroky voláme předem.

Rozsah počítáme ze tří proměnných: počtu uživatelských rolí, počtu obrazovek nebo endpointů a toho, jestli je součástí i API a administrace. Malý zákaznický portál se dvěma rolemi zabere zhruba dva týdny, rozsáhlý e-shop s administrací, věrnostním programem a API pro partnery tři.

Co rozsah zvedá nejvíc, není počet stránek, ale počet kombinací rolí a stavů. Aplikace se čtyřmi rolemi a schvalovacím procesem o třech krocích má víc přechodů k otestování než aplikace s dvaceti statickými obrazovkami. Přesně to je to, co rozhoduje o rozsahu testu aplikace, a tím i o délce, kterou uvidíte v nabídce.

U e-shopu je jádrem testu košík a platba: uplatnění slevy, změna ceny na straně klienta, dokončení objednávky bez zaplacení a přístup k cizí objednávce přes číslo dokladu. K tomu integrace na platební bránu a dopravce. Ty běží mezi servery a autorizují se klíčem nebo tokenem, takže na ně nedosáhne přihlášení uživatele a kontrolu oprávnění musí aplikace řešit zvlášť.

Zákaznický portál stojí a padá s oddělením účtů. Testujeme, jestli se zákazník dostane k dokumentům jiného zákazníka, jestli jde přes registraci obsadit cizí e-mail a co se dá vyčíst z chybových hlášek. U interních aplikací je to naopak role: účetní se dostane do personalistiky, brigádník vidí ceníky dodavatelů.

Interní aplikace mají navíc slabší přihlašování, protože se o nich předpokládá, že je nikdo zvenčí neuvidí. To platí do chvíle, než někdo získá přístup do sítě. Test aplikace tenhle předpoklad neověří, na to je test infrastruktury, na které aplikace běží.