Testing Workflow

Proces testów bezpieczeństwa aplikacji mobilnych można podzielić na kilka głównych etapów, które obejmują zarówno analizę statyczną, jak i dynamiczną, a także manualne testy logiki i przygotowanie dokumentacji. Taki workflow jest spójny z podejściem stosowanym w testach penetracyjnych (pentestach) oraz recenzjach bezpieczeństwa aplikacji mobilnych.

  1. Static Analysis of IPA ↳ Pliki, zaszyte dane, reverse engineering
  2. Install and extract data from device ↳ Pliki runtime, katalogi, Keychain
  3. Dynamic Analysis (frida, burp, debug) ↳ Hookowanie metod, intercept HTTPS, RCE
  4. Manual Tests (authentication, crypto, logic)
  5. Dokumentacja (raport, CVSS, ryzyka CIA)

1. Static Analysis (SAST)

Analiza statyczna polega na badaniu aplikacji bez jej uruchamiania. W kontekście iOS oznacza to pracę z plikiem .ipa lub .app, a w przypadku Androida — z plikiem .apk.

  • Pliki i zaszyte dane — analiza zawartości paczki instalacyjnej, w tym zasobów, konfiguracji i metadanych.
  • Hardcoded secrets — wyszukiwanie kluczy API, tokenów, haseł i innych poufnych danych w kodzie lub plikach.
  • Reverse engineering — dekompilacja i analiza binarki w celu zrozumienia implementacji mechanizmów bezpieczeństwa.
  • Automaty i ręczna analiza — połączenie narzędzi SAST z manualnym code review, co pozwala wykryć błędy logiki biznesowej, których skanery często nie identyfikują.

2. Runtime Analysis and Extraction

Po instalacji aplikacji na urządzeniu lub emulatorze możliwa jest analiza zachowania w czasie rzeczywistym i inspekcja danych zapisanych w systemie plików.

  • Pliki runtime i katalogi — przeglądanie przestrzeni sandbox aplikacji (np. /Documents, /Library, /Caches).
  • Keychain / Keystore — analiza sposobu przechowywania danych uwierzytelniających i tokenów.
  • Konfiguracje i logi — sprawdzanie, czy w logach lub plikach tymczasowych nie trafiają dane wrażliwe.

3. Dynamic Analysis (DAST)

Analiza dynamiczna polega na testowaniu aplikacji w trakcie jej działania, przy użyciu narzędzi do debugowania, interceptowania ruchu sieciowego i hookowania metod.

  • Frida — dynamiczne hookowanie metod, sprawdzanie zabezpieczeń (np. jailbreak detection, kontrola dostępu).
  • Burp Suite / mitmproxy — przechwytywanie i modyfikacja ruchu HTTPS, analiza komunikacji z API, weryfikacja cert pinningu.
  • Debugger i emulator — monitorowanie zachowania aplikacji, identyfikowanie potencjalnych RCE (Remote Code Execution).
  • Symulacja ataków — sprawdzanie skuteczności zabezpieczeń przed typowymi wektorami ataku (np. brute force, replay attack).

4. Manual Tests

Nawet najlepsze narzędzia automatyczne nie zastąpią testów ręcznych, które pozwalają zweryfikować błędy logiki i implementacji zabezpieczeń.

  • Authentication & Authorization — testy logowania, sesji, zarządzania tokenami i wieloskładnikowego uwierzytelniania.
  • Cryptography — weryfikacja poprawności użycia algorytmów szyfrujących, generatorów liczb losowych i bibliotek kryptograficznych.
  • Business Logic — wykrywanie błędów w logice aplikacji, które mogą pozwolić na obejście zabezpieczeń, mimo technicznie poprawnej implementacji.

5. Documentation & Reporting

Ostatnim etapem jest przygotowanie raportu, który nie tylko opisuje znalezione podatności, ale także przedstawia ich ocenę i rekomendacje.

  • Opis metod i narzędzi — dokumentacja przebiegu analizy, użytych technik i narzędzi.
  • Klasyfikacja podatności — priorytetyzacja zgodnie z CVSS, OWASP MASVS i kontekstem biznesowym.
  • Ocena ryzyka CIA — wpływ na poufność (Confidentiality), integralność (Integrity) i dostępność (Availability).
  • Rekomendacje — konkretne zalecenia naprawcze, wskazujące jak zminimalizować ryzyko i poprawić poziom zabezpieczeń aplikacji.

References