Praktická metodika · Bezpečnostní výzkum
Dobře napsaný bezpečnostní report pomáhá týmu rychle pochopit tři věci: co se stalo, za jakých podmínek se problém projeví a jaké riziko z něj skutečně plyne. Nemusí být dlouhý ani plný odborných zkratek. Musí být přesný, ověřitelný a bezpečný pro lidi, kteří budou nález prověřovat. Následující postup je určený pro autorizovaný výzkum, bug bounty programy a koordinované hlášení zranitelností. Testujte pouze systémy, pro které máte výslovné oprávnění.
Nejdřív ověřte rozsah a pravidla
Ještě před prvním testem si přečtěte podmínky programu nebo zveřejněnou politiku oznamování zranitelností. Ověřte, které domény, aplikace a účty jsou součástí rozsahu, jaké typy testování jsou povolené a které činnosti jsou výslovně vyloučené. Pravidla mohou omezovat automatizované skenování, zátěžové testy, sociální inženýrství nebo práci s produkčními daty. Pokud text není jednoznačný, nevyvozujte si oprávnění sami; požádejte správce programu o upřesnění.
Oprávnění není jednorázová formalita. Když během testu zjistíte, že další krok by mohl zasáhnout cizí účet, změnit důležitá data nebo narušit dostupnost služby, zastavte se. V reportu pak popište, co jste ověřili a kde jste záměrně skončili. Jasná hranice testu pomáhá triáži i organizaci, která nález přijímá.
Jeden report, jeden hlavní problém
Report se lépe posuzuje, když popisuje jednu zranitelnost nebo jeden úzce související řetězec chyb. Pokud jste našli několik nezávislých problémů, připravte pro každý samostatné hlášení. Tím se sníží riziko, že se část informací přehlédne, a každý nález může dostat vlastní prioritu, odpovědnou osobu i opravu.
Výjimkou je případ, kdy jednotlivé kroky tvoří jediný bezpečnostní scénář. V takovém případě hned v úvodu vysvětlete, proč spolu souvisejí, a ukažte, která část je podmínkou a která následkem. Nepropojujte nesouvisející chyby jen proto, že se objevily na stejné doméně nebo ve stejném testu.
Začněte stručným a výstižným názvem
Název je první informace, podle které tým report vyhledá a zařadí. Popište typ problému a místo, kterého se týká, ale nezveřejňujte v titulku citlivá data ani detailní návod k jeho zneužití. Místo obecného „Bezpečnostní chyba“ zvolte formulaci, která odliší konkrétní funkci nebo hranici oprávnění. Název má být krátký; vysvětlení patří do shrnutí.
První odstavec by měl v několika větách říct, jaký systém nebo funkce jsou dotčené, jaké oprávnění je potřeba a jaký dopad jste bezpečně ověřili. Oddělte pozorování od odhadu. Pokud některou část dopadu pouze předpokládáte, označte ji jako hypotézu a napište, co by bylo potřeba ověřit, aniž byste pokračovali za povolený rozsah.
Popište reprodukci tak, aby ji šlo bezpečně zopakovat
Uveďte předpoklady a očíslované kroky. Napište, jaký testovací účet nebo role byly použity, jaká stránka či funkce byla otevřena a jaký výsledek se objevil. Ke každému kroku patří očekávané chování a skutečné chování. Pokud se chyba projeví jen při určité konfiguraci, verzi aplikace nebo nastavení účtu, doplňte tuto informaci. Neuvádějte hesla, aktivní přístupové tokeny, soukromé klíče ani jiné přihlašovací údaje.
Reprodukce má být minimální. Zvolte nejkratší postup, který ukazuje rozdíl mezi očekávaným a skutečným chováním. Použijte vlastní testovací účet, vratnou akci a syntetická data. Není třeba prokazovat maximální možný rozsah dopadu tím, že otevřete další účty, získáte cizí záznamy nebo změníte stav produkční služby. Bezpečný důkaz popisuje hranici problému, ne jeho nejškodlivější možné zneužití.
Důkazy vybírejte úsporně a redigujte je
Screenshot, krátký záznam požadavku nebo výstup z testovacího prostředí může report výrazně zpřehlednit. Přiložte jen to, co skutečně pomáhá potvrdit nález. Každý důkaz popište: co ukazuje, v jakém kroku vznikl a která část je důležitá. Pokud existuje bezpečný testovací účet, uveďte jeho roli, ne jeho skutečné přihlašovací údaje.
Před odesláním zkontrolujte, zda příloha neobsahuje osobní údaje, cookies, autorizační hlavičky, interní adresy, tajné klíče nebo data jiných uživatelů. Citlivé části začerněte tak, aby je nešlo obnovit z původního souboru. Pokud organizace vyžaduje důvěrné důkazy, použijte její schválený zabezpečený kanál a ověřte, komu budou dostupné. Samotný report by měl obsahovat tolik detailů, kolik je třeba k ověření, ne celý obsah systému, do kterého jste nahlédli.
Vysvětlete dopad konkrétně, bez přehánění
Technický název chyby sám o sobě neurčuje její závažnost. Popište, kdo by mohl problém využít, jaké oprávnění by potřeboval a jaký konkrétní následek je doložený. Rozlišujte mezi přístupem k vlastnímu testovacímu účtu, přístupem k údajům jiné role a pouhou teoretickou možností dalšího útoku. Pokud jste dopad neověřili, řekněte to přímo.
Užitečný popis dopadu bývá věcný a podmíněný: „Uživatel s rolí X může za podmínek Y provést akci Z.“ Vyhněte se tvrzením typu „úplné převzetí systému“, pokud report neukazuje, jak k tomu dochází. Přiměřená formulace zvyšuje důvěryhodnost nálezu a pomáhá týmu rozhodnout o prioritě podle skutečného rizika, nikoli podle dramatického označení.
Návrh opravy oddělte od prokázaných faktů
Pokud máte promyšlený návrh opravy, přidejte ho jako doporučení, ne jako podmínku přijetí reportu. Popište princip: například ověřit oprávnění na serveru, svázat citlivou akci s ověřeným požadavkem nebo omezit přístup podle role. Konkrétní úprava závisí na architektuře aplikace, kterou nemusíte znát.
Rozlišujte mezi jistým zjištěním a hypotézou o kořenové příčině. Můžete napsat: „Pozorované chování naznačuje, že kontrola může probíhat pouze v klientské části; prosím ověřte také serverovou autorizaci.“ Taková formulace nabízí užitečný směr, ale nepředstírá, že máte přístup ke zdrojovému kódu nebo internímu návrhu.
Oznamujte soukromě a koordinujte další postup
Najděte oficiální kontaktní cestu uvedenou v programu nebo bezpečnostní politice. Neposílejte kompletní reprodukci do veřejného issue trackeru, komentáře na sociálních sítích ani do diskuse, kterou mohou číst další uživatelé. V prvním kontaktu stručně popište povahu nálezu a požádejte o bezpečný způsob předání detailů, pokud si nejste jistí kanálem.
Po odeslání si uchovejte časovou osu komunikace a potvrzení o přijetí. Respektujte dohodnutý postup zveřejnění a nereportujte stejný nález veřejně jen proto, že odpověď nepřišla okamžitě. Pokud organizace nereaguje, postupujte podle její politiky nebo se nejprve zeptejte na další kontakt. Report nemá být spojen s nátlakem, hrozbou zveřejnění ani požadavkem na odměnu mimo pravidla programu.
Retestujte opravu pouze v dohodnutém rozsahu
Když tým oznámí opravu, domluvte si, zda je žádoucí a povolené provést retest. Ověřte původní reprodukční krok v bezpečném prostředí a zaznamenejte, zda se očekávané chování změnilo. Nepokračujte automaticky v širším průzkumu a nezkoušejte nové cesty, které nebyly součástí původního povolení. Stručné potvrzení pomůže uzavřít report a může upozornit na neúplnou opravu.
Pokud problém přetrvává, pošlete aktualizaci stejného hlášení s přesným výsledkem retestu. Vyhněte se zakládání duplicitních reportů. Když oprava funguje, poděkujte za koordinaci a před případným veřejným shrnutím znovu ověřte, jaké informace lze sdílet a kdy.
Časté chyby, které report zbytečně oslabují
- Nejasný rozsah: není uvedeno, který systém, funkce nebo role byly testovány.
- Chybějící očekávaný výsledek: čtenář nepozná, proč je skutečné chování problém.
- Příliš mnoho důkazů: velké archivy a nesouvisející výpisy zakryjí klíčovou informaci.
- Neověřený dopad: hypotéza je prezentována jako prokázaný následek.
- Citlivá data v příloze: report neprošel kontrolou tokenů, osobních údajů a cizích záznamů.
- Test mimo pravidla: další ověřování pokračovalo, přestože rozsah nebyl jasný.
Tyto nedostatky lze často napravit jednoduchou závěrečnou kontrolou: přečíst report očima inženýra, který neviděl test, odstranit vše, co není nutné, a ověřit, že každý krok je bezpečně reprodukovatelný.
Jednoduchá osnova reportu
- Název: typ problému a dotčená funkce.
- Stručné shrnutí: co se děje, za jakých podmínek a co je potvrzené.
- Rozsah a předpoklady: testovaný systém, role, účet a prostředí.
- Bezpečná reprodukce: očíslované kroky, očekávaný a skutečný výsledek.
- Dopad: realistický následek a omezení, která jste při testu dodrželi.
- Důkazy: minimální redigované přílohy a jejich vysvětlení.
- Doporučení: možný směr opravy, jasně oddělený od ověřených faktů.
Pokud chcete navázat na pravidla bezpečného výzkumu, přečtěte si stránku Responsible disclosure & Bug Bounty. Pro další vzdělávací materiály pokračujte do sekce Learning notes; přehled nástrojů a laboratorních poznámek je na stránce Tools & labs. Pro otázky k bezpečnému oznámení lze využít také kontaktní stránku.
Nejlepší report není ten nejdelší. Je to zpráva, která chrání uživatele, respektuje rozsah oprávnění a dává týmu dostatek přesných informací k tomu, aby problém mohl ověřit, opravit a znovu otestovat.
Pokud tým teprve plánuje novou funkci, navazuje na tento postup také náš praktický průvodce modelováním hrozeb webové aplikace, který pomáhá určit aktiva, hranice důvěry a bezpečné ověření ještě před vydáním změny.