Co je penetrační test webové aplikace?

Penetrační test webové aplikace je řízený bezpečnostní útok prováděný etickým hackerem, jehož cílem je odhalit zranitelnosti dříve, než je zneužije skutečný útočník. Na rozdíl od automatizovaného skenování tester analyzuje aplikační logiku, autorizační scénáře a chování systému v nestandardních situacích. Testování probíhá dle metodiky OWASP Web Security Testing Guide (WSTG). Každý nález je popsán s proof of concept, CVSS 4.0 skóre a návodem na opravu.

Jaký je rozdíl mezi penetračním testem a skenováním zranitelností?

Skener zranitelností je automatizovaný nástroj, který porovnává aplikaci se známými vzory chyb. Je rychlý a vhodný pro pravidelné monitorování, ale nenajde chyby v business logice ani řetězce zranitelností. Penetrační test je manuální proces vedený zkušeným testerem, který útočí aktivně, kombinuje nástroje s vlastním úsudkem a ověřuje skutečný dopad zranitelností.

Jak dlouho trvá penetrační test webové aplikace?

Aktivní fáze testování standardně trvá 8–12 pracovních dnů, k tomu přibývá příprava reportu. Celý projekt od podpisu smlouvy po předání výsledků zabere typicky 4–6 týdnů. Délka závisí na rozsahu aplikace, počtu endpointů a zvoleném přístupu (white/grey/black box).

Naruší penetrační test provoz naší aplikace?

Za standardních podmínek ne. Test probíhá za předem dohodnutých podmínek s definovaným rozsahem a testovacími okny. Preferujeme testování na dedikovaném testovacím prostředí nebo mimo špičku. Destruktivní techniky neprovádíme bez výslovného souhlasu.

Kolik stojí penetrační test webové aplikace?

Nejčastěji 80 000 – 200 000 Kč. Závisí na počtu endpointů, složitosti autentizačních scénářů a zvoleném rozsahu. Nabídku zpracujeme do 24 hodin po bezplatné konzultaci.

Jak je zajištěna bezpečnost a mlčenlivost při penetračním testu?

Před zahájením podepisujeme NDA a Statement of Work s přesně definovaným rozsahem. Nálezy předáváme výhradně pověřeným osobám v šifrované podobě. INTEGRA má zkušenosti s projekty v bankovnictví a kritické infrastruktuře.

Co dostanu jako výstup z penetračního testu?

Výstupem je detailní bezpečnostní report obsahující: popis každé zranitelnosti s kroky k reprodukci, proof of concept (screenshot, video nebo HTTP request), CVSS 4.0 hodnocení závažnosti, doporučení k nápravě pro vývojáře a DevOps tým, executive summary pro management a CISO a volitelný retest po opravě nálezů.

Jak často penetrační test provádět?

Minimálně jednou ročně a vždy po větší změně: nasazení nových funkcí, migrace na novou infrastrukturu, přidání integrace třetí strany nebo před auditem či certifikací (NIS2, ISO 27001, PCI DSS).

Je penetrační test povinný pro NIS2, DORA nebo ISO 27001?

NIS2 — povinné pro subjekty v kritické infrastruktuře. DORA — TLPT pro finanční instituce nad určitou velikostí (od 2025). ISO 27001 — doporučen jako součást Annex A, kontrola A.12.6. PCI DSS — explicitně vyžadován pro aplikace zpracovávající platební data.

Penetrační testy webových aplikací a API

Jak testujeme webové aplikace a API

Nespoléháme na automatizované skenery. Každý test vede certifikovaný pentester, který chápe jak aplikace funguje — a hledá tam, kde skript nenajde nic.

Testujeme systematicky dle OWASP WSTG a pokrýváme všech 12 oblastí od sběru informací po business logiku. Každý nález dostane CVSS 4.0 skóre a konkrétní proof of concept.

Na každém projektu pracují minimálně dva testeři s certifikacemi OSCP, OSWP a CEH — křížová kontrola nálezů eliminuje slepá místa.

Výsledky každého testu prochází interním cross-review druhého testera ještě před předáním klientovi — ne proto, že bychom si nedůvěřovali, ale proto, že i zkušený tester má slepá místa a druhý pohled je součástí naší metodiky kvality.

Přístupy k testování

Rozsah testu přizpůsobujeme vašim potřebám. Každý přístup má jiný záběr — volba závisí na tom, jak moc chcete vidět.

Black Box

Tester přistupuje výhradně z pohledu externího útočníka — bez dokumentace, bez přístupu ke kódu. Testujeme co vidí internet. Ideální pro ověření perimetru a veřejně dostupných rozhraní.

Target

Grey Box

Nejčastější volba

