Pentest aplikacji mobilnej Android i iOS — przewodnik

Pentest aplikacji mobilnej sprawdza znacznie więcej niż podatności widoczne w ruchu HTTP. Tester analizuje pakiet APK lub IPA, dane zapisane na urządzeniu, kryptografię, komunikację sieciową, mechanizmy uwierzytelniania, interakcje z Androidem lub iOS, odporność na modyfikację oraz API obsługujące aplikację. Sam skan binarki albo przechwycenie kilku żądań nie daje pełnej oceny.

Najlepszym punktem odniesienia są aktualne projekty OWASP Mobile Application Security: MASVS definiuje wymagania, MASTG opisuje techniki testowe, MASWE porządkuje słabości, a MAS Checklist łączy kontrolki z konkretnymi testami. W tym przewodniku pokazujemy, jak przełożyć te materiały na realny zakres, przygotować środowisko i ocenić ofertę.

Co obejmuje pentest aplikacji mobilnej

Pełny system mobilny składa się co najmniej z trzech warstw:

Klient mobilny — kod, biblioteki, lokalne dane, konfiguracja, mechanizmy platformy i odporność na analizę.
Komunikacja — TLS, certificate pinning, format żądań, sesje, tokeny i odporność na przechwycenie albo modyfikację ruchu.
Backend i API — autoryzacja, logika biznesowa, role, separacja użytkowników, zasoby i integracje.

OWASP wyraźnie zaznacza, że MASVS obejmuje klienta mobilnego, a zdalne endpointy powinny zostać sprawdzone innymi standardami, np. ASVS i OWASP API Security. Oferta „pentest mobile” bez backendu może być poprawna, jeśli zakres jest jawny, ale nie daje oceny bezpieczeństwa całej usługi.

W praktyce najgroźniejsze scenariusze często łączą warstwy. Aplikacja przechowuje token zbyt słabo, a API pozwala użyć go bez kontroli urządzenia. Albo klient ukrywa funkcję administracyjną, lecz backend nie sprawdza roli i przyjmuje ręcznie zbudowane żądanie.

MASVS, MASTG, MASWE i Checklist — co oznaczają

OWASP MASVS grupuje wymagania w ośmiu obszarach:

MASVS-STORAGE — bezpieczne przechowywanie danych;
MASVS-CRYPTO — prawidłowe użycie kryptografii;
MASVS-AUTH — uwierzytelnianie i autoryzacja;
MASVS-NETWORK — ochrona komunikacji;
MASVS-PLATFORM — bezpieczna współpraca z funkcjami systemu;
MASVS-CODE — jakość i aktualność kodu;
MASVS-RESILIENCE — odporność na analizę oraz modyfikację;
MASVS-PRIVACY — kontrolki prywatności.

MASTG to przewodnik z technikami i przypadkami testowymi osobnymi dla Androida oraz iOS. MASWE opisuje klasy słabości. MAS Checklist ułatwia śledzenie, które testy wykonano i do jakiej wersji standardu się odnoszą.

Ważna aktualizacja: od MASVS 2.0 sam standard nie zawiera dawnych poziomów L1, L2 i R. OWASP przenosi logikę do MAS Testing Profiles i atomowych testów. Oferta bazująca na „certyfikacji MASVS L1” powinna wskazać konkretną wersję checklisty i profil, a nie używać starej etykiety bez wyjaśnienia. OWASP nie certyfikuje firm ani aplikacji i ostrzega przed sugerowaniem oficjalnego znaku zaufania.

Co testuje się po stronie Androida

W Androidzie analizuje się manifest, komponenty eksportowane, intent filters, custom permissions, deep links, WebView, backup, debugowanie oraz konfigurację sieci. Tester sprawdza, czy Activity, Service, BroadcastReceiver lub ContentProvider nie udostępnia funkcji obcej aplikacji bez właściwej autoryzacji.

Istotne są dane lokalne: SharedPreferences, bazy SQLite, cache, logi, pliki tymczasowe i schowek. Sekret zapisany w Keystore może być dobrze chroniony, ale aplikacja może wcześniej wypisać go do logu albo umieścić w łatwo dostępnej kopii.

Analiza statyczna obejmuje dekompilację, sekrety w kodzie, biblioteki, mechanizmy kryptograficzne i ukryte endpointy. Analiza dynamiczna sprawdza zachowanie procesu, hookowanie, emulator, modyfikację żądań oraz reakcję na root. Sam fakt wykrywania roota nie jest zabezpieczeniem danych. Należy ocenić, jaki scenariusz biznesowy ma utrudniać i czy nie blokuje legalnych użytkowników bez realnej ochrony backendu.

Co testuje się po stronie iOS

