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

Penetrační test webové aplikace je řízená simulace kybernetického útoku, při které bezpečnostní specialisté hledají zranitelnosti, které by mohl zneužít skutečný útočník. Slouží k proaktivnímu ověření bezpečnosti webové aplikace a odhalení zranitelností, které by mohly vést k únikům dat a provozním problémům.

Typický pentest webové aplikace zahrnuje ověření autentizace, autorizace, správy relací, vstupních formulářů, API i dalších částí aplikace. Cílem není pouze najít chyby, ale také posoudit jejich skutečný dopad a navrhnout konkrétní opatření k jejich odstranění.

Penetrační testování aplikací je navrženo tak, aby odhalilo zranitelnosti vznikající kombinací návrhu aplikace, způsobu implementace i předpokladů obchodní logiky a pracovních procesů. Mezi nejčastější nálezy patří nedostatečné řízení přístupových oprávnění, možnosti eskalace oprávnění, chyby v obchodní logice, nezabezpečená správa uživatelských relací, zneužitelné nebo nedokumentované chování API i vícefázové scénáře útoků, které kombinují několik zdánlivě méně závažných nedostatků do útoku s významným dopadem.

Standardní penetrační test webové aplikace a API zabere 5–15 člověkodnů, v praxi to jsou 1–3 týdny podle složitosti zadání. Automatické testy jsou součástí našeho arzenálu, ale důraz klademe především na manuální testování. Součástí je také test zranitelnosti infrastruktury, na které webová aplikace běží, a to v rozsahu aktiv, která máte ve správě nebo k jejichž testování máte oprávnění od jejich provozovatele.

Délka testování závisí na rozsahu aplikace, počtu funkcí, API endpointů i požadované hloubce testu. Menší webové aplikace lze otestovat během několika dnů, rozsáhlé podnikové systémy obvykle vyžadují jeden až několik týdnů.

Před samotným pentestem je potřeba si vyjasnit rozsah testu, motivaci a co od testu očekáváte. Se vším vám pomohou naši konzultanti. Poté je dobrou praxí uzavření NDA, buď samostatně nebo jako součást smlouvy.

Závěrečná zpráva obsahuje přehled zjištěných zranitelností a doporučení pro jejich odstranění z pohledu bezpečnostního auditora. Jednotlivé nálezy jsou hodnoceny podle mezinárodně uznávaného standardu CVSS 3.1 (Common Vulnerability Scoring System), který vyjadřuje jejich technickou závažnost.

Rozhodnutí o způsobu řešení jednotlivých nálezů je vždy na organizaci, zpravidla ve spolupráci s manažerem kybernetické bezpečnosti (MKB) nebo vlastníkem systému. Pokud zranitelnost představuje pro organizaci nepřijatelné riziko, doporučuje se její odstranění. V některých případech lze místo odstranění zavést kompenzační bezpečnostní opatření, která sice zranitelnost neodstraní, ale významně sníží pravděpodobnost jejího zneužití nebo dopad případného incidentu.

U méně závažných nálezů může organizace na základě analýzy rizik rozhodnout, že jejich riziko je vzhledem k charakteru podnikání akceptovatelné. V takovém případě není nutné přijímat další opatření, rozhodnutí by však mělo být řádně zdokumentováno v rámci procesu řízení rizik.

Po odstranění nálezů doporučujeme provést re-test, který ověří jejich skutečné odstranění. Re-test není součástí ceny penetračního testu a naceňujeme jej samostatně.

Cena závisí především na velikosti a složitosti aplikace, rozsahu API, počtu uživatelských rolí i požadované metodice testování. Každý projekt proto naceňujeme individuálně. Po úvodní konzultaci připravíme přesnou cenovou nabídku bez skrytých nákladů.

Doporučujeme provést penetrační test minimálně jednou ročně a vždy po významných změnách aplikace, například po nasazení nových funkcí, změně autentizačního mechanismu nebo integraci s dalšími systémy. Pravidelné testování pomáhá odhalit nově vzniklé zranitelnosti dříve, než je mohou zneužít útočníci.

Automatické skenery umí rychle identifikovat známé typy zranitelností. Neumí ale posoudit jejich skutečnou zneužitelnost. Penetrační test kombinuje automatizované nástroje s manuálním testováním zkušených bezpečnostních specialistů, kteří ověřují nalezené zranitelnosti, hledají složitější scénáře útoků a testují logické chyby, které automatické nástroje obvykle neodhalí.

