Pentest aplikacji mobilnych - Android, iOS oraz inne
Twoja aplikacja mobilna stanowi coraz ważniejszy kanał kontaktu z klientem. Działa jednak na urządzeniu, którego nie kontrolujesz. Atakujący instaluje ją na własnym telefonie, rozpakowuje, podgląda ruch do API i modyfikuje jej działanie w trakcie pracy. Testujemy dokładnie z tej pozycji.
Sprawdzamy aplikację razem z jej zapleczem: dane zapisywane na urządzeniu, komunikację z backendem, uwierzytelnianie, logikę biznesową i odporność na analizę wsteczną. Pracujemy zgodnie z OWASP MASVS, MASTG i Mobile Top 10.
Doświadczenie: ponad 500 testów penetracyjnych rocznie, m.in. dla banków, domów maklerskich, firm leasingowych, energetycznych, telekomunikacyjnych, produkcyjnych i e-commerce.
Dowiedz się więcejDlaczego pentesty aplikacji mobilnych wymagają osobnego podejścia?
W aplikacji mobilnej połowa logiki trafia na telefon użytkownika i przestaje być Twoja. Stąd:
-
Kod jest do wglądu
Aplikacje mobilne Android (APK) i iOS (IPA) da się rozpakować i zdekompilować. Klucze API, hasła serwisowe, adresy środowisk testowych, dane dostępowe do usług zewnętrznych i zakomentowane funkcje debugowe zostają w pliku, który dowolna osoba pobiera ze sklepu. -
Zabezpieczenia po stronie aplikacji mobilnej da się wyłączyć
Wykrywanie roota i jailbreaka, certificate pinning, blokada debugowania - to wszystko działa dopóki ktoś nie podmieni odpowiedniego fragmentu w pamięci. Sprawdzamy, co zostaje z bezpieczeństwa aplikacji po obejściu tych mechanizmów. -
Backend często ufa aplikacji
Jeżeli walidacja kwoty przelewu, ceny w koszyku albo limitu transakcji odbywa się wyłącznie w aplikacji mobilnej, wystarczy zmodyfikować żądanie. To najczęstsze poważne znalezisko w pentestach aplikacji mobilnych i zawsze wynika z założenia, że klient mobilny jest zaufany.
Skontaktuj się z nami
Co obejmuje test penetracyjny aplikacji mobilnej
Zakres pentestów sieci ustalamy przed startem, ale w typowym projekcie testów aplikacji mobilnej weryfikujemy:
Analiza pliku aplikacji
Dekompilacja APK i IPA, przegląd zasobów i konfiguracji, wyszukiwanie zaszytych sekretów, kluczy i adresów. Ocena skuteczności obfuskacji oraz mechanizmów utrudniających modyfikację i uruchomienie zmodyfikowanej wersji.
Komunikacja z backendem i API
Przechwytywanie ruchu, próby ataku Man-in-the-Middle, weryfikacja certificate pinningu i konfiguracji TLS. Testujemy też samo API (zależnie od zakresu): manipulację żądaniami, dostęp do danych innych użytkowników (IDOR), nadmiarowe dane w odpowiedziach i brak limitów po stronie serwera.
Uwierzytelnianie i sesja
Obejście logowania, obsługa biometrii, żywotność i unieważnianie tokenów, zachowanie aplikacji po zmianie hasła, brak ograniczeń liczby prób logowania, poprawność wylogowania na wszystkich urządzeniach.
Logika biznesowa
Najczęściej najkosztowniejsza kategoria błędów. Manipulacja procesem płatności, cenami, rabatami, punktami lojalnościowymi, kolejnością kroków w procesie, powtarzanie operacji, które powinny wykonać się raz.
Zachowanie w środowisku systemowym
Nadmiarowe uprawnienia, eksportowane komponenty Androida, obsługa deep linków, dane pozostające w zrzutach ekranu i w schowku, integracje z zewnętrznymi SDK, konfiguracja App Transport Security i backupu.
Testy dynamiczne w runtime
Podpinamy się do działającej aplikacji, podmieniamy zwracane wartości, wyłączamy kontrole po stronie klienta i sprawdzamy, jak zachowa się serwer, gdy dostanie żądanie, którego aplikacja nigdy nie powinna wysłać.
Analiza danych zapisywanych na urządzeniu
Sprawdzamy, jakie dane aplikacja mobilna zapisuje na urządzeniu podczas swojego działania. Weryfikujemy, czy informacje wrażliwe, takie jak dane osobowe, tokeny uwierzytelniające lub dane sesyjne, są odpowiednio chronione i nie są przechowywane w formie jawnej. Nieprawidłowa konfiguracja aplikacji lub niewłaściwy sposób przechowywania danych może doprowadzić do ich ujawnienia i wykorzystania przez osobę nieuprawnioną.
Kiedy zamówić test penetracyjny aplikacji mobilnych
- Przed publikacją w Google Play lub App Store, zanim aplikacja trafi do użytkowników.
- Po dodaniu lub modyfikacji funkcji dotyczącej pieniędzy, danych osobowych albo uwierzytelniania czy autoryzacji.
- Po integracji z nowym API, dostawcą płatności lub zewnętrznym SDK, lub po wykorzystaniu nowych bibliotek.
- Przed audytem, certyfikacją albo przeglądem bezpieczeństwa u klienta korporacyjnego.
- Po incydencie, żeby potwierdzić, że ta sama klasa błędu nie występuje w innych miejscach aplikacji.
- Cyklicznie, co 3 do 24 miesięcy, zależnie od wrażliwości danych i tempa wydawania nowych wersji.
Aplikacja mobilna a wymogi NIS2, UoKSC, CRA i DORA
Nowelizacja ustawy o krajowym systemie cyberbezpieczeństwa, wdrażająca dyrektywę NIS2, weszła w życie 3 kwietnia 2026 r. Podmioty kluczowe i ważne mają czas na dostosowanie do 3 kwietnia 2027 r., a podmioty kluczowe muszą przeprowadzić pierwszy audyt bezpieczeństwa do 3 kwietnia 2028 r. i powtarzać go nie rzadziej niż co trzy lata. Instytucje finansowe realizują równolegle obowiązki z rozporządzenia DORA.
Od 11 września 2026 r. producentów produktów z elementami cyfrowymi obowiązuje wynikający z rozporządzenia CRA obowiązek zgłaszania aktywnie wykorzystywanych podatności oraz poważnych incydentów, w krótkich terminach liczonych w godzinach. Pełne stosowanie rozporządzenia, wraz z wymogami zasadniczymi i dokumentacją zgodności, nastąpi 11 grudnia 2027 r. Sankcje sięgają 15 mln euro lub 2,5% światowego obrotu.
Aplikacje mobilne – szczególnie dostarczane klientom mogą podlegać CRA, a to ich bezpieczeństwo wpływa na podatności i potencjalne incydenty, o których mowa w CRA.
Żaden z tych przepisów nie wymienia pentestu aplikacji mobilnej z nazwy. Wszystkie wymagają natomiast dowodu, że zabezpieczenia zostały sprawdzone w praktyce, a ryzyko oszacowane. Raport z testów dostarcza tego dowodu dla kanału, przez który obsługujesz największą część klientów. Jeżeli chcesz połączyć testy z warstwą formalną, zobacz audyt zgodności z NIS2 i UoKSC.
Sprawdź, co da się zrobić z Twoją aplikacją
Umów bezpłatną konsultację. Ustalimy zakres testów penetracyjnych aplikacji mobilnej, termin i pracochłonność.
Android i iOS - inne narzędzia, inne ryzyka
Android
Prostsza analiza wsteczna, więc więcej uwagi poświęcamy zaszytym w kodzie danym i mechanizmom ochrony przed modyfikacją. Testujemy komponenty między aplikacyjne (Activity, Service, Broadcast Receiver, Content Provider), uprawnienia plików w pamięci wewnętrznej oraz obsługę intencji z zewnątrz.
iOS
Zamknięte środowisko wymusza pracę na urządzeniach z jailbreakiem, żeby dotrzeć do systemu plików i pamięci procesu. Sprawdzamy implementację Keychain wraz z klasami ochrony danych, konfigurację App Transport Security oraz skuteczność wykrywania jailbreaka.
Jeśli aplikacja istnieje na obu platformach, sugerujemy testy obu. Ten sam błąd potrafi wystąpić tylko po jednej stronie, bo zespoły implementują funkcję niezależnie.
Jeśli aplikacja istnieje na obu platformach, testujemy obie. Ten sam błąd potrafi wystąpić tylko po jednej stronie, bo zespoły implementują funkcję niezależnie.
Warianty pentestów aplikacji mobilnych
Black-box – pracujemy wyłącznie z aplikacją pobraną ze sklepu, bez kodu i dokumentacji. Najbliżej realnego scenariusza ataku, jednak atakujący mają czas, który w projekcie jest ograniczony.
Grey-box – najczęściej wybierany wariant. Dostajemy konta testowe dla różnych ról, dokumentację API i informacje o architekturze. Przy tym samym budżecie schodzimy głębiej w logikę biznesową. W przypadku aplikacji mobilnych prosimy również o przygotowanie wersji testowej z wyłączonymi mechanizmami utrudniającymi analizę, takimi jak certificate pinning, wykrywanie root/jailbreak czy wykrywanie emulatora. Dzięki temu czas przeznaczony na testy możemy wykorzystać na szczegółową analizę bezpieczeństwa i logiki aplikacji, zamiast na obchodzenie zabezpieczeń utrudniających prowadzenie testów.
White-box – z dostępem do kodu źródłowego i konfiguracji. Wychwytuje błędy, które ciężko wykryć z zewnątrz, lub jest to niemożliwe – na przykład w implementacji kryptografii i obsłudze błędów.
Jeżeli zależy Ci na pełnym przeglądzie kodu, sprawdź także audyt kodu źródłowego. W przypadku aplikacji mocno opartej na integracjach warto rozszerzyć zakres o testy bezpieczeństwa API.
Korzyści
Sprawdź co dostajesz po testach penetracyjnych aplikacji mobilnych
Podatności potwierdzone, nie zgłoszone przez skaner
Każde znalezisko ma proof of concept: kroki odtworzenia, zrzuty ekranu, zmodyfikowane żądania. Deweloper nie traci czasu na sprawdzenie, czy błąd w ogóle istnieje.
Wnioski dla całego procesu wytwarzania
Jeśli te same klasy błędów wracają w kolejnych wersjach, problem leży w procesie, a nie w pojedynczym commicie. Wspieramy wdrożenie Secure SDLC i włączenie testów bezpieczeństwa do pipeline'u CI/CD.
Kolejność napraw według ryzyka
Rekomendacje uszeregowane od najbardziej do najmniej istotnych. Wiesz, co musi zdążyć przed najbliższym wydaniem.
Potwierdzenie po poprawkach
Re-testy weryfikują, czy poprawki działają i czy przy okazji nie powstał nowy błąd.
Dokument do przedstawienia na zewnątrz
Ocena według uznanych standardów, którą pokażesz klientowi korporacyjnemu, audytorowi lub ubezpieczycielowi.
Materiał dla Zarządu
Streszczenie bez terminologii technicznej, z opisem możliwych skutków finansowych, reputacyjnych i prawnych.
Masz aplikację, ale nie wiesz, jaki zakres testów ma sens?
Umów BEZPŁATNĄ KONSULTACJĘ
Na rozmowie przejrzymy funkcje Twojej aplikacji, wskażemy obszary o najwyższym ryzyku i podamy realny zakres oraz czas testów. Bez zobowiązań.
Raport z testów penetracyjnych aplikacji mobilnej
Raport pisany jest dla dwóch odbiorców i tak też jest podzielony.
Część dla Zarządu i osób decyzyjnych:
- cel i zakres wykonanych prac,
- zastosowane podejście,
- podsumowanie wyników językiem biznesowym, bez terminologii technicznej,
- ogólna ocena poziomu bezpieczeństwa aplikacji.
Część techniczna, dla każdej podatności:
- tytuł i szczegółowy opis,
- proof of concept: sposób wywołania podatności wraz z dowodami (zrzuty ekranu, zmanipulowane zapytania, listingi poleceń, fragmenty logów),
- opis możliwych skutków wykorzystania,
- poziom ryzyka według CVSS lub OWASP RRM w skali: krytyczny, wysoki, średni, niski, informacyjny,
- odniesienie do publicznych baz podatności,
- rekomendacja naprawcza z opisem sposobu wdrożenia, dopasowana do specyfiki Twojej aplikacji mobilnych.
Raport zawiera też zakres i datę testów, listę zastosowanych metodyk i technik oraz wykorzystane narzędzia.
Dlaczego warto powierzyć nam testy penetracyjne aplikacji mobilnych?
Testy manualne jako podstawa. Skaner wskaże brak obfuskacji albo przestarzałą bibliotekę. Nie znajdzie sposobu na zmianę ceny w koszyku ani na wejście na konto innego użytkownika. Automat stosujemy pomocniczo i przy cyklicznych przeglądach.
Skala i doświadczenie. Ponad 500 testów penetracyjnych rocznie, zespół powyżej 20 inżynierów bezpieczeństwa z certyfikatami OSCP, OSCE, OSWE, OSEE, CEH, CISSP, CISA i eMAPT.
Jakość i niezależny przegląd. Dostajesz raport, a nie wynika pracy narzędzi. Raport jest wynikiem pracy przynajmniej dwóch niezależnych pentesterów lub zespołów – jeden wykonuje prace, drugi niezależnie weryfikuje ich wyniki i raport.
Metodyka na uznanych standardach. OWASP Mobile Top 10, OWASP MASVS, OWASP MASTG, OWASP WSTG, PTES, ISSAF, PTF, NIST SP 800-115, metodyka LPT EC-Council, P-PEN WAT. Ryzyko szacujemy według CVSS, OWASP RRM i WASC Threat Classification.
Dwie osoby kontaktowe. Pentester Wiodący odpowiada na pytania techniczne w trakcie testów, Project Manager pilnuje terminów i ustaleń.
Ochrona materiałów z testów. Zgodnie z ISO 27001: szyfrowanie dysków, szyfrowanie plików i załączników PGP, kontrola i monitorowanie dostępu do danych oraz raportów.
Wyjście poza jednorazowy test. Opracowujemy, optymalizujemy i wdrażamy Secure SDLC oraz włączamy automatyczne testy bezpieczeństwa do pipeline’u CI/CD.
Skontaktuj się z nami
Najczęściej zadawane pytania
Wycena zależy od liczby modułów i ról użytkowników, złożoności logiki biznesowej, wariantu testów, liczby aplikacji i jej zabezpieczeń oraz tego, czy zakres obejmuje API i infrastrukturę. Podajemy ją po wstępnej rozmowie, zawsze jako konkretną pracochłonność, a nie gotowy pakiet.
Pentesty aplikacji mobilnych trwają od 1 do 4 tygodni, zależnie od złożoności aplikacji mobilnej. Termin i pracochłonność ustalamy przed startem.
Aplikacji mobilnych, kont testowych dla każdej roli oraz zgody na testy. Przy wariancie grey-box lub white-box dodatkowo dokumentacji, opisu architektury i dostępu do kodu.
Preferujemy środowisko testowe odwzorowujące produkcję. Jeżeli test musi objąć produkcję, ustalamy okno czasowe i zakres dopuszczalnych operacji, a w trakcie prac utrzymujemy stały kontakt z Twoim zespołem.
Zależnie od uzgodnionego zakresu. Rekomendujemy objęcie API testami, bo API to zwykle backend aplikacji mobilnej realizujący kluczowe funkcje bezpieczeństwa.
Skaner wskazuje, że coś wygląda podejrzanie, i robi to w godziny. Test penetracyjny potwierdza, że da się to wykorzystać, pokazuje skutek i trwa tygodnie. Skan jest dobry jako cykliczny przegląd między pełnymi testami, nie jako ich zamiennik.
Tak. Zakres uwzględnia aktualne edycję.
M.in. Burp Suite Pro, Frida, MobSF, Objection, Apktool, jadx, hopper, mitmproxy, sqlmap, ffuf, OWASP ZAP, DirBuster, testssl. Uzupełniamy je autorskimi narzędziami pisanymi pod konkretne przypadki.
Tak. Wspieramy zespół przy naprawie, prowadzimy szkolenia z usuwania podatności i wykonujemy re-testy potwierdzające skuteczność poprawek.
Tak. Wdrażamy automatyczne testy bezpieczeństwa w pipeline CI/CD oraz opracowujemy i optymalizujemy Secure SDLC.
Zwykle co 3 do 24 miesięcy, zależnie od wrażliwości danych, poziomu ryzyka i tempa zmian. Przy szybkim cyklu wydawniczym sprawdza się model: pełny test raz w roku plus węższe testy po większych wydaniach. Pomagamy zbudować plan ciągłego monitorowania bezpieczeństwa.
Tak, przy współpracy długoterminowej warunki są korzystniejsze niż przy pojedynczym projekcie.
Zgodnie z ISO 27001: kontrola dostępu do serwerowni i zasobów sieciowych, szyfrowanie dysków, szyfrowanie plików i załączników PGP, szyfrowanie treści wiadomości, ciągłe monitorowanie dostępu.