W iOS zakres obejmuje entitlements, konfigurację aplikacji, Keychain, Data Protection API, pliki i backup, Universal Links, URL schemes, pasteboard, WebView oraz komunikację z innymi aplikacjami. Tester analizuje pakiet, frameworki, symbole i ustawienia kompilacji, a dynamicznie obserwuje zachowanie na urządzeniu testowym.

Jailbreak i instrumentacja pomagają sprawdzić, czy dane lub decyzje bezpieczeństwa można przejąć w runtime. Celem nie jest udowodnienie, że lokalny właściciel urządzenia może zmienić własną aplikację — to zwykle oczywiste. Wartością jest pokazanie wpływu: przejęcia tokenu, ominięcia kontroli transakcji, wydobycia klucza, manipulacji parametrem albo naruszenia danych innego użytkownika.

Podobnie jak w Androidzie, ochrona klienta nie może zastępować autoryzacji serwerowej. Każdą decyzję wpływającą na pieniądze, dane lub uprawnienia backend musi zweryfikować niezależnie.

Przechowywanie danych i kryptografia

Tester zaczyna od inwentaryzacji: jakie dane aplikacja przechowuje, po co, jak długo i kto może je odczytać. Szuka tokenów sesyjnych, danych osobowych, dokumentów, historii aktywności, kluczy oraz informacji diagnostycznych.

Szyfrowanie pliku nie rozwiązuje problemu, jeśli klucz znajduje się obok albo jest stałą w kodzie. Własny algorytm kryptograficzny jest kolejnym sygnałem ostrzegawczym. Aplikacja powinna używać sprawdzonych mechanizmów platformy i ograniczać dane do niezbędnego minimum.

Test obejmuje także snapshoty ekranu, powiadomienia, przełącznik aplikacji, schowek i logi. Kod MFA widoczny w powiadomieniu lub numer dokumentu pozostawiony w cache może ominąć poprawne szyfrowanie głównej bazy.

W obszarze prywatności warto połączyć MASVS-PRIVACY z wymaganiami RODO i rzeczywistą deklaracją aplikacji. Pentest techniczny nie jest pełnym audytem prawnym, ale może wykazać, że aplikacja zbiera lub zachowuje więcej danych, niż zakłada projekt.

Komunikacja sieciowa i certificate pinning

Podstawą jest poprawny TLS, walidacja nazwy hosta i brak niebezpiecznych wyjątków. Tester próbuje przechwycić ruch, analizuje zachowanie po błędzie certyfikatu oraz sprawdza, czy aplikacja nie przechodzi awaryjnie na HTTP.

Certificate pinning może utrudnić atak z fałszywym urzędem certyfikacji, ale zwiększa złożoność operacyjną. Błędna rotacja certyfikatu może zablokować wszystkich klientów. Pinning nie naprawia też BOLA, błędnej sesji ani wycieku tokenu. W teście ocenia się zarówno możliwość obejścia w zmodyfikowanym kliencie, jak i wpływ na realistyczny scenariusz.

Ruch sieciowy ujawnia często nieudokumentowane endpointy, identyfikatory obiektów i nadmiarowe dane. Jest punktem startu do pentestu API, nie jego końcem.

Uwierzytelnianie, biometria i sesje

Biometria w aplikacji mobilnej zwykle odblokowuje lokalny sekret lub sesję; nie jest magicznym dowodem tożsamości przesyłanym do serwera. Tester sprawdza, czy aplikacja właściwie używa mechanizmów platformy, czy można pominąć prompt oraz co dzieje się po zmianie biometrii na urządzeniu.

Ważne są reset hasła, rejestracja urządzenia, MFA, wylogowanie, utrata telefonu, unieważnienie tokenów i ponowne uwierzytelnienie dla operacji wysokiego ryzyka. Sesja powinna wygasać i dać się cofnąć z innego urządzenia. Token nie może pozostawać ważny bez końca tylko dlatego, że aplikacja przechowuje go w bezpiecznym magazynie.

Testy wielokontowe pozwalają wykryć, czy użytkownik A może użyć identyfikatora użytkownika B albo wykonać funkcję zarezerwowaną dla pracownika. To obszar wspólny z bezpieczeństwem API.

Odporność na reverse engineering i manipulację

Obfuscation, anti-debugging, integralność i wykrywanie zmodyfikowanego środowiska utrudniają analizę, ale nie tworzą absolutnej bariery. Wysoki poziom odporności ma sens szczególnie dla aplikacji finansowych, DRM, kluczy biznesowych i mechanizmów przeciwdziałania oszustwom.

Tester ocenia, czy napastnik może zmienić przepływ, ominąć ograniczenie, podmienić wynik lokalnej kontroli lub poznać protokół. Rekomendacja powinna uwzględniać koszt i cel. Dodanie kolejnej warstwy zaciemnienia do aplikacji bez wrażliwych lokalnych decyzji może być mniej ważne niż naprawa autoryzacji backendu.

