Audyt bezpieczeństwa infrastruktury sprzętowej IT
Oprogramowanie do wydruku etykiet
Audyt bezpieczeństwa infrastruktury sprzętowej IT
Oprogramowanie do wydruku etykiet
Pokaż wszystko

Audyt bezpieczeństwa aplikacji – testy penetracyjne

Aplikacje web, podobnie jak sieć WLAN >> 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.

Zobacz też: Kontrola dostępu do sieci >> i MDM >>

Audyt bezpieczeństwa aplikacji webowych metodą OWASP.

OWASP Open Worldwide Application Security Project® to międzynarodowa społeczność, a także fundacja, której głównym celem jest poprawa bezpieczeństwa wszelkiego rodzaju aplikacji internetowych. OWASP, w których strukturach działa wielu specjalistów od bezpieczeństwa z całego świata, zajmuje się m.in. przygotowywaniem raportów i analiz dotyczących zagrożeń w sieci, projektowaniem technologii i narzędzi, a także szkoleniami z zakresu bezpieczeństwa, które prowadzone są na całym świecie. 

OWASP, przy współpracy społeczności i szeregu specjalistów ds. bezpieczeństwa, regularnie tworzy i aktualizuje ranking OWASP Top Ten. Ranking zawiera najczęściej występujące luki bezpieczeństwa wraz z informacją o ich potencjalnym wpływie i generowanym zagrożeniu.

Lista OWASP Top Ten jest wykorzystywana przez specjalistów ds. bezpieczeństwa oraz testerów przy projektowaniu aplikacji webowych, a także wykonywaniu testów penetracyjnych. Jeśli w Twojej firmie przeprowadzane będą takie testy, to z pewnością będą one bazować na metodologii OWASP, która jest obecnie najlepszym sposobem na badanie potencjalnych zagrożeń. 

Etap wstępny. Czym jest skaner podatności?

Zanim specjaliści do spraw bezpieczeństwa rozpoczną testy penetracyjne, zazwyczaj przeprowadzane jest skanowanie systemu za pomocą tak zwanego skanera podatności (ang. vulnerability scanner). W bardzo dużym uproszczeniu skaner podatności można porównać do skanera antywirusowego, który wpuszczamy do naszego komputera w poszukiwaniu złośliwego oprogramowania. W tym przypadku skaner podatności nie odnajduje złośliwego oprogramowania, ale szuka luk w zabezpieczeniach systemów komputerowych, sieci, aplikacji itp.

Skanery podatności zawierają w sobie rozbudowaną bibliotekę na jej podstawie przeprowadzają przegląd systemu. Sprawdzają m.in. czy w oprogramowaniu firmowym wykonane zostały wszystkie aktualizacje i czy znajdują się pewne niebezpieczne luki, które mogą stać się potencjalnym źródłem zagrożenia.

Warto wyraźnie podkreślić, że wynik uzyskany przez skaner podatności nie zastępuje testu penetracyjnego. Skanowanie pomaga we wstępnym rekonesansie i zorientowaniu się w stanie systemu. 

Co bada się podczas audytu i testów penetracyjnych zgodnych z OWASP? 

Wiele zależy od tego, co jest przedmiotem testów penetracyjnych. Czy są to aplikacje webowe, IoT, aplikacje mobilne a może usługi w chmurze? Dla każdej z tych grup OWASP ma przygotowany zestaw 10 kluczowych luk, które zazwyczaj jest punktem wyjścia do audytów i testów penetracyjnych. 

Aktualizacje listy prowadzone są na bieżąco i uwzględnia najczęściej występujące typy zagrożeń.

A01: Nieodpowiednia kontrola dostępu (Broken Access Control)

To luka bezpieczeństwa, która zanotowała największy skok w porównaniu 2017 rokiem, w którym zajmowała tylko 5 pozycję na liście. Testerzy sprawdzają, w jaki sposób możliwe jest uzyskiwanie dostępu do danych wrażliwych i próbują wykryć luki, które potencjalnie mogą pozwolić atakującemu na dostanie się do systemu.

A02: Błędy kryptograficzne (Cryptographic Failures)

Ta kategoria luk w poprzednim zestawieniu znajdowała się na pozycji numer 3 i wcześniej był znana jako “Narażenie na wrażliwe dane”. Awarie związane z kryptografią bardzo często są powodem ujawnienia wrażliwych danych lub naruszenia bezpieczeństwa systemu. Czym w istocie są tego typu luki? Najczęściej dotyczą one nieprawidłowego zabezpieczania haseł lub generowania zbyt słabych kluczy kryptograficznych. Często wynikają np. ze złego zarządzania  rotacją kluczy (hasła nie są zmieniane wystarczająco często).

