Black box, grey box czy white box - który test penetracyjny wybrać

Każdy test penetracyjny zaczyna się od decyzji, ile tester ma wiedzieć o systemie i do czego dostanie dostęp. Dwie oferty na „pentest portalu klienta” - jedna w podejściu black box, druga grey box - to w praktyce dwie różne usługi z różnym wynikiem, a white box dokłada do nich trzecią perspektywę. Porównujemy black box, grey box i white box, pokazujemy, czego każde z tych podejść zwykle nie wykryje, i podpowiadamy, które wybrać w ośmiu typowych sytuacjach.

Black box, grey box i white box - porównanie

Podejście określa, z jaką wiedzą i z jakim dostępem tester zaczyna pracę. Według definicji NIST black box zakłada brak wiedzy o wewnętrznej strukturze i szczegółach implementacji badanego obiektu, grey box - częściową wiedzę, a white box - wiedzę jawną i obszerną. Różnica między black box a white box jest więc różnicą stopnia: to dwa krańce tej samej skali, a grey box leży między nimi.

Najważniejszy jest wiersz „czego zwykle nie wykryje” - pokazuje, jakie ryzyko zostaje poza testem, jeśli wybierzesz tylko jedno podejście.

Testy penetracyjne black box - co sprawdzają i gdzie się kończą

Test penetracyjny black box zaczyna się jak prawdziwy atak z internetu: tester dostaje nazwę domeny albo zakres adresów i sam ustala, co jest wystawione na zewnątrz. Zasoby znalezione poza listą celów testuje dopiero po potwierdzeniu, że należą do firmy i są objęte zgodą. Test obejmuje przede wszystkim:

• rekonesans - domeny, subdomeny i zapomniane serwery, np. stare środowiska testowe,
• usługi wystawione do internetu i ich wersje, w tym oprogramowanie ze znanymi podatnościami (CVE),
• konfigurację TLS i nagłówki HTTP oraz pliki, które nie powinny być publiczne, np. kopie zapasowe,
• funkcje dostępne przed logowaniem - rejestrację, logowanie, reset hasła.

Przykład demonstracyjny: pod subdomeną środowiska testowego działa zapomniana kopia panelu administracyjnego sprzed roku, bez uwierzytelniania wieloskładnikowego. Z głównej aplikacji nic do niej nie prowadzi, ale rekonesans ją znajduje - tak samo jak znalazłby ją atakujący.

Ograniczenie: czas zamiast wiedzy

Brytyjskie Narodowe Centrum Cyberbezpieczeństwa (NCSC) zauważa, że testowanie bez informacji o systemie dokładniej odwzorowuje ryzyko ze strony atakujących niezwiązanych z organizacją, ale brak informacji może sprawić, że część podatności pozostanie nieodkryta w czasie przeznaczonym na test. Test ma ustalony budżet, a atakujący może rozpoznawać system tak długo, jak chce. Część czasu testu pochłania więc odkrywanie tego, co zespół Twojej firmy wie od pierwszego dnia. Przewodnik OWASP Web Security Testing Guide (WSTG) wskazuje drugie ograniczenie: test z zewnątrz sprawdza tylko to, co da się osiągnąć przez interfejs („front-impact testing only”).

Kiedy black box wystarczy

Sam black box wystarczy, gdy testujesz stronę firmową bez kont użytkowników, kontrolujesz perymetr po zmianach w infrastrukturze albo sprawdzasz po wdrożeniu system, którego funkcje dostępne po zalogowaniu przetestowano wcześniej. Pamiętaj, że to nie to samo co skan podatności: tester ręcznie potwierdza ustalenia i łączy słabości w scenariusze ataku. Różnice wyjaśniamy w artykule czym skan podatności różni się od pentestu.

Testy grey box - standard dla aplikacji z logowaniem

Grey box to test z częściową wiedzą: tester dostaje konta w systemie i podstawową dokumentację, ale nie kod. Kluczowe są konta po dwa w każdej roli. Dwa konta w tej samej roli pozwalają sprawdzić, czy jeden użytkownik widzi dane drugiego, a konta różnych ról - czy zwykły użytkownik wywoła funkcję administratora. Testy grey box wykrywają przede wszystkim:

• IDOR i inne błędy kontroli dostępu do obiektów - faktur, dokumentów, zamówień,
• eskalację uprawnień - pracownik wykonuje operację zastrzeżoną dla kierownika albo administratora,
• brak separacji danych między klientami w systemach SaaS,
• błędy logiki procesów - np. ponowne użycie jednorazowego kodu rabatowego, pominięcie etapu akceptacji czy zmianę kwoty po zatwierdzeniu.

Przykład demonstracyjny: w aplikacji do obiegu faktur przycisk „Zatwierdź płatność” widzi tylko kierownik. Tester zalogowany na środowisku testowym jako pracownik z rolą „przeglądający” wysyła to samo żądanie, które wysyła przycisk, i płatność zostaje zatwierdzona - interfejs ukrywał funkcję, ale serwer nie sprawdzał roli. W teście bez kont w obu rolach tego błędu zwykle nie widać.