Jak przygotować aplikację do testu

Najlepszy model to open book review rekomendowany przez OWASP dla szerokiej weryfikacji. Przygotuj:

pliki APK/AAB i IPA albo dostęp do TestFlight;
wersję produkcyjną oraz debug, jeśli zachowanie się różni;
konta dla każdej roli i co najmniej dwóch niezależnych użytkowników;
dokumentację API, diagram logowania i listę integracji;
urządzenia lub zgodę na urządzenia testera;
informacje o pinningu, mechanizmach anti-tamper i root/jailbreak;
kod źródłowy lub wybrane moduły przy white box;
bezpieczne dane testowe i procedurę sprzątania;
kontakt awaryjny oraz zakres niedozwolonych działań.

Warto zamrozić wersję na czas testu. Jeśli build zmienia się codziennie, część dowodów przestaje być odtwarzalna. Krytyczne poprawki można wdrażać, ale zespół powinien informować testera o zmianie.

Jak wygląda raport i retest

Raport powinien rozdzielać Android, iOS, elementy wspólne i backend. Każde znalezisko musi mieć dowód, wpływ, dotknięte wersje, mapowanie do MASVS/MASTG lub ASVS oraz jasną naprawę. Sam wynik skanera nie jest dowodem wykonania pełnego profilu.

Dobrą praktyką jest macierz pokrycia z wersją standardu i identyfikatorami testów. Dzięki temu kolejny zespół rozumie, co rzeczywiście sprawdzono. OWASP zaleca zachowanie work papers, logów proxy, skryptów i materiałów umożliwiających powtórzenie w kontrolowanych warunkach.

Retest powinien objąć nie tylko zamknięcie konkretnego PoC, ale też warianty i wpływ poprawki na obie platformy. Zmiana po stronie backendu może naprawić Android i iOS, podczas gdy lokalna poprawka tylko jednego klienta pozostawi drugi podatny.

Automatyczny skan a manualny pentest mobile

Narzędzia takie jak skanery zależności i analiza binarki są użyteczne w CI/CD. Szybko wykrywają niebezpieczne flagi, znane biblioteki, sekrety i część złych praktyk. Nie rozumieją jednak wszystkich przepływów biznesowych, relacji między rolami ani wpływu zmodyfikowanego klienta na API.

OWASP wprost wskazuje, że samo uruchomienie narzędzia i zaraportowanie błędów nie zapewnia wystarczającego dowodu pełnej weryfikacji. Najlepszy proces łączy automatyzację przy każdym buildzie z manualnym testem przed ważną premierą i po zmianie krytycznych mechanizmów.

Najczęstsze pytania

Czy trzeba testować osobno Android i iOS? Tak. Backend i część logiki są wspólne, ale systemy mają inne magazyny danych, mechanizmy uprawnień, linki, WebView i zabezpieczenia kompilacji. Zakres można zoptymalizować, lecz nie traktować platform jako identycznych.

Czy pentest mobile obejmuje API? Tylko jeśli zapisano to w zakresie. MASVS koncentruje się na kliencie. Backend powinien przejść osobny, choć skoordynowany pentest API.

Czy aplikacja dostanie certyfikat OWASP? Nie. OWASP nie certyfikuje aplikacji ani dostawców. Raport może potwierdzić zakres weryfikacji względem określonej wersji standardu.

Czy root lub jailbreak automatycznie oznacza podatność? Nie. Tester musi pokazać wpływ. Właściciel urządzenia ma dużą kontrolę nad środowiskiem; ważne jest, czy może naruszyć dane, konta lub zaufanie backendu.

Kiedy wykonać test? Przed publicznym wdrożeniem, po dużej zmianie logowania, płatności, API lub magazynu danych oraz okresowo dla aplikacji wysokiego ryzyka. Przygotowania opisuje też ogólny przewodnik przed pentestem.

Podsumowanie

Pentest aplikacji mobilnej powinien objąć klienta Android/iOS, dane lokalne, platformę, komunikację, sesje, kryptografię, prywatność, odporność na modyfikację oraz uzgodniony backend. MASVS definiuje wymagania, MASTG dostarcza techniki, a aktualne profile i checklisty dają śledzenie pokrycia.

Najważniejsze jest jawne rozdzielenie tego, co przetestowano. Skan APK nie jest testem całej usługi, a poprawne TLS nie oznacza bezpiecznego API. Jeśli planujesz premierę lub znaczącą zmianę aplikacji, ustalmy zakres klienta i backendu, zanim wycena sprowadzi się do samej liczby ekranów.

Źródła i dalsza lektura: OWASP MASVS, OWASP MAS Checklist, OWASP — Assessment and Certification, MAS Testing Profiles, CERT Polska — raport 2025 i projekt Deckard.