Penetrační testování webových aplikací.
Vaše webová aplikace není firemní prezentace. Je to místo, kde skutečně běží váš byznys: transakce, data zákazníků, oprávnění. Testujeme ji tam, kde automatické skenery končí — v business logice, v řízení přístupu a v kódu, který běží uživateli v prohlížeči.
Zabezpečujeme české technologické firmy, které uspěly ve světě.
Byznys dnes běží ve webových aplikacích
Web býval branou k firmě. Dnes byznys běží ve webových aplikacích: internetové bankovnictví, zákaznické portály, SaaS produkty, interní systémy v prohlížeči, API, které obsluhuje mobilní aplikaci. Zpracovávají operace, u kterých si chybu nemůžete dovolit — platby, smlouvy, osobní údaje a to, kdo je k čemu oprávněn.
Otázka „lze do aplikace proniknout?“ je proto špatně položená. Správná zní: co všechno může přihlášený uživatel provést, pokud se rozhodne pravidla nedodržet? Na této otázce stavíme penetrační testy webových aplikací.
API není samostatný produkt. Je to stejná aplikace bez uživatelského rozhraní a testujeme je ve stejném rozsahu (ASVS V13) — REST i GraphQL.
Co skener nevidí
Automatický skener posílá do backendu škodlivé vstupy — SQL injection, XSS, path traversal — a sleduje, kde aplikace selže. Totéž provádíme i my, ručně i s nástroji, ale je to ta snazší část. Skener nezná vaše role, neví, v jakém pořadí má workflow proběhnout, a nikdy nečte kód, který odesíláte do prohlížeče. Právě tam vznikají závažné nálezy.
Business logika a řízení přístupu
Aplikace se řídí pravidly, která žádný skener nezná: kdo je k čemu oprávněn, v jakém pořadí, za jakou cenu. Testujeme, co se stane, pokud je poruší někdo, kdo je zná. Záporné množství v košíku. Kupón uplatněný dvakrát ve dvou souběžných požadavcích (race condition). Přeskočení ověřovacího kroku voláním kroku následujícího. Změna ceny přímo v požadavku, kterou frontend „neumožňuje“. Na úrovni HTTP je vše validní, a skener proto nic neohlásí.
Většina aplikací má více než jednu roli a často více než jednoho zákazníka na téže instanci. Sestavíme matici oprávnění a systematicky ji prolamujeme: horizontálně (uživatel A čte data uživatele B — IDOR, BOLA), vertikálně (běžný uživatel volá administrátorskou funkci — BFLA) a mezi tenanty (klient A vidí data klienta B). Zda tlačítko v rozhraní chybí, není podstatné. Podstatné je, zda endpoint za ním požadavek odmítne.
Klient: kód, který běží v prohlížeči uživatele
Moderní aplikace je z velké části JavaScript běžící v prohlížeči. React, Angular, Vue — do klienta se odesílá celý bundle včetně funkcí, které daný uživatel nikdy neměl vidět. Analyzujeme, co je do prohlížeče skutečně doručeno: skryté administrátorské routy, feature flagy, API klíče a další secrets ponechané v kódu, source mapy a validační nebo autorizační logiku, která existuje pouze na straně klienta. Testujeme DOM XSS, zpracování postMessage, prototype pollution, konfiguraci CSP a CORS a práci s tokeny v localStorage a cookies (HttpOnly, Secure, SameSite). Vše, co běží na straně klienta, má útočník plně pod kontrolou. Test, který končí u backendu, pokrývá jen polovinu aplikace.
Jak probíhá penetrační test webové aplikace
Každý penetrační test webové aplikace má tři kroky — abyste přesně věděli, co dostáváte.
Mapování útočného povrchu
Runtime, framework, závislosti, API endpointy včetně zapomenutých starších verzí, uniklé Swagger/OpenAPI specifikace a obsah JS bundlu. Útočný povrch aplikace bývá širší, než napovídá její navigace.
Ruční testování a exploitace
Autentizace a relace: session management, JWT, OAuth/OIDC a SSO, MFA, reset hesla, rate limiting. Autorizace napříč rolemi a tenanty. Business logika. Vstupy a backend: SQLi, NoSQL injection, command injection, SSTI, XXE, SSRF, deserializace, upload souborů, request smuggling. Klientský kód. Každý nález potvrdíme reálným zneužitím (exploitací) — „potenciální zranitelnost“ v našem reportu nenajdete.
Řetězení a reálný dopad
Dílčí nálezy zřetězíme do útoku a ukážeme, kam až útočník v systému pronikne. Závažnost hodnotíme podle CVSSv3 na základě skutečného dopadu, nikoli podle skóre nástroje.
Metodika: OWASP OTG a ASVS
Rozsah definujeme podle OWASP, aby byl opakovatelný a nezávisel na konkrétním testerovi.
- OWASP OTGv4 — široké pokrytí útočného povrchu; volitelně cílený test podle OWASP Top 10 pro rychlý přehled.
- OWASP ASVS (v4 a v5) — ověření podle úrovně rizika: L1 pro aplikace bez cenných dat, L2 pro většinu firemních aplikací, L3 pro regulované a kritické systémy. ASVS v5 navíc umožňuje white-box ověření s přístupem ke zdrojovému kódu.
Black-box, grey-box nebo white-box. Jeden modul nebo celá aplikace. Nevíte, kterou úroveň potřebujete? Určíme ji na úvodním hovoru.
Report, se kterým vývojáři pracují
Manažerské shrnutí pro vedení, seznam nálezů seřazený podle závažnosti a ke každému nálezu popis, dopad, CVSS vektor, návrh opravy a kroky k reprodukci. Každý nález prochází peer-review druhým seniorním testerem. Po nasazení oprav přetestujeme.
Každý test vedou certifikovaní seniorní specialisté. Na vašich systémech se neučí žádní junioři.
Chcete vidět, jak vypadá náš výstup? Pošleme vám ukázkový report.
Výstupy z testů využijete pro NIS2, DORA, ISO 27001 i PCI-DSS.
Kolik stojí penetrační test webové aplikace?
Cena testu webové aplikace se odvíjí od velikosti aplikace, počtu rolí a zvolené hloubky (OTG vs. úroveň ASVS).
Rozsah a cenu potvrdíme na krátkém hovoru.
Náš vhled.
Cokoli odešlete do prohlížeče, čte i útočník — včetně source map, feature flagů a API klíčů.
Často kladené dotazy, vždy zodpovězeny.
Testujete v produkčním, nebo v testovacím prostředí?
Je to možné v obou. Testovací (staging) prostředí nám umožňuje provádět invazivnější testy bez rizika ovlivnění reálných uživatelů. Produkční prostředí naopak poskytuje nejvěrnější obraz reality. Přesný postup si odsouhlasíme před začátkem projektu. V případě testování produkce pečlivě koordinujeme časování a váš provozní tým je během testů v pohotovosti.
Aplikaci pravidelně skenujeme. Proč ještě penetrační test?
Skener hledá známé vzory v backendu. Nezná vaše role, neví, že kupón lze uplatnit jen jednou, a nikdy nečte obsah vašeho JS bundlu. Nejzávažnější chyby bývají tam, kde skener nemá co hledat.
Opravíte nalezené problémy? Mohu po opravě nechat aplikaci přetestovat?
Ke každé zranitelnosti dáme doporučení podle nejlepších oborových standardů, ale opravu sami neimplementujeme — díky tomu zůstáváme nezávislou třetí stranou a můžeme provést přetestování, jakmile váš tým opravy nasadí.
Testujete i single-page aplikace a API bez uživatelského rozhraní?
Ano, dnes je to typický případ. U SPA analyzujeme klientský bundle stejně důkladně jako backend; u API testujeme přímo endpointy bez závislosti na frontendu — REST i GraphQL.
Jaký je rozdíl mezi skenem zranitelností a penetračním testem?
Penetrační test se snaží najít a zneužít bezpečnostní zranitelnosti s cílem zlepšit nebo prokázat bezpečnost systému — často ručně řetězí jeden či více nálezů. Sken zranitelností najde známé zranitelnosti, ale nedokáže je kombinovat ani zneužít k dalšímu ověření bezpečnosti.
Pojďme to probrat.
Napište nám, co provozujete — SaaS, portál, bankovnictví, API — a s kolika uživatelskými rolemi aplikace pracuje. Navrhneme rozsah a úroveň testu.
Domluvit nezávaznou konzultaci ›