Testy penetracyjne · Aplikacje mobilne
Aplikacje mobilne
Audyt bezpieczeństwa i testy penetracyjne aplikacji iOS i Android według OWASP MASVS: dane na telefonie, API, SDK i dane o zdrowiu. Raport i retest.
Testy penetracyjne · Przykładowy raport
Przykładowy raport z testu penetracyjnego
Raport z testu penetracyjnego mówi zarządowi, które ryzyka wymagają decyzji, a zespołowi technicznemu - co dokładnie naprawić i jak to sprawdzić. Pokazujemy strukturę raportu Innovix i jego fragmenty na danych demonstracyjnych: fikcyjna „Przykładowa aplikacja pacjenta” na iOS i Androida z backendem API, przetestowana według OWASP MASVS i MASTG, tak jak w naszych testach penetracyjnych aplikacji mobilnych. Raport z testu aplikacji webowej, API, chmury czy infrastruktury ma ten sam układ - zmieniają się metodyka i rodzaj ustaleń.
01Struktura
Co zawiera raport z testu penetracyjnego
Siedem części; przy każdej podajemy jej głównego odbiorcę. Kolejne sekcje tej strony pokazują fragmenty z przykładu.
| Część raportu | Dla kogo | Co zawiera |
|---|---|---|
| 1. Podsumowanie dla zarządu | Zarząd, właściciel biznesowy systemu | Ocena ogólna, najważniejsze ryzyka językiem biznesowym, decyzje do podjęcia |
| 2. Zakres i założenia | Zespół projektu, dział zakupów, audytor | Co testowaliśmy, w jakiej wersji i środowisku, z jakimi kontami, czego nie obejmował test |
| 3. Metodyka | Dział bezpieczeństwa, audytor | Standardy, podejście (black, grey lub white box), skala oceny i terminy napraw |
| 4. Tabela ustaleń | Kierownik projektu, dział bezpieczeństwa | Wszystkie ustalenia z poziomem, wynikiem CVSS, oceną kontekstową, terminem i właścicielem |
| 5. Szczegóły ustaleń | Programiści, administratorzy | Opis, wpływ, wektor CVSS, odniesienie do wymagania i CWE, dowód, rekomendacja |
| 6. Łańcuchy ataku | Zespół techniczny i zarząd | Jak kilka słabości składa się w jeden scenariusz - jeśli test taki wykazał |
| 7. Wyniki retestu | Wszyscy odbiorcy | Status każdego ustalenia po naprawach i nowy dowód |
W raporcie dla klienta dowody są dosłownymi wynikami poleceń i żądań, bez parafraz - tak, żeby zespół mógł odtworzyć każdy krok. Na tej stronie opisujemy je słowami, bo pokazujemy format, a nie prawdziwy system.
02Fragment 1
Podsumowanie dla zarządu
Podsumowanie dla zarządu mieści się na jednej stronie i nie wymaga wiedzy technicznej. Odpowiada na trzy pytania: jak poważna jest sytuacja, co może się stać i jakie decyzje trzeba podjąć - z terminami.
- ocena ogólna - jedno zdanie, które można przenieść do notatki dla zarządu,
- liczba ustaleń według poziomu - po ocenie kontekstowej, nie tylko według CVSS,
- ryzyko biznesowe - co konkretnie grozi firmie i jej klientom,
- decyzje - budżet, priorytety, ewentualne wstrzymanie wydania.
W tym przykładzie dane pacjentów należą do szczególnej kategorii danych osobowych, dlatego ocena kontekstowa podnosi priorytet dwóch ustaleń. Jak testujemy systemy dla placówek medycznych i laboratoriów, opisujemy na stronie testów bezpieczeństwa w ochronie zdrowia.
03Fragment 2
Zakres i założenia testu
Ta część chroni obie strony: wiadomo, co zostało sprawdzone, a czego raport nie dotyczy.
| Element | Ustalenia w przykładzie |
|---|---|
| Obiekt testu | Przykładowa aplikacja pacjenta 3.4.0 (iOS i Android) oraz backend API api.pacjent.example |
| Funkcje | Logowanie numerem telefonu i kodem SMS, lista zleceń, pobieranie wyników badań w PDF, profil pacjenta |
| Podejście | Grey box: dwa konta pacjenta, aplikacja w wersji testowej (TestFlight i zamknięte testy w Google Play), specyfikacja API |
| Środowisko | Testowe, będące kopią produkcji, z danymi fikcyjnych pacjentów |
| Poza zakresem | Panel administracyjny laboratorium, systemy partnerów i integracje laboratoryjne, testy DoS i obciążeniowe |
| Zasady | Pisemna zgoda właściciela systemu, okna czasowe w dni robocze, kontakt awaryjny, próby odgadnięcia kodu najwyżej 20 i tylko za zgodą |
04Fragment 3
Metodyka i skala oceny
W raporcie wymieniamy standardy, według których pracowaliśmy, i to, do czego każdy z nich posłużył:
- OWASP MASVS 2.1 - wymagania bezpieczeństwa aplikacji mobilnej w ośmiu grupach (od MASVS-STORAGE do MASVS-PRIVACY); każde ustalenie wskazuje wymaganie, którego dotyczy,
- OWASP MASTG - procedury testów statycznych i dynamicznych dla iOS i Androida,
- OWASP WSTG v4.2 i OWASP API Security Top 10 2023 - testy backendu API, z którego korzysta aplikacja,
- OWASP ASVS 5.0 - gdy klient chce weryfikacji wymagań backendu na wybranym poziomie (L1, L2 albo L3),
- PTES - ramy procesu od ustaleń przedtestowych po raport,
- NIST SP 800-115 - planowanie i prowadzenie testów oraz raportowanie, zwłaszcza w testach infrastruktury,
- CWE - identyfikacja klasy słabości przy każdym ustaleniu.
| Poziom | Wynik CVSS | Zalecany termin naprawy |
|---|---|---|
| Critical | 9.0-10.0 | 14 dni |
| High | 7.0-8.9 | 30 dni |
| Medium | 4.0-6.9 | 90 dni |
| Low | 0.1-3.9 | 180 dni |
Wynik bazowy liczymy w CVSS 3.1, a na życzenie podajemy też wektor CVSS 4.0. Termin naprawy wynika z oceny kontekstowej: ta sama podatność może dostać wyższy priorytet, gdy dotyczy danych o zdrowiu albo pieniędzy.
05Fragment 4
Przykładowe ustalenia z oceną CVSS
Cztery ustalenia z przykładu: dostęp do plików w backendzie, przechowywanie danych na urządzeniu, logowanie kodem SMS i ekran aplikacji.
MOB-01
Wyniki badań innych pacjentów dostępne bez logowania pod przewidywalnym adresem
High CVSS 3.1 7.5
Opis
Aplikacja pobiera plik PDF z wynikiem badania z adresu zawierającego kolejny numer zlecenia. Serwer zwraca plik każdemu, kto zna adres - nie wymaga tokenu i nie sprawdza, czy wynik należy do zalogowanego pacjenta. Numery są nadawane kolejno, więc adresy innych wyników łatwo przewidzieć.
Wpływ
Każda osoba z internetu może pobierać wyniki badań wszystkich pacjentów. W ocenie kontekstowej podnosimy poziom do Critical: pliki zawierają dane o zdrowiu i dane identyfikujące pacjenta.
Dowód
Z konta testowego pacjenta A pobraliśmy własny wynik i zapisaliśmy adres pliku. To samo żądanie wysłane bez nagłówka z tokenem zwróciło plik (HTTP 200). Po zmniejszeniu numeru o jeden serwer zwrócił wynik pacjenta B, czyli drugiego konta testowego. Na tym zakończyliśmy test - nie pobieraliśmy plików spoza kont testowych.
Rekomendacja
Wymagaj ważnego tokenu przy każdym pobraniu i sprawdzaj po stronie serwera, czy zlecenie należy do zalogowanego pacjenta. Pliki udostępniaj przez krótkotrwałe, jednorazowe adresy generowane po tej kontroli. Losowe identyfikatory mogą być dodatkową warstwą, ale nie zastępują autoryzacji. Przejrzyj logi pobrań, żeby ustalić, czy ktoś wcześniej wykorzystał tę lukę.
MOB-02
Token odświeżania i pobrane wyniki zapisane na urządzeniu bez szyfrowania (Android)
Medium CVSS 3.1 5.2
Opis
Wersja na Androida zapisuje token odświeżania w pliku preferencji w postaci jawnej, a pobrane pliki PDF z wynikami zostają w katalogu pamięci podręcznej po zamknięciu podglądu. Wersja na iOS przechowuje token w pęku kluczy (Keychain) i nie zostawia plików - ustalenie dotyczy tylko Androida.
Wpływ
Osoba, która uzyska dostęp do plików aplikacji - na urządzeniu z dostępem root albo z kopii zapasowej danych aplikacji - może odczytać wyniki badań, a tokenem zalogować się jako pacjent na innym urządzeniu i zmienić dane w jego profilu. Dlatego oprócz poufności (C:H) oceniamy też wpływ na integralność (I:L).
Dowód
Na urządzeniu testowym z dostępem root odczytaliśmy plik preferencji aplikacji: token był czytelny bez dodatkowych kroków. Skopiowany token pozwolił uzyskać nową sesję z innego urządzenia. W katalogu pamięci podręcznej znaleźliśmy trzy pliki PDF z wynikami konta testowego, pobrane w poprzednich sesjach.
Rekomendacja
Szyfruj token kluczem przechowywanym w Android Keystore albo przechowuj go wyłącznie w pamięci na czas sesji. Pliki z wynikami wyświetlaj bez zapisu na dysku lub usuwaj je po zamknięciu podglądu. Wyłącz dane sesji i pliki wyników z kopii zapasowych w konfiguracji aplikacji.
MOB-03
Brak limitu prób kodu SMS przy logowaniu
Medium CVSS 3.1 6.5
Opis
Pacjent loguje się numerem telefonu i sześciocyfrowym kodem SMS ważnym 10 minut. Serwer nie ogranicza liczby błędnych prób dla kodu, konta ani adresu, z którego przychodzą żądania, i nie unieważnia kodu po serii błędów.
Wpływ
Atakujący, który zna numer telefonu pacjenta, może zautomatyzować zgadywanie kodu. Wymaga to dużej liczby żądań w czasie ważności kodu (stąd AC:H), ale jest wykonalne bez udziału ofiary. Skutkiem jest przejęcie konta, dostęp do wyników i zmiana danych kontaktowych - dlatego w ocenie kontekstowej podnosimy poziom do High.
Dowód
Za pisemną zgodą wysłaliśmy dla konta testowego 20 błędnych kodów w ciągu minuty. Każda próba zwróciła ten sam komunikat błędu, bez blokady i bez opóźnienia odpowiedzi, a kolejna próba z poprawnym kodem zakończyła się zalogowaniem. Zgodnie z zasadami testu nie przekroczyliśmy 20 prób.
Rekomendacja
Unieważniaj kod po kilku błędnych próbach (np. pięciu), ogranicz tempo prób na numer telefonu i adres źródłowy, ogranicz też liczbę nowych kodów, które można zamówić w krótkim czasie. Rejestruj serie błędnych prób i ustaw alert dla zespołu, który monitoruje usługę.
MOB-04
Ekran wyników widoczny w podglądzie ostatnich aplikacji i na zrzutach ekranu
Low CVSS 3.1 2.4
Opis
Ekran z wynikiem badania nie jest chroniony przed zrzutami ekranu i nagrywaniem na Androidzie, a na iOS nie jest zasłaniany, gdy aplikacja przechodzi w tło. Treść wyniku widać w przełączniku ostatnich aplikacji.
Wpływ
Osoba, która na chwilę dostanie telefon do ręki, zobaczy ostatnio otwarty wynik bez odblokowania aplikacji. Skala jest ograniczona do jednego wyniku i wymaga fizycznego dostępu do urządzenia.
Dowód
Po otwarciu wyniku i przejściu do ekranu głównego podgląd w przełączniku aplikacji pokazywał nazwę badania i wartości. Na Androidzie zrzut ekranu wyniku wykonał się bez ostrzeżenia.
Rekomendacja
Na Androidzie ustaw ochronę okna przed zrzutami na ekranach z wynikami, na iOS zasłaniaj treść przy przejściu aplikacji w tło. Rozważ ponowne uwierzytelnienie (np. biometrią) przed pokazaniem wyniku po powrocie do aplikacji.
06Fragment 5
Tabela priorytetów i plan napraw
| ID | Ustalenie | CVSS 3.1 | Ocena kontekstowa | Zalecany termin | Właściciel |
|---|---|---|---|---|---|
| MOB-01 | Wyniki badań dostępne bez logowania | 7.5 High | Critical | 14 dni | Zespół backendu |
| MOB-03 | Brak limitu prób kodu SMS | 6.5 Medium | High | 30 dni | Zespół backendu |
| MOB-02 | Token i wyniki bez szyfrowania na Androidzie | 5.2 Medium | Medium | 90 dni | Zespół Android |
| MOB-04 | Wynik widoczny w podglądzie aplikacji | 2.4 Low | Low | 180 dni | Zespoły iOS i Android |
Tabelę sortujemy według oceny kontekstowej. W tym przykładzie nie zmienia ona kolejności względem wyniku bazowego, ale skraca terminy: MOB-01 przechodzi z High (30 dni) do Critical (14 dni), a MOB-03 z Medium (90 dni) do High (30 dni), bo oba ustalenia dają dostęp do danych o zdrowiu bez dostępu do telefonu pacjenta. Kolumna „Właściciel” pozwala od razu przypisać zadania zespołom i zaplanować poprawki w najbliższych wydaniach aplikacji.
07Fragment 6
Retest: jak dokumentujemy naprawy
| ID | Status po reteście | Co sprawdziliśmy |
|---|---|---|
| MOB-01 | Usunięte | Żądanie pliku bez tokenu zwraca HTTP 401, a z tokenem pacjenta A do wyniku pacjenta B - HTTP 403; adresy plików są jednorazowe |
| MOB-02 | Usunięte | Token zaszyfrowany kluczem z Android Keystore, katalog pamięci podręcznej pusty po zamknięciu podglądu |
| MOB-03 | Usunięte częściowo | Kod unieważniany po pięciu błędnych próbach; nowe kody można jednak zamawiać bez ograniczeń, więc zgadywanie nadal jest możliwe. Wektor bez zmian: CVSS:3.1/ |
| MOB-04 | Ryzyko zaakceptowane | Właściciel aplikacji zdecydował o poprawce w kolejnym kwartale; decyzję i jej datę zapisujemy w raporcie |
Retest to ponowne sprawdzenie każdego ustalenia po naprawach, z nowym dowodem technicznym. Status i dowód dopisujemy do tego samego raportu, więc jeden dokument pokazuje zarówno problem, jak i jego rozwiązanie. Ustalenie naprawione tylko częściowo oceniamy ponownie i podajemy wektor CVSS po reteście - tak jak przy MOB-03: atak nadal jest możliwy, więc wynik bazowy się nie zmienia, ale po unieważnianiu kodu po pięciu próbach obniżamy poziom w ocenie kontekstowej.
08Dla zamawiającego
Jak ocenić raport z pentestu
Raporty różnych wykonawców trudno porównać na pierwszy rzut oka. Te pytania pomagają ocenić, czy raport nadaje się do pracy zespołu i do pokazania audytorowi:
- Czy każde ustalenie ma wersję CVSS i pełny wektor, a nie tylko liczbę?
- Czy dowód pozwala odtworzyć problem bez kontaktu z testerem?
- Czy raport opisuje zakres, wersje, środowisko i to, czego test nie obejmował?
- Czy ocena uwzględnia, jakie dane chroni system, a nie tylko wynik bazowy?
- Czy rekomendacja mówi, co zmienić, i czy przewidziano retest?
- Czy zarząd znajdzie w podsumowaniu decyzje, które ma podjąć?
Jeśli raport ma trafić do konkretnego odbiorcy - banku, dużego klienta albo audytora - warto przed testem uzgodnić z nim zakres i oczekiwaną formę. Raport z testu penetracyjnego jest mocnym dowodem testowania systemu, ale nie zastępuje audytu bezpieczeństwa z art. 15 ustawy o KSC ani oceny całego systemu zarządzania bezpieczeństwem.
Na co jeszcze patrzeć przy wyborze wykonawcy, piszemy w artykule jak porównać oferty na testy penetracyjne, a przegląd rodzajów audytu i testów - na stronie audytu bezpieczeństwa IT.
Najczęściej zadawane pytania
Czy mogę zobaczyć pełny raport z testu u innego klienta?
Nie. Raporty z testów u klientów są poufne i nie publikujemy ich wyników, także w formie zanonimizowanej. Ta strona pokazuje strukturę i fragmenty raportu na danych demonstracyjnych, a o formie raportu dla Twojego systemu rozmawiamy przy ustalaniu zakresu.
W jakim języku przygotowujecie raport?
Po polsku i po angielsku. Wersja angielska przydaje się, gdy raport trafia do centrali za granicą, do międzynarodowego zespołu albo do klienta, który wymaga dokumentu w tym języku.
Dlaczego ocena kontekstowa różni się od wyniku CVSS?
Wynik bazowy CVSS opisuje powagę samej podatności, a nie ryzyko dla Twojej organizacji. Ocena kontekstowa uwzględnia, jakie dane chroni system i kto ma do niego dostęp - dlatego luka w systemie z danymi o zdrowiu może dostać wyższy priorytet niż ta sama luka w narzędziu wewnętrznym. Więcej w haśle CVSS.
Od czego zależy liczba ustaleń w raporcie?
Od zakresu i podejścia oraz od dojrzałości systemu. Test black box z zewnątrz, np. w pakiecie Audyt Zewnętrzny opisanym na stronie testów penetracyjnych, obejmuje mniej funkcji niż test grey box z kontami w każdej roli, a w systemie testowanym wcześniej część podatności mogła zostać już usunięta. Sama liczba nie mówi ani o jakości testu, ani o poziomie ryzyka - jedno ustalenie Critical może ważyć więcej niż wiele ustaleń Low. W tym przykładzie pokazujemy cztery ustalenia, żeby zaprezentować format, a nie typową liczbę.
Źródła
- OWASP Mobile Application Security Verification Standard (MASVS) - wydania, v2.1.0 ()
- OWASP MASVS - MASVS-STORAGE-1 ()
- OWASP MASVS - MASVS-AUTH-1 ()
- OWASP MASVS - MASVS-PLATFORM-3 ()
- OWASP Mobile Application Security Testing Guide (MASTG) ()
- OWASP Web Security Testing Guide v4.2 - WSTG-ATHN-03 Testing for Weak Lock Out Mechanism ()
- OWASP API Security Top 10 2023 ()
- OWASP Application Security Verification Standard (ASVS) 5.0.0 ()
- PTES - Penetration Testing Execution Standard ()
- NIST SP 800-115 - Technical Guide to Information Security Testing and Assessment ()
- FIRST - Common Vulnerability Scoring System v3.1: Specification Document ()
- MITRE CWE-306: Missing Authentication for Critical Function ()
- MITRE CWE-312: Cleartext Storage of Sensitive Information ()
- MITRE CWE-307: Improper Restriction of Excessive Authentication Attempts ()
- MITRE CWE-200: Exposure of Sensitive Information to an Unauthorized Actor ()
Powiązane usługi
Cyberbezpieczeństwo · Audyt bezpieczeństwa
Audyt bezpieczeństwa IT
Audyt bezpieczeństwa IT dla firm: aplikacje, API, kod, chmura, sieć i AI oraz zgodność z NIS2/KSC i DORA. Dobór zakresu, raport z dowodami, retest. Cała Polska.
Cyberbezpieczeństwo · Testy penetracyjne
Testy penetracyjne
Testy penetracyjne aplikacji webowych i mobilnych, API, infrastruktury, chmury i kodu. OWASP, PTES, raport z dowodami i retest po naprawach.