Tester dostane přihlašovací údaje a dokumentaci — testuje aplikaci jako přihlášený uživatel i jako útočník bez přístupu. Nejrealističtější model reálného útoku.

TargetDocumentationCredentials

White Box

Vše jako u Grey Box, navíc tester nahlíží do zdrojového kódu. Odhaluje logické chyby a bezpečnostní nedostatky, které jsou při externím pohledu neviditelné.

TargetDocumentationCredentialsSource code

Reálné nálezy z penetračních testů

Anonymizované ukázky z testování produkčních aplikací v bankovnictví, SaaS a e-commerce. Skutečné projekty INTEGRA z roku 2024–2025.

CRITICAL · CVSS 9+

HIGH · CVSS 7–9

MEDIUM · CVSS 4–7

HIGH · CVSS 6.5 IDOR – neoprávněný přístup k datům 10 000+ organizací

KlientSaaS platforma (B2B)

Typ testuGrey Box

StackNode.js · GraphQL · MongoDB

Attack Chain

Enumerace GraphQL schématu přes introspection query
Identifikace IDOR v /api/users/{id}/data bez autorizační kontroly
Přístup k citlivým datům 10 000+ tenantů bez autentizace
Absence rate limitingu → brute-force enumerace ID v reálném čase

Náprava

Server-side autorizační kontroly na úrovni každého API requestu
Rate limiting a IP throttling na API gateway vrstvě
Zakázání GraphQL introspection v produkci

Node.js GraphQL OWASP A01 CWE-639

HIGH · CVSS 8.1 Race Condition – multiplikace finančních transakcí

KlientFinanční instituce

Typ testuGrey Box

StackNode.js · PostgreSQL · REST API

Attack Chain

Zachycení POST /api/v1/payments/internal přes Burp Suite proxy
Odeslání 10 identických requestů paralelně v rámci race window
Race condition → 4 z 10 requestů zpracovány souběžně
Výsledek: 4× multiplikace transakce — demonstrace 40 000 USD

Náprava

Idempotentní transakce s distribuovanými mutex zámky (Redis)
Databázové unikátní constrainty na transaction ID úrovni
Monitoring anomálních vzorců transakcí v reálném čase

PostgreSQL REST API OWASP A04 CWE-362

CRITICAL · CVSS 9.8 RCE přes exponovaný JDWP debug port v produkci

KlientEnterprise korporace

Typ testuBlack Box

StackJava 17 · Spring Boot · JDWP

Attack Chain

Síťový sken odhalil otevřený port 9009 (Java Debug Wire Protocol)
Identifikace aktivního JVM remote debugging v produkci
Zneužití JDWP → volání Runtime.exec() přes debugger
Vzdálené spuštění libovolných OS příkazů bez autentizace

Náprava

Okamžité vypnutí JDWP na všech produkčních serverech
Audit a zpřísnění firewallových pravidel — allowlist přístup
Automatizované skenování otevřených portů v CI/CD pipeline

Java Spring Boot OWASP A05 CWE-489

HIGH · CVSS 8.6 Bypass biometrické autentizace v bankovní iOS aplikaci

KlientBankovní instituce

Typ testuGrey Box

StackiOS · Swift · REST API

Attack Chain

Reverse engineering iOS IPA souboru nástrojem Frida
Identifikace klientské biometrické kontroly bez serverové validace
Bypass autentizace runtime patchováním přes Frida hook
Plný přístup k bankovním funkcím bez platných přihlašovacích údajů

Náprava

Přesun autentizační logiky na server — token-based auth s krátkým TTL
Implementace certificate pinning pro veškerou API komunikaci
Detekce jailbreak a runtime manipulace (Frida/Substrate detection)

iOS Swift OWASP MASTG CWE-287

MEDIUM · CVSS 6.1 Stored XSS → session hijacking a převzetí admin účtu

KlientE-commerce platforma

Typ testuBlack Box

StackReact · Django · PostgreSQL

Attack Chain

Injekce JavaScript payloadu do pole „Název produktu"
Payload vykreslen v admin dashboardu bez sanitizace výstupu
Automatická krádež session cookie administrátora
Převzetí admin účtu a plný přístup k řízení e-shopu

Náprava

Output encoding na všech uživatelsky ovlivnitelných výstupech
Nastavení HttpOnly a Secure flag na session cookies
Nasazení Content Security Policy (CSP) s strict-dynamic

React Django OWASP A03 CWE-79

Penetrační testy webových aplikací & API

Jak testujeme webové aplikace a API

Přístupy k testování

Nejčastější zranitelnosti

Reálné nálezy z penetračních testů

Zjistěte, jak je vaše aplikace skutečně zabezpečená

Žadost o vzorovou zprávu výsledků z testu