Skrzynki montażowe AP – co warto o nich wiedzieć?
31 sierpnia, 2021
Firewall NGFW – na co zwrócić uwagę przy wyborze?
6 września, 2021
Pokaż wszystko

Audyt bezpieczeństwa aplikacji – testy penetracyjne

Aplikacje web, podobnie jak sieć LAN w firmie, codziennie narażone są na ataki hakerskie. Jak sprawdzić, czy nasz sklep internetowy, marketplace, aplikacja mobilna czy platforma SaaS jest zabezpieczona przed cybernetycznym atakiem? Rozwiązaniem jest przeprowadzenie audytu bezpieczeństwa aplikacji webowej.

Liczba ataków cybernetycznych, jakie dokonywane są na aplikacje webowe wzrasta z roku na rok w zastraszającym tempie. W gronie najczęstszych typów ataków znajdują się:

  • Ataki Cross-site request forgery (CSRF lub XSRF)
  • „Ślepe” ataki SQL injection
  • Ataki Cross-site scripting (XSS)
  • Ataki Man-in The-Middle
  • Ataki DNS Tunneling
  • Ataki DDoS
  • Ataki Zero-day exploit

Konsekwencją cybernetycznego ataku najczęściej są spore straty finansowe i wizerunkowe dla firmy. Efektem zaniedbania związanego z bezpieczeństwem może być nie tylko wyciek newralgicznych informacji i danych klientów, ale również unieruchomienie całej usługi (ataki DDoS).

Z tego powodu istotną kwestią dla firm na najbliższe lata jest zapewnienie wysokiego poziomu bezpieczeństwa a regularna kontrola stanu zabezpieczeń i kodu źródłowego aplikacji powinno być jednym z priorytetów. Te kwestie rozwiązuje audyt bezpieczeństwa.

Na czym polega audyt bezpieczeństwa aplikacji?


Audyt bezpieczeństwa aplikacji webowej polega na sprawdzeniu i weryfikacji zabezpieczeń, jakimi chroniona jest dana aplikacja webowa.
W ramach audytu aplikacji przeprowadzanych jest wiele testów mających na celu wykrycie luk bezpieczeństwa, które potencjalnie mogą stać się furtką dla możliwych ataków sieciowych. Z tego powodu w trakcie audytu przeprowadzane są testy typu BlackBox, WhiteBox i GreyBox (jeden typ testów lub ich zestaw).


Na czym polegają testy Black Box?


Testy Black Box to testy zewnętrzne, które przeprowadzane są bez znajomości kodu źródłowego, środowiska serwerowego czy danej konfiguracji. Innymi słowy, podejmowane jest testowanie systemu bez wcześniejszej wiedzy o jego wewnętrznym działaniu. Pod tym względem testy Black Box w dużym stopniu przypominają rzeczywisty scenariusz, w którym haker próbuje się włamać z zewnątrz do systemu i aplikacji.

W tego typu badaniu tester dostarcza aplikacji pewne dane wejściowe i sprawdza jakie dane wyjściowe generowane są przez system. W ten sposób jest w stanie ocenić, jak aplikacja reaguje na działania użytkownika. Przy okazji może zweryfikować również inne aspekty funkcjonowania aplikacji UI/UX, serwer WWW lub serwer aplikacji, bazę danych itd.


Wybrane techniki testowania Black Box


Analiza wartości granicznej (brzegowej)
W tej metodzie testerzy koncentrują się na wartościach granicznych, przy których potencjalnie istnieje większe prawdopodobieństwo na otrzymanie błędnej odpowiedzi. Weryfikowane są odpowiedzi systemu związane z określoną wartością graniczną. Przypuśćmy, że jedno z pól formularza może akceptować tylko wartości od 1 do 10. W takiej sytuacji osoby testujące będą weryfikować odpowiedzi systemu na -1, 1 oraz 10 i 11. W ten sposób sprawdzamy, czy system odpowiednio akceptuje i odrzuca dane wyjściowe.

Podział na klasy równoważności
W tym przypadku dane wejściowe dzielone są na poszczególne klasy lub partycje.
Testerzy sprawdzają tylko przykładowe dane wejściowe należące do danej klasy.

Testowanie tabeli decyzyjnej
Dotyczy to systemów, które dostarczają dane wyjściowe na podstawie zestawu warunków. Po zidentyfikowaniu reguł, czyli kombinacji warunków, testerzy określają wynik każdej reguły i projektują wariant testu.


Na czym polegają testy White Box?


W odróżnieniu od testów Black Box w testach białej skrzynki tester ma wiedzę na temat wewnętrznej struktury lub kodu oprogramowania. W tego typu teście analizowana jest nie tylko funkcjonalność, jak w przypadku testów czarnej skrzynki, ale również struktury wewnętrzne, struktury danych, architektura aplikacji, kod i działanie oprogramowania.

Testy białej skrzynki zazwyczaj składają się z następujących etapów.

  1. Dane wejściowe. Na tym etapie tester zapoznaje się ze specyfikacją, dokumentami projektowymi i kodem źródłowym.
  2. Planowanie testów. Testerzy przygotowują określone zadania testowe, które mają na celu sprawdzenie działania całego kodu. Teksty przeprowadzane są do momentu otrzymania wyników pozbawionych luk i błędów.
  3. Raport. Raport końcowy z wyniku testów, przeprowadzonych prac oraz rekomendacje zmian.

Testy White Box pozwalają na przygotowanie się do sytuacji, w której atakujący jest zaznajomiony ze strukturą i działaniem serwisu.

Audyt bezpieczeństwa aplikacji metodą Grey Box

Metoda szarej skrzynki jest czymś pośrednim między białą i czarną. Przy tego typu audycie testerzy otrzymają tylko częściowe, wyrywkowe dane, które mogłyby zostać zidentyfikowane przez potencjalnego hakera. Zazwyczaj tester zna kody źródłowe, ale testy są prowadzone tylko z poziomu interfejsu. Tego typu audyt przygotowuje na sytuację, w której pewne neurologiczne dane swojej firmy mogą zostać ujawnione na przykład przez działania socjotechniczne hakera czy działania offline

Znajomość słabych punktów swojego systemu i aplikacji pozwoli na uniknięcie lub zminimalizowanie zagrożenia cybernetycznego ataku. Z tego względu audyt aplikacji webowych i testy penetracyjne powinny być wykonywane regularnie w każdej firmie.

Potrzebujesz audytu / testów penetracyjnych aplikacji w firmie?

Zapraszam do kontaktu ze mną pod numerem telefonu +48 515 135 478 lub mailowego pod adresem pt@sebitu.pl. Przygotuję propozycje na audyt twojej aplikacji i poznasz opcje do wyboru.

Piotr Tamulewicz
Piotr Tamulewicz
Doradca ds. rozwiązań IT w SEBITU.