Black box, grey box a white box: tři úrovně znalosti při testu

Rozdíl mezi variantami není v důkladnosti testu, ale v tom, kolik z domluveného času padne na zjišťování informací, které zadavatel zná.

Black box dává smysl tam, kde je cílem ověřit, co uvidí útočník bez jakéhokoli přístupu: externí perimetr, veřejný portál, e-mailová brána. U aplikace za přihlášením se ale velká část času spotřebuje na získání účtu a zmapování funkcí, tedy na práci, kterou grey box vyřeší předáním přihlašovacích údajů.

Argument pro black box zní, že je realističtější. Stojí na rovnici, která neplatí: čím míň toho tester ví, tím věrněji prý simuluje útočníka. Potíž je v poměru času. Útočník může na jednu firmu tlačit měsíce a nic ho to nestojí, tester má patnáct dní. Simulovat neznalost proto znamená koupit si průzkum místo nálezů.

• Testuje se vnější perimetr a otázka zní, co je odtud vůbec vidět.
• Součástí zadání je i ověření, jestli útok někdo zachytí.
• Aplikace je veřejná a registraci si tester může založit sám.
• Zadavatel potřebuje doklad pro protistranu, že test proběhl bez vnitřních informací.

Zvolte black box, pokud testujete to, co je vidět z internetu, a ne to, co se děje po přihlášení.

Grey box je u webových aplikací a API výchozí volbou, protože tester dostane účet pro každou roli a může rovnou zkoušet, jestli se dá mezi rolemi přelézt. Chyby v autorizaci, tedy přístup k cizím datům po legitimním přihlášení, se přitom bez účtu pro každou roli otestovat nedají.

Předání účtů zároveň řeší praktický problém: bez nich tester netuší, že aplikace má kromě běžného uživatele ještě roli schvalovatele a roli správce pobočky. Rozsah kontrol, které projde, se řídí metodikou, u webu nejčastěji podle OWASP Web Security Testing Guide, ne úrovní znalosti.

Zvolte grey box, pokud má aplikace víc než jednu uživatelskou roli a záleží vám na tom, aby se testovaly všechny.

White box se vyplatí u aplikací, které firma sama vyvíjí a kde je hodně vlastní logiky: platební toky, výpočty limitů, integrace na bankovní rozhraní. S kódem tester ověří i větve, na které se z rozhraní běžně nedostane, a u nálezu rovnou ukáže místo, které je potřeba opravit.

Obava, že předáním kódu firma testeru něco prozradí, míří vedle. Kód nezvyšuje závažnost nálezu, jen zkracuje cestu k němu. Co s ním tester smí a nesmí, se stejně řeší smlouvou o mlčenlivosti a pravidly zapojení, ne tím, že se mu repozitář zatají.

• Aplikaci vyvíjíte sami nebo máte ke kódu přístup přes dodavatele.
• Podstatná část rizika je v logice, ne v konfiguraci.
• Test má navázat na revizi kódu nebo na opravy z minulého kola.
• Aplikace zpracovává platby, zdravotní údaje nebo jiná citlivá data.

U aplikace se úrovní znalosti myslí účty, dokumentace a zdrojový kód. U sítě jde o něco jiného: jestli tester předem zná topologii, rozsahy IP a seznam systémů, nebo si je musí najít sám. Stejné slovo v poptávce na test aplikace a jejích rolí a na test sítí a serverů proto znamená pokaždé jinou přípravu.

U interní sítě navíc přibývá třetí proměnná, kterou boxová terminologie vůbec nepokrývá: s jakým oprávněním tester začíná. Jestli dostane běžný doménový účet, nebo se má nejdřív dostat do sítě sám, změní výsledek testu víc než to, kolik dokumentace předem přečetl.

Seznam podkladů patří do zadání, ne až do kick-off hovoru. Když se účty a testovací data řeší až po zahájení, ubývá čas z testování, a to bez ohledu na zvolenou variantu.