Jedno číslo
Zákazník se přihlásí do nového portálu a otevře si svou fakturu.
V adrese stránky si všimne čísla dokumentu. Zkusí ho změnit.
A aplikace mu zobrazí fakturu jiného zákazníka.
Neprolomil hesloHeslo je obecný prostředek ověření totožnosti (autentizaci) uživatele, kterým nemusí nutně být pouze... Více. Neobešel přihlášeníOvěření totožnosti. Služba zjišťuje, zda jste opravdu ten, za koho se vydáváte. Více. Nepoužil žádný speciální nástroj.
Jen změnil jedno číslo.
PřihlášeníOvěření totožnosti. Služba zjišťuje, zda jste opravdu ten, za koho se vydáváte. Více přitom funguje. Faktury se správně načítají. Běžný test aplikace prošel.
Aplikace ověřila, že je uživatel přihlášený. Už ale neověřila, jestli smí zobrazit právě tento dokument.
Funkce fungovala.
Jen ne bezpečně.
Prošlo to předáním
Při předání aplikace se obvykle kontroluje očekávaný postup.
Uživatel se přihlásí, vyplní formulář, odešle objednávku nebo stáhne dokument. Administrátor upraví záznam. Data se uloží a potřebné informace se předají dál.
Taková kontrola odpovídá na důležitou otázku:
Dělá aplikace to, co jsme si objednali?
Neodpovídá ale automaticky na jinou:
Co aplikace dovolí člověku, který ji použije jinak, než se očekává?
Může běžný uživatel otevřít dokument někoho jiného? Dostane se k funkci určené správci? Uvidí informace, které mu nepatří? Dokáže přeskočit část procesu?
Bezpečnostní chybaSlabina v aplikaci, zařízení nebo nastavení, kterou lze zneužít k útoku. Více se přitom nemusí projevit pádem aplikace nebo chybovou hláškou.
Naopak. Aplikace požadavek bez problému provede.
Jen pro nesprávného uživatele nebo nad cizími daty.
Přebíráte nebo spouštíte webovou aplikaci?
Pošlete stručný popis aplikace, typů uživatelů a plánovaného termínu předání. Řeknu vám, jestli odpovídá Bezpečnostní kontrole webové aplikace, nebo potřebuje Penetrační test na míru.
Když vývoj zrychlí
AI nástroje dokážou vývoj webových aplikací výrazně urychlit.
Pomohou vytvořit přihlášeníOvěření totožnosti. Služba zjišťuje, zda jste opravdu ten, za koho se vydáváte. Více, administraci, formuláře, uploady, exporty nebo propojení s dalšími systémy. Funkční verze tak může vzniknout velmi rychle.
To samo o sobě není problém.
Problém nastává, když se rychlost vývoje zamění za ověření výsledku.
Každá nová funkce totiž přináší rozhodnutí, která musí aplikace dělat správně:
- Kdo smí tuto stránku otevřít?
- Komu patří tento dokument?
- Kdo může záznam změnit?
- Co smí běžný uživatel a co správce?
- Jaká data může aplikace zobrazit?
AI může funkci vytvořit. Pořád je ale potřeba ověřit, koho přes ni aplikace pustí dovnitř a k čemu mu umožní přístup.
To platí i pro běžný vývoj. U aplikací vytvořených nebo výrazně urychlených pomocí AI je ale snadné bezpečnostní kontrolu přeskočit, protože funkční výsledek vypadá hotově velmi brzy.
Jiný pohled
Bezpečnostní nález automaticky neznamená, že dodavatel nebo vývojář odvedl špatnou práci.
Vývojový tým musí dodat domluvené funkce, propojit jednotlivé části, opravit chyby a zajistit, aby aplikace fungovala jako celek.
Bezpečnost má být součástí kvalitního vývoje. Nezávislá kontrola má ale jiný účel.
Vývojář se například ptá:
Dokáže zákazník zobrazit svou fakturu?
Bezpečnostní kontrola přidává druhou otázku:
Dokáže zobrazit také fakturu někoho jiného?
Nezkouší jen očekávané použití. Prověřuje také změny identifikátorů, obcházení rolí, přístup k cizím datům a další situace, se kterými běžný předávací scénář nemusí počítat.
Vývojové testování a nezávislá bezpečnostní kontrola si nekonkurují.
Každé odpovídá na jinou otázku.
Dokud je čas
Nejlepší chvíle pro nezávislou kontrolu je před finálním převzetím, spuštěním nebo doplacením projektu.
Dodavatel má aplikaci stále v kontextu. Vývojový tým je dostupný. Dokumentace a testovací prostředí jsou po ruce.
Nalezené problémy lze řešit během aktivní spolupráce, ne až ve chvíli, kdy aplikaci používají zákazníci a původní tým už pracuje na jiném projektu.
Firma navíc získá podklad pro rozhodnutí:
- co je potřeba opravit před spuštěním;
- co má největší praktický dopad;
- co lze řešit později;
- zda stačí omezená bezpečnostní kontrola;
- nebo zda projekt potřebuje širší penetrační test.
Kontrola má smysl i u aplikace, která už běží. Předání je ale přirozený okamžik, kdy firma přebírá odpovědnost za systém, jeho uživatele a data.
Je lepší vědět, co skutečně přebírá.
Ne razítko
Smyslem bezpečnostní kontroly není vydat potvrzení, že je aplikace jednou provždy bezpečná.
Takovou záruku poctivě dát nelze. Každý test probíhá v konkrétním čase a v předem domluveném rozsahu.
Výsledkem ale nemá být ani automatický výpis technických zkratek bez vysvětlení.
Klient potřebuje vědět:
- co bylo nalezeno;
- jaký může mít problém dopad;
- jak je závažný;
- jak ho může vývojář ověřit;
- co má opravit jako první.
Výstupem má být prioritizovaný report a konkrétní doporučení k nápravě.
Ne obecné varování. Podklad pro opravy a další rozhodování.
Kontrola, nebo pentest?
Pro jednu menší webovou aplikaci může být vhodná Bezpečnostní kontrola webové aplikace.
Má předem omezený rozsah a zaměřuje se na nejdůležitější části aplikace: přihlášeníOvěření totožnosti. Služba zjišťuje, zda jste opravdu ten, za koho se vydáváte. Více, uživatelské role, oprávněníRozhodnutí, co smí přihlášený uživatel vidět nebo dělat. Více, hlavní procesy, práci s neveřejnými daty, formuláře, uploady a API.
Výstupem je prioritizovaný report, doporučení k nápravě a závěrečná konzultace.
Cena je 35 000 Kč za předem omezený rozsah.
U větší nebo citlivější aplikace dává větší smysl Penetrační test na míru. Typicky jde o systémy s více uživatelskými rolemi, několika prostředími, rozsáhlejším API, větším počtem integrací nebo konkrétními rizikovými scénáři.
Také pentest má jasně domluvený rozsah. Ten se stanoví individuálně podle aplikace, cíle testu a požadované hloubky.
Cena se určí po krátkém scopu.
Před podpisem
Funkční předání potvrzuje, že aplikace dělá to, co bylo objednané.
Neříká ale automaticky, kdo se přes její funkce dostane k jakým účtům, dokumentům a datům.
AI může vývoj výrazně urychlit. Nezávislou kontrolu výsledku ale nenahradí.
Před finálním převzetím proto dává smysl položit ještě jednu otázku:
Zkoušel někdo aplikaci použít také jinak než podle návodu?
Pošlete stručný popis aplikace, typů uživatelů, prostředí a plánovaného termínu předání.
Podle rozsahu doporučím Bezpečnostní kontrolu webové aplikace, nebo Penetrační test na míru. Pokud ani jedna varianta nebude pro projekt dávat smysl, řeknu to.
