Zrozumienie różnych podejść do testowania jest kluczowe żeby skutecznie chronić aplikacje i systemy IT. W tym artykule zgłębiamy temat testowania podejściami white-box, black-box i gray-box, obalamy popularne mity i dostarczamy praktycznych wskazówek.
Oto trzy główne wątki omawiane w tekście:
- Definicje i charakterystyka testowania white-box, black-box i gray-box, wraz z wyjaśnieniem, jak każde z tych podejść wpływa na proces oceny bezpieczeństwa rozwiązania.
- Rozprawienie się z powszechnymi mitami dotyczącymi tych metod, które często prowadzą do nieporozumień w branży.
- Praktyczne zalecenia dotyczące wyboru odpowiedniego podejścia do testowania w zależności od dojrzałości projektu i celów bezpieczeństwa.
Zapraszamy do lektury:
Kilka mitów o kolorach skrzynek
Zacznijmy od mitów z jakimi na rynku spotykamy się najczęściej w temacie testowania podejściami white-box, black-box i gray-box:
- Testując podejściem black-box nie można mieć konta w aplikacji czy systemie. Można, bo kolor skrzynki dotyczy wiedzy na temat testowanej aplikacji czy systemu IT, a nie powierzchni ataku.
- Kolor skrzynki determinuje rodzaj oceny bezpieczeństwa. Nie determinuje, kolor skrzynki odnosi się do informacji jakie posiada tester na temat testowanego rozwiązania i nie ma tutaj większego znaczenia jaki sposób oceny bezpieczeństwa jest wybrany. Oczywiście różne kolory pasują bardziej lub mniej do konkretnych sposobów oceny bezpieczeństwa (np. ocena podatności daje najlepszą stopę zwrotu w wydaniu white-box, a test penetracyjny w wydaniu black-box), ale na upartego można je mieszać.
- Podejście white-box oznacza audyt kodu źródłowego. Nie, white-box oznacza to, że tester ma dostęp do kodu jednak audyt tego kodu wcale nie musi się odbyć. Po prostu tester wykonując pracę w momencie napotkania błędu jest w stanie wejść w kod źródłowy i zrozumieć mechanizm odpowiedzialny za ten błąd. A więc aplikacja dla testera jest białą skrzynką ponieważ można zajrzeć „do jej środka“ i zrozumieć działanie. Natomiast audyt kodu źródłowego to jeden z rodzajów oceny bezpieczeństwa i jest to osobna usługa, którą wykonuje się niezależnie od innych testów.
Z tych mitów wynika ważna uwaga: W każdym z kolorowych podejść stosujemy jakiś rodzaj oceny bezpieczeństwa (np. test penetracyjny), ale wybór sposobu oceny bezpieczeństwa jest osobną sprawą od tego jak dużo informacji na temat testowanego rozwiązania dostarczymy. O tych różnych sposobach oceny bezpieczeństwa aplikacji i systemów IT będziemy pisać w kolejnych artykułach.
Black-box, White-box, Grey-box – o co tutaj chodzi?
OK, to co te wszystkie podejścia w ogóle znaczą? Co konkretnie znaczy, że testujemy aplikację podejściem white-box albo black-box? Spieszymy z wyjaśnieniem!
🚨 Potrzebujesz testu bezpieczeństwa dla Twojej aplikacji lub systemu IT? W Bezpiecznym Kodzie, wspólnie dobierzemy optymalne podejście – white-box, black-box lub gray-box. Dowiedz się więcej →
Podejście Black-box
Testowanie podejściem black-box oznacza, że tester nie posiada żadnej wiedzy na temat wewnętrznej struktury ani wewnętrznego działania aplikacji czy systemu. A więc z perspektywy testera aplikacja jest czarną skrzynką, którą może odpytywać i dostawać od niej odpowiedzi jednak nie wie czemu odpowiedź jest taka a nie inna – może to jedynie domniemywać. Dlatego podejście black-box nazywane jest również testowaniem typu “zero-knowledge”.
W cyberbezpieczeństwie celem podejścia black-box jest imitacja realnego zewnętrznego atakującego, który w normalnym scenariuszu nie zna „wnętrzności“ naszych aplikacji czy systemów.
Podejście White-box
Z kolei testowanie podejściem white-box to odwrotność podejścia black-box. Tutaj tester posiada pełną wiedzę na temat wewnętrznej struktury i wewnętrznego działania aplikacji czy systemu. Testując tym podejściem odpowiedzi aplikacji przestają być niewiadomą – w każdej chwili można wejść do kodu źródłowego, przeczytać go, zrozumieć logikę biznesową i zrozumieć czemu odpowiedź wygląda tak, a nie inaczej. Z tego powodu podejście white-box nazywane jest również testowaniem “full-knowledge”.
W cyberbezpieczeństwie celem podejścia white-box jest maksymalizacja stopy zwrotu z oceny bezpieczeństwa. Transparentność, którą tutaj zyskujemy pozwala na szybsze i precyzyjniejsze działanie.
Podejście Gray-box
Testowanie podejściem gray-box charakteryzuje się tym, że tester posiada pewną, ale niepełną wiedzę na temat wewnętrznej struktury lub wewnętrznego działania aplikacji czy systemu. Jest to kompromis pomiędzy podejściem black-box, a podejściem white-box.
Co determinuje kolor skrzynki?
Z powyższych definicji możemy również wyciągnąć kluczowy fakt: Tylko informacje, które pogłębiają wiedzę na temat wewnętrznej struktury lub wewnętrznego działania aplikacji czy systemu zmieniają kolor skrzynki. Z czarnej na szarą (w przypadku niepełnych) lub białą (w przypadku pełnych).
Przykładowo dokumentacja może, ale nie musi wpływać na kolor skrzynki. To zależy od tego co w niej jest oraz jak dobrze jest to opisane. Jeśli jest to goły spis wszystkich punktów końcowych w aplikacji to taka dokumentacja nie wpływa na kolor skrzynki ponieważ dalej nie znamy ani działania ani wewnętrznej struktury. Jednak taka sama dokumentacja opisująca punkty końcowe wraz z parametrami, które przyjmują zmienia kolor z czarnego na szary – dalej nie wiemy jak wygląda kod, ale wiemy jak wejść w interakcję z każdą opisaną funkcjonalnością ponieważ poznaliśmy strukturę przyjmowanych danych.
Różnice pomiędzy kolorami na przykładzie
Wyobraź sobie, że masz do przetestowania aplikację, która posiada mechanizm uwierzytelniania i autoryzacji, czyli po prostu można w niej mieć konto użytkownika. Od strony technicznej oznacza to tyle, że pewne punkty końcowe, pewne funkcjonalności, nie są dostępne dla wszystkich i żeby mieć do nich dostęp najpierw trzeba się uwierzytelnić, a następnie spełnić wymogi dostępu.
Teraz popatrz, jeśli jako tester dostaniesz konto w tej aplikacji to dalej nie zwiększa to Twojej wiedzy na temat tego jaką wewnętrzną strukturę posiada ta aplikacja lub jak ona wewnętrznie działa. To co się zwiększa to powierzchnia ataku (masz dostęp do punktów wymagających uwierzytelnienia i autoryzacji), ale powierzchnia ataku sama w sobie nie pogłębia Twojej wiedzy na temat działania aplikacji. A więc nie rozjaśnia to koloru skrzynki i taka ocena bezpieczeństwa byłaby wykonywana podejściem black-box.
A teraz odwróćmy sytuację. Nie dostajesz konta w tej aplikacji, ale dostajesz kod źródłowy. W takim wypadku posiadasz mniejszą powierzchnię ataku do przetestowania (zakładając poprawność uwierzytelniania i autoryzacji), ale dostęp do kodu daje wiedzę na temat tego jak działają te funkcjonalności, do których masz dostęp. A więc ta informacja zmienia kolor skrzynki na biały – funkcjonalności, które są dostępne można dogłębnie przebadać bazując na tym, że kod źródłowy prawdę Ci powie, po prostu zakres testu jest mniejszy.
💡 Uwaga: Kod źródłowy również potrafi kłamać. Przykładowo różne kompilatory emitują różny kod wyjściowy co w przypadkach krańcowych może doprowadzić do powstania bugów i podatności pomimo identycznego kodu na wejściu. Co więcej ten sam kod kompilowany dla różnych architektur również może być bezpieczny na jednej, a podatny na innej.
Wracając do kolorów skrzynek. Testowanie podejściem gray-box ma miejsce wtedy kiedy jako tester otrzymujesz niepełne, ale pogłębiające Twoją wiedzę informacje na temat działania aplikacji.
W omawianym przypadku załóżmy, że do Twoich rąk trafił spis wszystkich punktów końcowych wraz z parametrami jakie przyjmują. Taka dokumentacja z jednej strony nie mówi nic o tym jak wewnętrznie działają te funkcje (więc nie może być to white-box), ale jednocześnie pogłębia Twoją wiedzę na temat wewnętrznej struktury aplikacji (więc nie jest to black-box). No właśnie – jest to gray-box!
Cały ten przykład można trochę urealnić: Załóżmy, że testujesz Facebooka w ramach Bug Bounty. Jakie podejście zastosujesz?
- White-box odpada, bo nie masz dostępu do kodu źródłowego.
- Gray-box odpada, bo nie masz żadnych szczególnych informacji na temat wewnętrznej struktury Facebooka ani tego jak on wewnętrznie działa.
- Zostaje podejście black-box… no ale w Facebooku możesz sobie założyć konto, a przecież według jednego z mitów założenie konta magicznie zmienia kolor skrzynki na szary. No i tu wyłapujemy sprzeczność, więc powtórzmy: Tylko informacje pogłębiające zrozumienie wewnętrznego działania aplikacji czy systemu zmieniają kolor skrzynki. Posiadanie konta rozszerza powierzchnię ataku (dostęp do większej ilości funkcjonalności), ale nie zmienia koloru skrzynki.
I przypomnijmy to co już pisaliśmy we wstępie – podejście do testowania jest luźno połączone z samym rodzajem oceny bezpieczeństwa. Przykładowo ocenę podatności aplikacji da się przeprowadzić zarówno podejściem black-box jak i white-box czy gray-box. Tak samo jest w przypadku testów penetracyjnych.
Podejście hybrydowe
Zacznijmy od wyjaśnienia co w ogóle oznacza słowo “hybryda”? Słownik języka polskiego definiuje ten wyraz jako «coś, co składa się z różnych elementów, często do siebie niepasujących» i dokładnie takie twór mamy w tym przypadku.
Z podejściem hybrydowym spotkaliśmy się po raz pierwszy (i ostatni) czytając Application Security Verification Standard (ASVS) w wersji 4. Nie jest ono tam jakoś szczegółowo opisane, ale łącząc kropki jesteśmy w stanie dojść do tego na czym ono ma polegać i przede wszystkim czemu w ogóle zostało wprowadzone jako nowy termin.
ASVS jest podzielony na poziomy i obecnie kontrolki na poziomie L1 (najniższym) w zdecydowanej większości można zweryfikować podejściem black-box, ale już poziomy L2 i L3 wymagają dostępu do kodu źródłowego. Natomiast w dokumencie autorzy najczęściej mówią o testach penetracyjnych jako formie testowania bezpieczeństwa aplikacji, a pentesty naturalnie wykonuje się podejściem black-box.
Rozwiązaniem tej sprzeczności (tj. black-boxowych pentestów z kontrolkami wymagającymi dostępu do kodu źródłowego) było wprowadzenie terminu “testowanie hybrydowe”.
A czemu autorzy ASVS nie odnieśli się po prostu do podejścia white-box? Tego nie wiemy, choć się domyślamy. Na koniec dnia nie ma to jednak znaczenia. Sądzimy, że ten sztuczny termin nie wejdzie do powszechnego użycia, bo nie wnosi nic poza zamieszaniem. Wspominamy o nim tylko dlatego, że możesz się z nim spotkać i wtedy warto kojarzyć o co w nim chodzi i skąd pochodzi.
Podsumowanie – co robić, jak żyć?
Teraz kiedy już mamy wyrównane zrozumienie tego na czym polega podejście black-box, white-box, oraz gray-box możemy przejść do odpowiedzi na pytanie: Jakie podejście wybrać?
No i oczywiście to zależy. Generalną zasadą jest to, że kolor skrzynki powinien przechodzić od jasnego do ciemnego wraz z dojrzałością bezpieczeństwa rozwiązania. To znaczy, że w momencie kiedy nasze rozwiązanie jest jeszcze świeże to najpierw powinniśmy się skupić na testowaniu bezpieczeństwa podejściem white-box, w kolejnych iteracjach testów bezpieczeństwa można przejść do gray-box, a dopiero na samym końcu powinno się testować podejściem black-box.
Na samym końcu, czyli dopiero wtedy kiedy rozwiązanie przeszło już wiele rund testowania podejściami white-box i gray-box i jest wolne od nisko wiszących podatności (tzw. low-hanging fruits)
Dlaczego? Ponieważ pierwsze iteracje testów bezpieczeństwa powinny umożliwić nam wyłapanie jak największej ilości błędów w jak najmniejszej jednostce czasu. A więc chcemy maksymalnie uprościć pracę testera po to, aby złapać i wyprowadzić jak największą ilość problemów. Dopiero, gdy nie mamy w aplikacji prostych do znalezienia błędów powinniśmy powoli utrudniać pracę testera i zwiększać “realizm” całego ćwiczenia.
Kilka uwag z punktu widzenia praktyków
Patrząc na stopę zwrotu gray-box to najgorszy rodzaj podejścia do testowania. Zarówno black-box jak i white-box oferują jasną biznesową wartość, natomiast gray-box nie daje ani tego co da white-box, ani tego co da black-box sam w sobie nie oferując nic w zamian. Z naszych obserwacji wynika, że gray-box wybierany jest wtedy kiedy żadna ze stron (ani klient ani dostawca usługi) nie do końca rozumieją różnice i cele związane z rodzajami oceny bezpieczeństwa oraz kolorami skrzynek.
Ocena bezpieczeństwa aplikacji podejściem black-box jest nieoptymalna ponieważ łatwo jest pominąć wiele funkcjonalności, które wymagają analizy kodu (np. logika warunkowa z której tylko pojedynczy warunek otwiera podatność – bez spojrzenia w kod można do tego warunku nigdy nie dotrzeć).
W zasadzie to bez cienia wątpliwości można założyć, że jeżeli aplikacja jest testowana wyłącznie podejściem black-box to na pewno są w niej podatności, które czekają na odkrycie.
Tutaj trzeba też wziąć pod uwagę, że wiele problemów bezpieczeństwa manifestuje się jako zwykłe bugi. Jeśli nie mamy wglądu w kod źródłowy to takie bugi w najgorszym przypadku mogą zostać przeoczone, a w najlepszym zaraportowane jako zwykły błąd. Jednak w sytuacji, w której tester ma dostęp do kodu źródłowego po napotkaniu pięćsetki może wejść i zobaczyć co konkretnie się tam dzieje bez tracenia czasu na próbę testowania “po omacku”.
Warto również zauważyć, że patrząc na całość szerzej to przykładowo w audytach finansowych audytor ma dostęp do dokumentów firmy i praktycznie wszystkiego czego sobie zażyczy. Natomiast testując bezpieczeństwo aplikacji czy systemów IT często zakłada się, że lepiej jest testować nie mając wszystkich informacji, bo wtedy jakby magicznie “udajemy prawdziwego atakującego”.
Oczywiście powyższe jest tylko czczym marzeniem w zdecydowanej większości przypadków. Chcemy też tutaj przypomnieć, że asymetria pomiędzy atakującymi a broniącymi jest zbyt duża. Atakujący ma tyle czasu ile sam będzie chciał go poświęcić i wystarczy, że znajdzie 1, 2, kilka słabych punktów. Z kolei ludzie pracujący nad zabezpieczeniami systemów są ograniczeni czasowo (czas typowego testu bezpieczeństwa to ok. 2 tygodnie) i teoretycznie powinni zabezpieczyć wszystko.