Aplikacja mobilna to nie tylko ekran w telefonie. To kod klienta, lokalne dane, komunikacja z API, mechanizmy sesji, certyfikaty, logi, konfiguracja i backend. Dlatego test mobilny powinien obejmować zarówno samą aplikację Android/iOS, jak i usługi, z którymi aplikacja rozmawia.
Najczęstszy błąd przy zamawianiu testów mobile polega na rozdzieleniu aplikacji i API tak, jakby były niezależne. W praktyce aplikacja mobilna jest często najlepszą dokumentacją backendu: pokazuje endpointy, parametry, identyfikatory, formaty tokenów, mechanizmy synchronizacji i ukryte funkcje.
Co sprawdzamy w aplikacji mobilnej
Zakres zależy od platformy i modelu dystrybucji, ale typowy test obejmuje analizę statyczną, analizę dynamiczną, komunikację sieciową, przechowywanie danych lokalnie, odporność na modyfikację, obsługę root/jailbreak, zarządzanie sesją, logi, konfigurację i API.
| Obszar | Przykładowe testy | Ryzyko |
|---|---|---|
| Local storage | SharedPreferences, Keychain, SQLite, cache, pliki | wyciek tokenów, danych osobowych, sekretów |
| Komunikacja | HTTPS, cert pinning, proxy, błędy TLS | podsłuch lub manipulacja ruchem |
| Reverse engineering | dekompilacja, stringi, konfiguracja, ukryte endpointy | ujawnienie logiki, kluczy, adresów środowisk |
| API | BOLA, role, rate limit, dane nadmiarowe | dostęp do cudzych danych mimo poprawnego UI |
| Runtime | root/jailbreak, hookowanie, manipulacja aplikacją | obejście zabezpieczeń klienta |
Analiza statyczna: co można zobaczyć bez uruchamiania aplikacji
W Androidzie analiza APK pozwala sprawdzić manifest, uprawnienia, konfigurację network security, biblioteki, stringi, adresy endpointów, mechanizmy logowania, zaszyte klucze, linki deep link i fragmenty logiki. W iOS analiza IPA ma inne ograniczenia, ale nadal pozwala zbadać strukturę aplikacji, konfigurację i część artefaktów.
Najczęstsze problemy to nadmiarowe uprawnienia, debugowe endpointy, zaszyte sekrety, brak ochrony przed backupem danych, podatne zależności, zbyt szczegółowe logi i konfiguracje pozwalające na ruch nieszyfrowany w określonych warunkach.
Local storage: telefon nie jest sejfem
Aplikacje mobilne często przechowują tokeny, dane użytkownika, ustawienia, cache odpowiedzi API, pliki PDF, historię operacji i logi. Część z tych danych jest potrzebna, ale powinna być minimalizowana i odpowiednio chroniona. Inaczej zgubiony telefon, backup, malware albo dostęp do urządzenia testowego może ujawnić informacje, które nie powinny opuszczać backendu.
Przykładowe znalezisko:
Plik: /data/data/app.example/shared_prefs/session.xml
Problem: token odświeżania przechowywany jawnie
Wpływ: osoba z dostępem do urządzenia/root może odtworzyć sesję
Rekomendacja: użyć Android Keystore, skrócić żywotność tokenu, wprowadzić rotacjęCert pinning: dobry mechanizm, ale nie magiczna tarcza
Cert pinning utrudnia podsłuch ruchu przez nieautoryzowany certyfikat, ale nie zastępuje bezpieczeństwa API. W testach sprawdzamy, czy pinning istnieje, czy jest poprawnie wdrożony, czy można go obejść przez konfigurację debug, hookowanie lub słabe biblioteki, a przede wszystkim: co widać po przechwyceniu ruchu w kontrolowanym środowisku testowym.
Kluczowe jest to, że nawet idealny pinning nie naprawi BOLA w API. Jeżeli użytkownik może zmienić ID dokumentu i pobrać cudze dane, problem jest po stronie backendu. Aplikacja mobilna tylko pomaga odkryć scenariusz.
API mobilne: najczęstsze miejsce krytycznych podatności
W praktyce najpoważniejsze znaleziska w testach mobile często występują w API. Aplikacja pokazuje przepływ, ale backend musi sprawdzić role, obiekty, tenanty, limity i uprawnienia. Tester pracuje na kilku kontach, analizuje requesty, zmienia parametry i sprawdza, czy API odpowiada zgodnie z modelem bezpieczeństwa.
PUT /mobile-api/v1/users/1002/profile HTTP/1.1
Authorization: Bearer token_user_1001
Content-Type: application/json
{"phone":"+48123123123"}
# Oczekiwane: odmowa
# Podatne API: aktualizacja profilu innego użytkownikaTego typu problem nie jest „mobilny” w sensie technicznym, ale został odkryty dzięki testowi mobilnemu. Dlatego zamawiając pentest aplikacji mobilnej warto uwzględnić backend.
Root/jailbreak i odporność na manipulację
Nie każda aplikacja musi blokować urządzenia z rootem lub jailbreakiem. To decyzja zależna od ryzyka. Aplikacja bankowa, medyczna lub firmowa z danymi wrażliwymi zwykle wymaga większej ochrony niż aplikacja informacyjna. Ważne, aby decyzja była świadoma, a mechanizmy nie dawały fałszywego poczucia bezpieczeństwa.
Sprawdzamy, czy aplikacja wykrywa środowisko testowe, czy logika zabezpieczeń jest tylko po stronie klienta, czy można hookować funkcje krytyczne, czy dane są chronione nawet w trudniejszych warunkach i czy backend nie ufa flagom przesyłanym przez aplikację.
Raport z testu mobile
Dobry raport mobile powinien rozdzielać podatności aplikacji, podatności API i decyzje architektoniczne. Dla każdego znaleziska potrzebny jest wpływ, warunki wykorzystania, dowód, rekomendacja i kryterium retestu. Przy danych lokalnych warto wskazać dokładne miejsce przechowywania. Przy API — request/response i rolę użytkownika. Przy reverse engineering — artefakt i wpływ na bezpieczeństwo.
Mobile to aplikacja, API i urządzenie jednocześnie
Test aplikacji mobilnej nie powinien ograniczać się do analizy APK albo IPA. Aplikacja mobilna przechowuje tokeny, komunikuje się z API, używa mechanizmów systemowych, obsługuje certyfikaty, czasem działa offline i często ma uproszczone ścieżki UX. Każdy z tych elementów może wprowadzać ryzyko.
Najważniejsze obszary testu mobile
- lokalne przechowywanie tokenów, danych osobowych i konfiguracji,
- komunikacja TLS, certificate pinning i obsługa proxy,
- reverse engineering, sekrety, klucze i endpointy w aplikacji,
- autoryzacja i logika biznesowa po stronie API,
- bezpieczeństwo deep linków, intentów, WebView i plików,
- zgodność z OWASP MASVS i MASTG.
W praktyce wiele krytycznych błędów mobile okazuje się błędami backendu. Aplikacja mobilna pomaga je znaleźć, bo pokazuje endpointy, parametry, sposób autoryzacji i założenia projektowe.