Rozkładamy APK na części, uruchamiamy aplikację na urządzeniu z pełnymi uprawnieniami i sprawdzamy, co mogą z nią zrobić inne aplikacje na telefonie, podsłuch w sieci i sam użytkownik.
Dekompilacja kodu i zasobów, AndroidManifest, biblioteki natywne. Szukamy kluczy API, adresów środowisk testowych, ukrytych ekranów i flag takich jak debuggable czy allowBackup.
Wyeksportowane aktywności, serwisy, odbiorniki i dostawcy treści dostępni dla innych aplikacji na telefonie. Sprawdzamy, czy da się przez nie wywołać akcję albo odczytać dane bez uprawnień.
Czy link z maila lub strony wykona akcję bez potwierdzenia, przekaże złośliwe parametry albo zostanie przechwycony przez inną aplikację podszywającą się pod Waszą.
Ładowanie obcych treści, mostki JavaScript (addJavascriptInterface), dostęp do plików lokalnych. Błąd w WebView daje napastnikowi uprawnienia samej aplikacji.
SharedPreferences, bazy SQLite, pamięć zewnętrzna, logi i kopie zapasowe. Sprawdzamy, czy sekrety trafiają do Android Keystore i co zostaje po wylogowaniu.
Konfiguracja Network Security Config, ruch nieszyfrowany, zaufanie do certyfikatów użytkownika, przypinanie certyfikatów. Potem API, bo tam zwykle jest najpoważniejsze ryzyko.
Na Androidzie aplikacja nie jest zamkniętym pudełkiem. Rozmawia z innymi aplikacjami przez intenty, udostępnia im swoje komponenty, otwiera linki z dowolnego źródła i często wyświetla strony w WebView. Każdy z tych kanałów to droga, którą coś z zewnątrz może dostać się do środka.
Najczęstszy błąd specyficzny dla platformy to wyeksportowany komponent bez kontroli. Aktywność albo dostawca treści dostępny dla każdej aplikacji na telefonie, który pokazuje dane albo wykonuje akcję bez sprawdzenia, kto o to prosi. Złośliwa aplikacja zainstalowana obok nie potrzebuje wtedy żadnych uprawnień.
Druga grupa to dane zostawione na urządzeniu. Tokeny w SharedPreferences zamiast w Keystore, pliki na pamięci współdzielonej, logi z odpowiedziami serwera i kopie zapasowe, z których da się wyciągnąć dane aplikacji. Telefon z Androidem łatwo zrootować, więc wszystko, co nie jest szyfrowane kluczem ze sprzętowego magazynu, trzeba traktować jak jawne.
Jak w każdym teście mobilnym, najpoważniejsze znaleziska zwykle siedzą w backendzie. Dlatego zalecamy, żeby API było w zakresie. Szerzej o całym procesie piszemy we wpisie co sprawdzamy w teście aplikacji mobilnej.
Definiujemy, co testujemy, w jakim trybie i w jakich godzinach. Doprecyzowujemy, co jest poza zakresem.
Pełna poufność na każdym etapie. Znalezione podatności zostają między nami.
Testy manualne wsparte narzędziami. Krytyczne znaleziska zgłaszamy od razu, nie czekamy z nimi do raportu.
Raport z oceną ryzyka, krokami reprodukcji i rekomendacjami. Po wdrożeniu poprawek sprawdzamy je ponownie.
Napisz, czy aplikacja jest już w Google Play i czy mamy sprawdzić także backend - odezwiemy się w 24 h z wyceną.
Zapytaj o wycenę