Zakres testów

Testy penetracyjne
aplikacji mobilnych

Aplikacja mobilna to dwa osobne problemy: kod, który trafia na urządzenie użytkownika i przestaje być Twoją tajemnicą, oraz backend, który tej aplikacji ufa. Rozbieramy pakiet APK i IPA na części, podglądamy ruch mimo pinningu i sprawdzamy, co zostaje w pamięci telefonu po wylogowaniu.

  • Android i iOS, w tym Flutter oraz React Native
  • Analiza statyczna, dynamiczna i testy backendu w jednym zakresie
  • Weryfikacja według OWASP MASVS i MASTG

Aplikacje mobilne

Czas trwania
zwykle 7-15 dni roboczych
Pracujemy według
  • OWASP Mobile Application Security Verification Standard (MASVS)
  • OWASP Mobile Application Security Testing Guide (MASTG)
  • OWASP Mobile Top 10
  • PTES

Co dokładnie sprawdzamy

Zakres dopasowujemy do Twojego środowiska, ale te obszary bierzemy pod lupę zawsze.

1

Analiza statyczna i reverse engineering

Dekompilacja pakietu, przegląd kodu i zasobów. Szukamy zaszytych kluczy API, danych logowania do usług, adresów środowisk testowych i logiki, która powinna być po stronie serwera.

2

Dane na urządzeniu

Keychain i Keystore, SharedPreferences, bazy SQLite, pliki tymczasowe, pamięć podręczna WebView, logi systemowe, kopie zapasowe i zrzuty ekranu w przełączniku aplikacji.

3

Komunikacja z backendem

Poprawność TLS i walidacja certyfikatu, obecność oraz jakość certificate pinningu, próba jego obejścia, dane wrażliwe w parametrach adresu, brak szyfrowania w kanałach pobocznych.

4

Uwierzytelnianie i autoryzacja

Cykl życia tokenów, odświeżanie sesji, wylogowanie na wszystkich urządzeniach, biometria i jej obejście, kod PIN, przejęcie konta przez deep link lub własny schemat URL.

5

Odporność środowiskowa

Zachowanie na urządzeniu z rootem i po jailbreaku, wykrywanie debuggera i emulatora, odporność na wstrzykiwanie kodu w czasie działania (Frida, objection), integralność pakietu po repackagingu.

6

API mobilne

Backend testujemy w pełnym zakresie aplikacji webowej: kontrola dostępu, IDOR, logika biznesowa i limity. Endpointy mobilne bywają starsze i mniej pilnowane niż te używane przez stronę.

Co najczęściej znajdujemy

Przykłady z naszych projektów w tym zakresie. Nazwy klientów i szczegóły techniczne zostają w raportach.

  • Klucz API do usługi płatniczej zaszyty w kodzie aplikacji
  • Token sesji zapisany w postaci jawnej w SharedPreferences
  • Certificate pinning obchodzony w kilka minut, bez dodatkowej kontroli po stronie serwera
  • Deep link uruchamiający akcję na koncie bez potwierdzenia użytkownika
  • Dane osobowe w logach systemowych czytelnych dla innych aplikacji
  • Weryfikacja uprawnień wykonywana wyłącznie w aplikacji, nie na backendzie
  • Brak unieważnienia tokenu po wylogowaniu i po zmianie hasła
  • Aktywna konfiguracja debugowania w wydaniu produkcyjnym

Wybrane narzędzia

MobSFFridaobjectionjadx i apktoolBurp Suite Professional

Narzędzia skracają pracę powtarzalną. Wnioski i łańcuchy ataku budujemy ręcznie.

Przebieg testu i raport

Proces testowy, forma raportu oraz zasady retestów są wspólne dla wszystkich zakresów.

Zobacz pełny proces i zawartość raportu

Najczęstsze pytania

Czy potrzebujecie kodu źródłowego?

Nie, standardowo pracujemy w podejściu black box na gotowym pakiecie APK i IPA. Dostęp do kodu skraca czas i pozwala potwierdzić przyczynę błędu, więc jeśli możesz go udostępnić, test będzie dokładniejszy.

Jak przekazać wersję do testów na iOS?

Najwygodniej przez TestFlight albo plik IPA z profilem ad hoc obejmującym nasze urządzenia. Potrzebujemy wersji bez wymuszonej aktualizacji, która pozwoli pracować przez cały okres testów.

Czy testujecie aplikacje we Flutterze i React Native?

Tak. Różni się głównie warstwa analizy statycznej i sposób podpięcia się pod ruch sieciowy. Zakres testów, standardy i forma raportu pozostają takie same.

Czy backend trzeba zamawiać osobno?

Nie, API wykorzystywane przez aplikację jest częścią tego zakresu. Osobno wyceniamy tylko sytuację, w której ten sam backend obsługuje dużą aplikację webową i chcesz ją objąć testami w całości.