A03: Ataki typu injection

Bardzo popularna metoda hakerska >>, która polega na wstrzyknięcie złośliwego kodu. Najpopularniejszymi typu zagrożeniami są:

  • SQL injection, 
  • XSS, 
  • Host Header injection, 
  • Code injection, 
  • JSON injection,  Command injection. 

Najprostszą metodą audytu  jest dokładny przegląd kodu źródłowego, który pomoże wykryć podatność aplikacji na iniekcję.

A04: Niebezpieczne zaprojektowanie aplikacji  (Insecure Design)

To nowa kategoria, która pojawiła się na liście w 2021 roku i związana jest z błędami projektowymi i architektonicznymi, które mogą wpłynąć na zwiększenie podatności na zagrożenie np. nieprawidłowo zaprojektowany mechanizm logowania do aplikacji czy też uploadu plików. Innymi słowy, sprawdzane są potencjalne błędy w budowie strony internetowej czy aplikacji.

A05: Niewłaściwa konfiguracja (Security Misconfiguration)

W tej kategorii znajduje się szereg luk dotyczących niewłaściwej konfiguracji aplikacji. Dotyczyć to może wielu aspektów takich jak np. nieprawidłowo skonfigurowane uprawnienia w usługach, instalacja lub wyłączenie niepotrzebnych funkcji czy też pozostawienie domyślnych ustawień haseł do kont itp. Weryfikacja polega na dokładnym sprawdzeniu katalogu, używanych komponentów czy też konfiguracji serwera webowego.

A06: Podatne i przestarzałe komponenty (Vulnerable and Outdated Components)

Grupa zawierająca wszystkie luki bezpieczeństwa, które pojawiają się wówczas, kiedy nie wykonujemy aktualizacji oprogramowania lub też nie naprawimy usterki platformy narażając ją na luki zabezpieczenia. Często pojawiają się również,  gdy twórca programowania nie testuje zgodności uaktualnionych lub poprawionych bibliotek.

A07: Identyfikacja i błędy w autentykacji (Identification and Authentication Failures) 

W tej kategorii znajdują się wszystkie potencjalne luki, które związane są z błędami identyfikacji. Testowanie ma na celu wykrycie słabych punktów w procesie uwierzytelniania. Najczęściej w tym przypadku sprawdzone są gruntownie mechanizmy przypominania hasła, a także wykonywane są testowe ataki typu brute force w panelu logowania.

A08: Błędy danych integralności w aplikacji Software and Data Integrity Failures

To kolejna nowa grupa błędów, która związana jest z aktualizacjami oprogramowania, krytycznymi danymi. Tego typu luki występują w sytuacji, gdy np. dana aplikacja wykorzystuje w swojej pracy wtyczki czy biblioteki, które nie pochodzą z zaufanych repozytoriów. Podobnie jak w przypadku punktu 6. rozwiązaniem jest tutaj dokładny przegląd kodu źródłowego bibliotek, modułów i wersji aplikacji. 

A09: Logowanie i monitoring (Security Logging and Monitoring Failures)

Grupa zagrożeń, które wynikają z niewłaściwego rejestrowania wykrywania i monitorowania aplikacji. Zagrożenie może pojawić się, gdy w dziennikach logów nie są odnotowywane np. nieudane logowania i transakcje o dużej wartości. Nie ustawione są określone bazowe progi, które wygenerowałyby np. odpowiednio wcześniej alerty. Wówczas podczas testów sprawdza się, czy dana aplikacja loguje wszystkie zdarzenia, które mogą prowadzić do incydentów bezpieczeństwa. 

A10: Podatność SSRF (Server Side Request Forgery)

Kolejna stosunkowo nowa kategoria, która na razie nie ma dużej częstotliwości występowania. Zagrożenie sukcesywnie rośnie między innymi z uwagi na rosnący dostęp do usług chmurowych. Luka SSRF polega na wykorzystaniu słabego punktu w aplikacji, którym jest pobierany ze zdalnego zasobu bez uprzedniej weryfikacji adresu URL. To pozwala atakującemu na kontrolowanie aplikacji i przesyłanie specjalnie spreparowanego żądania do nieoczekiwanego miejsca docelowego, nawet w przypadku, gdy aplikacja jest chroniona przez różnego rodzaju listy kontroli dostępu do sieci.

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.

Zobacz też: Firewall NGFW >>

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.

Ostatnia aktualizacja 2023-07-10

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