Dlaczego grey box odpowiada realnym atakom

Atakujący nie musi przełamywać zabezpieczeń z zewnątrz, żeby dostać się do funkcji dostępnych po zalogowaniu. W systemie z otwartą rejestracją wystarczy założyć konto jak każdy klient, a hasło pracownika, używane także w innym serwisie, może wyciec razem z bazą tego serwisu. Grey box zaczyna właśnie od tego punktu, a czas, który w black box pochłania rozpoznanie, przeznacza na sprawdzanie uprawnień i logiki biznesowej.

White box - kiedy dać testerowi kod

White box to test z pełną wiedzą: tester ma dokumentację, opis architektury, konfigurację i kod źródłowy. Kod pokazuje to, do czego nie prowadzi żaden ekran: zadania uruchamiane w tle, importy, integracje i stare endpointy pominięte w dokumentacji, a także sekrety w repozytorium i sposób użycia kryptografii.

Przykład demonstracyjny: token resetu hasła powstaje ze znacznika czasu i identyfikatora użytkownika, a nie z kryptograficznie bezpiecznego generatora liczb losowych. Z zewnątrz tokeny wyglądają na losowe, a w kodzie od razu widać, że da się je przewidzieć.

OWASP WSTG wymienia mocne strony przeglądu kodu - kompletność i dokładność - ale też ograniczenia: trudno w nim wykryć błędy, które pojawiają się dopiero w działającym systemie, a kod wdrożony na produkcji może się różnić od analizowanego. Dlatego white box najlepiej łączyć z testem działającej aplikacji.

White box a audyt kodu źródłowego

W naszej ofercie white box to Rewizja kodu źródłowego - dodatek do pakietu Audyt Kompleksowy, więc przegląd kodu zawsze łączymy z testem działającej aplikacji. Dla kogo jest ta usługa, jak przebiega i jak opisujemy podatność z miejscem w kodzie, pokazujemy na stronie audyt kodu źródłowego.

Który test wybrać - 8 typowych sytuacji

Wybór zależy od trzech rzeczy: czy użytkownicy się logują, jakie dane i operacje obsługuje system oraz czy możesz udostępnić kod. Poniżej osiem typowych sytuacji z podpowiedzią, które podejście - black box, grey box czy white box - pasuje do każdej z nich.

Zakres testów interfejsów opisujemy na stronie testy bezpieczeństwa API, a portali i sklepów - na stronie testy penetracyjne aplikacji webowych. W testach infrastruktury zamiast podziału na black, grey i white box częściej mówi się o teście zewnętrznym i wewnętrznym; test wewnętrzny z kontem zwykłego użytkownika domeny jest bliski podejściu grey box. Jego zakres pokazujemy w części o teście sieci wewnętrznej i Active Directory.

Drzewo decyzji w czterech pytaniach

1. Czy użytkownicy logują się do systemu? Jeśli nie - wystarczy black box. Jeśli tak - podstawą jest grey box z kontami po dwa w każdej roli.
2. Czy system jest dostępny z internetu? Jeśli tak - dodaj w tym samym projekcie część black box.
3. Czy błąd w którymś module oznaczałby wyciek danych wrażliwych albo utratę pieniędzy? Jeśli tak - rozważ white box dla tych modułów.
4. Czy możesz udostępnić kod? Jeśli nie masz do niego praw albo dostawca się nie zgadza, zostaje grey box. Jeśli możesz - ogranicz white box do modułów z pytania 3.

Łączenie podejść w jednym projekcie

Podejścia się nie wykluczają. Najczęstsze połączenie to black box i grey box: najpierw sprawdzamy to, co widać z internetu, potem wszystko, co jest dostępne po zalogowaniu. Tak jest zbudowany pakiet Audyt Kompleksowy, który obejmuje też retest po naprawach, a w raporcie opisujemy obie części rozdzielnie. Tam, gdzie błąd kosztuje najwięcej, dokładamy rewizję kodu źródłowego (white box). Co obejmuje każdy wariant, pokazujemy w zestawieniu pakietów testów penetracyjnych.

Koszt i czas - od czego naprawdę zależą

W internecie można przeczytać zarówno to, że black box jest najtańszy, jak i to, że trwa najdłużej. Obie opinie biorą się z porównywania różnych rzeczy: cena i czas zależą przede wszystkim od zakresu, a podejście ten zakres zmienia.

• black box - przy tym samym nakładzie pracy obejmie mniej funkcji, bo część czasu pochłania rozpoznanie,
• grey box - zakres rośnie razem z liczbą ról i funkcji, bo uprawnienia trzeba sprawdzić dla każdej kombinacji roli i funkcji,
• white box - dochodzi przegląd kodu, którego pracochłonność zależy od wielkości kodu, technologii i liczby modułów krytycznych.