Mezi nejčastější zranitelnosti API patří nedostatečná autentizace a autorizace, chyby v řízení přístupových oprávnění (BOLA/BFLA), nadměrné zpřístupnění dat na úrovni vlastností objektů (Broken Object Property Level Authorization, dříve označované jako Excessive Data Exposure), nedostatečná validace vstupů, chybějící omezení počtu požadavků (Rate Limiting), nesprávná konfigurace CORS nebo únik citlivých informací prostřednictvím chybových hlášení. Moderní penetrační test API ověřuje nejen technické chyby, ale také bezpečnost obchodní logiky a odolnost vůči zneužití jednotlivých endpointů.

Řada regulatorních rámců a bezpečnostních standardů, včetně PCI DSS, SOC 2, ISO 27001, DORA nebo ZoKB, vyžaduje nebo důrazně doporučuje pravidelné penetrační testování aplikací jako důkaz, že zavedená bezpečnostní opatření jsou ověřována proti realistickým scénářům útoků. Výstupy z penetračního testu poskytují dokumentaci, která auditorům umožňuje ověřit, že organizace identifikuje a vyhodnocuje rizika, odstraňuje nalezené zranitelnosti a přistupuje k zabezpečení svých aplikací systematicky a dlouhodobě.

Rozdíl spočívá v tom, kolik informací mají bezpečnostní specialisté o testované webové aplikaci před zahájením testování.

• Black box testování simuluje útok externího útočníka, který nemá žádné interní informace o aplikaci. Tester pracuje pouze s veřejně dostupnými informacemi a hledá zranitelnosti stejně jako skutečný útočník.
• Grey box testování kombinuje pohled externího útočníka s omezenými znalostmi systému. Tester má například běžný uživatelský účet, dokumentaci k API nebo základní architekturu aplikace. Tento přístup umožňuje efektivněji odhalit chyby v autentizaci, autorizaci nebo obchodní logice.
• White box testování probíhá s plnou znalostí aplikace. Tester má přístup například ke zdrojovým kódům, architektuře, konfiguraci nebo interní dokumentaci. Díky tomu lze důkladně prověřit i zranitelnosti, které by při běžném útoku nemusely být snadno objeveny.

V praxi se nejčastěji využívá grey box testování, protože nabízí nejlepší poměr mezi realistickou simulací útoku, hloubkou testování a časovou efektivitou.

OWASP (Open Worldwide Application Security Project) je mezinárodní nezisková organizace, která vytváří otevřené standardy, metodiky a doporučení pro bezpečnost webových aplikací a API. Její materiály patří mezi nejuznávanější zdroje v oblasti aplikační bezpečnosti a využívají je bezpečnostní specialisté i vývojové týmy po celém světě.

Nejznámějším projektem je OWASP Top 10, seznam deseti nejzávažnějších bezpečnostních rizik webových aplikací. V aktuální edici OWASP Top 10:2025 jsou na prvních místech nedostatečná kontrola přístupů (Broken Access Control), chybná konfigurace (Security Misconfiguration) a rizika dodavatelského řetězce softwaru (Software Supply Chain Failures). Do kategorie Injection spadá i SQL Injection nebo Cross-site Scripting (XSS). Penetrační testy se těmito doporučeními běžně řídí a ověřují, zda aplikace vůči těmto hrozbám odolává.

Penetrační testování simuluje reálný útok s cílem ověřit, zda lze zranitelnosti nebo slabiny v konfiguraci systému skutečně zneužít a jaký by takový útok mohl mít dopad na organizaci. Nejedná se však o bezpečnostní výzkum zaměřený na aktivní vyhledávání dosud neznámých (zero-day) zranitelností.

Standardní penetrační test vychází z veřejně známých technik útoku, aktuálních hrozeb a osvědčených metodik. Jeho cílem je posoudit reálnou úroveň zabezpečení testovaného prostředí, nikoliv objevovat nové zranitelnosti v používaném softwaru.

Pokud bychom během testování narazili na dosud neznámou zranitelnost (zero-day), budeme postupovat podle zásad koordinovaného odpovědného zveřejnění zranitelností (Coordinated Vulnerability Disclosure). To znamená, že o nálezu nejprve informujeme dotčenou organizaci a výrobce produktu a neposkytneme žádné veřejné informace, dokud nebude mít výrobce přiměřenou možnost zranitelnost odstranit.