Testy bezpieczeństwa aplikacji
Sprawdzamy Twoją aplikację tak, jak zrobiłby to atakujący: logikę biznesową, role i uprawnienia, API oraz to, co dzieje się na urządzeniu użytkownika. Dostajesz dowody, nie listę teoretycznych podatności.
- ISO/IEC 27001
- 3000+ stanowisk pod opieką
- NIS2 i KSC
- IOD w standardzie
- od 2017
Aplikacja, z której korzystają klienci albo magazyn, jest dziś częściej celem ataku niż serwer w szafie. Testujemy aplikacje webowe, portale, API, aplikacje Android oraz systemy magazynowe i terminalowe, żeby luki wyszły na jaw u nas, a nie u kogoś, kto się nie przedstawi.
Co testujemy
Zakres dobieramy do tego, jak aplikacja jest zbudowana i gdzie realnie leży ryzyko dla firmy.
-
Aplikacje webowe i portale
Panele klienta, sklepy, systemy wewnętrzne. Uwierzytelnianie, sesje, role, dostęp do cudzych danych i podatności typu wstrzyknięcie kodu.
-
API i integracje
Interfejsy REST i webhooki, którymi aplikacja rozmawia z innymi systemami. Autoryzacja per zasób, limity, wyciek danych w odpowiedziach.
-
Aplikacje mobilne Android
Analiza pakietu, dane przechowywane na urządzeniu, komunikacja z serwerem, przypięcie certyfikatów i to, co da się obejść po stronie klienta.
-
Systemy magazynowe i terminalowe
Aplikacje WMS, kolektory danych i terminale. Kontrola dostępu, praca w sieci zakładowej, izolacja od reszty środowiska.
-
Stanowiska kioskowe i Windows PE
Stacje w trybie kiosku i środowiska preinstalacyjne. Czy da się wyjść z powłoki, podmienić obraz albo dostać się do systemu plików.
-
Raport z dowodami
Każde ustalenie z krokami odtworzenia, oceną ryzyka i konkretną rekomendacją. Do tego retest po naprawie, żeby potwierdzić, że luka zniknęła.
Co to są testy bezpieczeństwa aplikacji?
Testy bezpieczeństwa aplikacji to kontrolowana próba złamania konkretnego programu: aplikacji webowej, portalu, API, aplikacji mobilnej albo systemu magazynowego. Sprawdzamy, czy da się dostać do danych innego użytkownika, obejść uprawnienia, wykonać operację bez autoryzacji albo wyprowadzić dane z systemu. Efektem nie jest lista teoretycznych podatności, tylko potwierdzone ścieżki ataku wraz z krokami odtworzenia.
Testujemy w trzech wariantach. Bez wiedzy o systemie (black box), z kontem użytkownika i dokumentacją (grey box) oraz z dostępem do kodu źródłowego (white box). Najwięcej daje wariant środkowy: mamy konto, więc sprawdzamy to, co najczęściej zawodzi, czyli uprawnienia i logikę biznesową, a nie tylko warstwę wejściową.
Czym to się różni od testów penetracyjnych infrastruktury
Test penetracyjny infrastruktury patrzy na środowisko: serwery, sieć, usługi wystawione na zewnątrz, konfigurację. Odpowiada na pytanie, czy da się wejść do firmy. Test bezpieczeństwa aplikacji patrzy na jeden program i jego logikę: czy zalogowany klient zobaczy fakturę innego klienta, czy da się zmienić cenę w koszyku, czy pracownik magazynu wykona operację zarezerwowaną dla kierownika.
To są uzupełniające się badania, nie zamienniki. Firma z bezpieczną infrastrukturą i dziurawą aplikacją traci dane tak samo skutecznie jak firma z odwrotnym problemem. Jeśli nie wiecie, od czego zacząć, zwykle proponujemy najpierw aplikację, przez którą przechodzą dane klientów, bo to ona jest wystawiona na świat przez całą dobę.
Aplikacje magazynowe, terminalowe i kioskowe
To obszar, o którym w firmach myśli się najrzadziej, a który bywa najsłabszym ogniwem. Kolektor danych albo terminal na hali zwykle loguje się jednym wspólnym kontem, ma zapisane hasło do bazy i pracuje w tej samej sieci co reszta firmy. Wystarczy, że ktoś wyjdzie z aplikacji do systemu, i ma gotowy przyczółek.
Sprawdzamy dokładnie takie scenariusze: czy da się opuścić tryb kiosku, co jest zapisane w konfiguracji urządzenia, jak wygląda komunikacja z serwerem i czy urządzenie magazynowe jest odseparowane od segmentu biurowego. Przy Windows PE i obrazach instalacyjnych patrzymy też na to, czy nie ma w nich zaszytych poświadczeń, bo to klasyk, który potrafi przetrwać w firmie latami.
Kiedy warto przetestować aplikację
Najczęstsze momenty to: przed uruchomieniem nowej aplikacji lub portalu dla klientów, po dużej zmianie w systemie ról i uprawnień, przed audytem klienta korporacyjnego, który pyta o testy w ankiecie bezpieczeństwa, oraz przy przygotowaniu do NIS2 albo ISO 27001.
Osobna sytuacja to aplikacja przejęta razem z firmą albo odziedziczona po poprzednim dostawcy. Nikt nie wie, co w niej jest, a odpowiedzialność już leży po Waszej stronie. Test daje wtedy punkt wyjścia: co grozi najbardziej i czy w ogóle warto ten kod utrzymywać, czy lepiej zaplanować modernizację.
Co dostajecie po testach
Raport techniczny z listą ustaleń, każde z krokami odtworzenia, dowodem i oceną ryzyka w skali, która ma sens dla Waszej firmy, a nie tylko w punktacji z tabelki. Do tego streszczenie dla zarządu: co jest naprawdę groźne, co poczeka i jaki jest realny koszt naprawy.
Dołączamy plan naprawczy podzielony na to, co da się poprawić od razu w konfiguracji, i to, co wymaga zmian w kodzie. Po Waszych poprawkach robimy retest tych ustaleń, żeby potwierdzić, że luki zostały faktycznie zamknięte, a nie tylko przykryte.
Jeśli aplikację pisał ktoś inny, tłumaczymy ustalenia w sposób, który da się przekazać dostawcy bez tłumacza. Możemy też rozmawiać z jego programistami bezpośrednio, o ile chcecie skrócić drogę.
Jak prowadzimy testy
Zakres i zasady ustalamy na piśmie przed startem, żeby test nie zaskoczył ani Was, ani Waszych użytkowników.
- zakres na piśmie ustalony przed rozpoczęciem
- bez przestoju testy na kopii albo w oknie serwisowym
- dowody kroki odtworzenia dla każdego ustalenia
- retest potwierdzenie po naprawie w cenie
Najpierw zakres i zgoda
Ustalamy, co testujemy, w jakich godzinach i czego nie ruszamy. Wszystko na piśmie, łącznie ze zgodą właściciela systemu.
Testujemy bezpiecznie
Pracujemy na kopii środowiska albo w uzgodnionym oknie. Nie niszczymy danych i nie wywracamy produkcji, żeby udowodnić tezę.
Zgłaszamy krytyczne od razu
Jeśli znajdziemy lukę grożącą wyciekiem, dzwonimy tego samego dnia, nie czekając z tym do raportu końcowego.
Sprawdzamy po naprawie
Po Waszych poprawkach wracamy i potwierdzamy, że ustalenia zostały zamknięte. Retest jest częścią usługi.
Model rozliczeń
Testy wyceniamy w stałej cenie po krótkiej ankiecie zakresu. Znacie kwotę, zanim zaczniemy, i nie rozliczamy tego od godziny konsultanta.
W abonamencie
- Testy w uzgodnionym zakresie
- Raport techniczny i streszczenie dla zarządu
- Plan naprawczy z priorytetami
- Retest ustaleń po naprawie
Poza abonamentem
- Naprawa błędów w kodzie aplikacji
- Kolejne rundy testów po dużych zmianach
- Testy powtarzane cyklicznie w abonamencie
Na wycenę wpływa liczba ról w aplikacji, liczba ekranów i integracji oraz to, czy testujemy też warstwę mobilną i urządzenia.
Najczęstsze pytania
Czym testy bezpieczeństwa aplikacji różnią się od testów penetracyjnych?
Testy penetracyjne patrzą na środowisko: serwery, sieć i usługi wystawione na zewnątrz. Testy bezpieczeństwa aplikacji patrzą na jeden program i jego logikę: uprawnienia, role, API oraz to, czy zalogowany użytkownik dostanie się do cudzych danych. To badania uzupełniające się, a nie zamienne.
Czy testujecie aplikacje mobilne na Androida?
Tak. Analizujemy pakiet aplikacji, dane zapisywane na urządzeniu, komunikację z serwerem oraz to, co da się obejść po stronie klienta, na przykład weryfikację wykonywaną wyłącznie w aplikacji. Sprawdzamy też API, z którego aplikacja korzysta, bo tam zwykle leży prawdziwe ryzyko.
Testujecie systemy magazynowe i terminale?
Tak, to jeden z naszych obszarów. Sprawdzamy aplikacje WMS, kolektory danych, terminale i stanowiska kioskowe: czy da się wyjść z aplikacji do systemu, co jest zapisane w konfiguracji urządzenia, jak wygląda uwierzytelnianie i czy sprzęt magazynowy jest odseparowany od sieci biurowej. Przy obrazach Windows PE szukamy też zaszytych poświadczeń.
Czy test zakłóci pracę firmy?
Planujemy go tak, żeby nie zakłócił. Testy prowadzimy na kopii środowiska albo w uzgodnionym oknie serwisowym, a zakres i godziny ustalamy na piśmie przed rozpoczęciem. Nie usuwamy danych i nie wywracamy produkcji, żeby coś udowodnić.
Ile trwają testy bezpieczeństwa aplikacji?
Dla typowej aplikacji webowej z kilkoma rolami zwykle od jednego do dwóch tygodni: kilka dni testów, potem opracowanie raportu. Aplikacja z rozbudowanym API, częścią mobilną i urządzeniami magazynowymi wymaga więcej czasu. Termin podajemy razem z wyceną.
Ile to kosztuje?
Wyceniamy w stałej cenie po ankiecie zakresu, a nie godzinowo. Na kwotę wpływa liczba ról i ekranów w aplikacji, liczba integracji oraz to, czy w zakresie jest też warstwa mobilna i urządzenia. Retest po naprawie jest częścią usługi, nie osobną pozycją.
Co jeśli aplikację pisał inny dostawca?
To bardzo częsta sytuacja i nie jest problemem. Raport przygotowujemy tak, aby dało się go przekazać dostawcy bez tłumaczenia technicznego, a w razie potrzeby rozmawiamy z jego zespołem bezpośrednio. Jeśli okaże się, że kod jest w stanie, w którym łatanie nie ma sensu, powiemy to wprost i pokażemy koszt modernizacji.
Czy pomożecie naprawić znalezione błędy?
Tak, jeśli tego chcecie. Możemy poprawić aplikację, którą utrzymujemy, wesprzeć Wasz zespół albo doradzić przy rozmowie z zewnętrznym dostawcą. Naprawa jest wyceniana osobno, bo jej zakres znamy dopiero po testach.
Porozmawiajmy o Twoim projekcie
Odpowiedz na 2 pytania o swoją firmę. Prostą wycenę zobaczysz od razu, a pełną propozycję przygotujemy w 24 godziny robocze.
- 2 minuty, bez zobowiązań
- Rozmawiasz z inżynierem, nie handlowcem
- Żadnego spamu, jeden kontakt w sprawie wyceny