Jaka drukarka do szarf?
2025-06-13
Audyt bezpieczeństwa infrastruktury sprzętowej IT
2025-06-17
Ostatnia aktualizacja 2025-06-17
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.
O czym przeczytasz w tym artykule?
Liczba ataków cybernetycznych wzrasta
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
Przykład
Jak luka w aplikacji doprowadziła do sabotażu przemysłowego
Jednym z najgłośniejszych ataków w historii cyberbezpieczeństwa był przypadek wirusa Stuxnet, który w 2010 roku zaatakował instalacje nuklearne w Iranie.
W uproszczeniu – był to bardzo zaawansowany program, który potrafił przejąć kontrolę nad systemami przemysłowymi odpowiedzialnymi za sterowanie wirówkami do wzbogacania uranu.
Atak wykorzystał luki w systemach Windows oraz w oprogramowaniu sterującym urządzeniami przemysłowymi (tzw. systemy SCADA). Złośliwy kod został wprowadzony do sieci za pomocą zainfekowanego pendrive’a – co pokazuje, że zagrożenia mogą pochodzić nie tylko z internetu, ale też z wewnątrz firmy.
Stuxnet nie tylko przejął kontrolę nad wirówkami, ale też manipulował danymi wyświetlanymi operatorom – tak, by nie zorientowali się, że coś jest nie tak. Efekt? Uszkodzenie ponad 1000 wirówek, spowolnienie programu nuklearnego i ogromne straty.
Ten przykład jasno pokazuje, dlaczego tak ważne jest testowanie aplikacji i systemów – zarówno od strony użytkownika, jak i wewnętrznych mechanizmów bezpieczeństwa. Właśnie na tym polegają testy penetracyjne: na sprawdzeniu, czy istnieje jakakolwiek ścieżka, która mogłaby zostać wykorzystana przez napastnika. Bo jeśli nie znajdziemy jej my – może zrobić to ktoś inny.
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 bezpieczeństwa aplikacji webowych 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 penetracyjnych 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).
Testy penetracyjne – o co w tym chodzi?
Testy penetracyjne (często określane również jako pentesty lub testy bezpieczeństwa aplikacji) są praktycznym rozszerzeniem audytu bezpieczeństwa. Ich głównym celem jest symulacja realnego ataku cybernetycznego w kontrolowanych warunkach – tak, jakby wykonywał go prawdziwy haker. Często testy te obejmują zarówno perspektywę zewnętrznego napastnika (testy typu Black Box), jak i osoby z częściowym dostępem do systemu (Grey Box) czy pełnym wglądem w kod źródłowy (White Box).
W praktyce oznacza to sprawdzenie, jak trudno jest „wejść” do aplikacji, czy można podnieść sobie uprawnienia do poziomu administratora, czy też w łatwy sposób można przejąć sesję użytkownika. Wysoki odsetek najgroźniejszych ataków, jak np. ransomware klasy golden ticket czy ataki z wykorzystaniem Pegasusa, opiera się właśnie na wykorzystaniu takich podatności. Testy penetracyjne koncentrują się na warstwie 7 modelu OSI, czyli warstwie aplikacji – odpowiadającej za protokoły takie jak HTTP/HTTPS. Dzięki nim możliwa jest identyfikacja luk, zanim zostaną one wykorzystane przez cyberprzestępców. Przyjrzyjmy się teraz szczegółowo rodzajom testów penetracyjnych.
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.
Zobacz też: Audyt bezpieczeństwa infrastruktury sprzętowej IT
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.
- Dane wejściowe. Na tym etapie tester zapoznaje się ze specyfikacją, dokumentami projektowymi i kodem źródłowym.
- 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.
- 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.
Jak testujemy aplikacje webowe w Sebitu?
W ramach testów penetracyjnych przeprowadzanych przez Sebitu, inżynierowie wykonują szereg zaawansowanych działań – zarówno automatycznych, jak i manualnych – w oparciu o uznaną metodologię OWASP Top 10. Zakres testów jest każdorazowo dostosowywany do specyfiki aplikacji oraz potrzeb przedsiębiorstwa – inne testy przeprowadzimy w przypadku prostego sklepu internetowego, a inne w przypadku systemu transakcyjnego czy platformy chmurowej.
Zakres testów penetracyjnych aplikacji webowej dzielimy na dwie główne kategorie:
- Testy podstawowe – obejmują najczęstsze podatności (np. XSS, SQL Injection, błędy w uwierzytelnianiu), skanowanie za pomocą narzędzi automatycznych oraz przygotowanie raportu. Czas realizacji: ok. 2 tygodni
- Testy rozszerzone – pogłębiona analiza aplikacji, obejmująca mniej oczywiste i rzadziej występujące zagrożenia, testy manualne i sprawdzenie zgodności z dokumentacją techniczną. Dodatkowy czas realizacji: od 2 tygodni.
Przykładowe scenariusze testowe, które mogą być realizowane:
- SQL Injection w punktach wejściowych użytkownika (np. logowanie, formularze).
- Cross-Site Scripting (XSS) – ataki typu stored, reflected oraz DOM-based.
- CSRF – testy fałszowania żądań w formularzach i linkach.
- Testy odporności mechanizmów logowania na brute force oraz credential stuffing.
- Weryfikacja konfiguracji SSL i podatności na ataki typu Man-in-the-Middle.
- Testowanie uploadu plików, API, zarządzania sesją i tokenami JWT.
- Sprawdzenie zgodności z dokumentacją i analiza odpowiedzi systemu na nieprzewidziane zachowania użytkownika.
Każdy projekt kończy się szczegółowym raportem wraz z rekomendacjami i oceną ryzyka. Dzięki temu klient otrzymuje nie tylko listę błędów, ale też konkretne wskazówki, jak je naprawić.
Potrzebujesz audytu / testów penetracyjnych aplikacji w firmie?
Zapraszam do kontaktu telefonicznego +48 22 299 25 15 lub pozostaw wiadomość przez formularz kontaktowy. Przygotuję propozycje na audyt twojej aplikacji i poznasz opcje do wyboru.
OWASP Top Ten to podstawa przy audytach aplikacji.
Recenzja: Audyt bezpieczeństwa aplikacji webowych – testy penetracyjne.