Dobrze przygotowane konta i dokumentacja skracają rozpoznanie, więc więcej czasu zostaje na same testy. Kwot nie podajemy, bo pod tą samą nazwą usługi kryją się bardzo różne zakresy - zamiast nich opisujemy czynniki wyceny testu penetracyjnego.

Co przygotować do każdego podejścia

• Black box: pisemna zgoda właściciela systemu, lista celów (domeny, adresy IP, aplikacje) i wyłączeń, okna czasowe, kontakt awaryjny oraz decyzja, czy test ma przechodzić przez ochronę typu WAF.
• Grey box - dodatkowo: konta po dwa w każdej roli z danymi, które można bezpiecznie zmieniać, opis ról i uprawnień, specyfikacja API oraz środowisko testowe będące kopią produkcji albo zgoda na nieinwazyjny test na produkcji.
• White box - dodatkowo: dostęp do kodu i opis architektury; pełną listę podajemy w części o przygotowaniu kodu do audytu.

Listę kontrolną z terminami - od zgody na test do porządków po nim - znajdziesz w artykule jak przygotować firmę do testu penetracyjnego, a przebieg samego testu - w artykule jak przebiega test penetracyjny krok po kroku.

Co mówią przepisy KSC i DORA o podejściu do testu

Przepisy wymagają testowania i oceny skuteczności zabezpieczeń, ale podejścia nie wskazują. W ustawie o KSC wśród elementów systemu zarządzania bezpieczeństwem informacji (art. 8 ust. 1) są m.in.:

• Bezpieczeństwo systemów i testowanie - bezpieczeństwo przy nabywaniu, rozwoju, utrzymaniu i eksploatacji systemu, w tym testowanie systemu informacyjnego (art. 8 ust. 1 pkt 2 lit. b).
• Ocena skuteczności środków - polityki i procedury oceny skuteczności środków technicznych i organizacyjnych (art. 8 ust. 1 pkt 2 lit. h).

W sektorze finansowym stosuje się DORA. Podmioty finansowe inne niż mikroprzedsiębiorstwa ustanawiają oparty na ryzyku program testowania operacyjnej odporności cyfrowej (art. 24 ust. 1-3). Wśród testów wymienionych przykładowo w art. 25 ust. 1 są osobno testy penetracyjne oraz przeglądy kodu źródłowego, gdy jest to wykonalne - przegląd kodu występuje więc obok testu penetracyjnego, a nie zamiast niego. Rozporządzenie delegowane do DORA dodaje wymóg dotyczący procesu wytwórczego: procedura rozwoju systemów obejmuje przeglądy kodu źródłowego z testami statycznymi i dynamicznymi, w tym testy bezpieczeństwa aplikacji internetowych (art. 16 ust. 3 rozporządzenia delegowanego (UE) 2024/1774). Zaawansowane testy TLPT to osobna kategoria - wyjaśniamy, czym TLPT różni się od testu penetracyjnego.

Najczęstsze błędy przy wyborze podejścia

• „Black box jest najbardziej realistyczny, więc najlepszy.” Perspektywa jest realistyczna, ale czas testu - ograniczony, a w aplikacjach z kontami użytkowników najgroźniejsze błędy kryją się za ekranem logowania.
• Grey box z jednym kontem administratora. Na koncie, które widzi wszystko, nie sprawdzisz dostępu do cudzych danych.
• White box bez testu działającej aplikacji. Błędy konfiguracji serwera czy chmury widać dopiero w działającym systemie.
• Porównywanie ofert opartych na różnych podejściach. Zestawiając ofertę black box z ofertą grey box, porównujesz ceny dwóch różnych usług. Jak wyrównać zakres przed porównaniem, piszemy w artykule jak porównać oferty na testy penetracyjne.

Black box w pentestach a testy czarnej skrzynki w QA

Nazwa „testy czarnej skrzynki” ma dwa znaczenia. W testowaniu oprogramowania (QA) to technika projektowania testów funkcjonalnych na podstawie specyfikacji - NIST opisuje ją jako badanie funkcjonalności aplikacji bez wglądu w jej wewnętrzną strukturę. W pentestach ta sama nazwa opisuje wiedzę i dostęp atakującego na starcie. Testy QA sprawdzają, czy system robi to, co powinien, a pentest - czy da się go zmusić do tego, czego robić nie powinien.

Jak możemy pomóc

Testujemy aplikacje webowe i mobilne, API, infrastrukturę, chmurę i kod źródłowy - jednorazowo albo cyklicznie. Podejście dobieramy po krótkiej rozmowie zakresowej: dla systemów z logowaniem zwykle proponujemy Audyt Kompleksowy, a gdy liczy się każda ścieżka w kodzie - także rewizję kodu. Jeśli najpierw potrzebujesz szybkiej oceny tego, co widać z internetu, punktem wejścia jest Audyt Zewnętrzny.

Zakres i metodykę testów przedstawiamy na stronie testy penetracyjne, a od czego zależy cena - w cenniku testów penetracyjnych.