Ta sekcja zawiera rekomendacje dotyczące zapewnienia bezpieczeństwa aplikacji na urządzeniach z Androidem.
Weryfikacja kodu źródłowego
Sprawdzanie kodu źródłowego może wykryć szeroki zakres problemów z bezpieczeństwem, w tym te, które zostały opisane w tym dokumencie. Android zdecydowanie zaleca zarówno ręczne, jak i automatyczne sprawdzanie kodu źródłowego.
- Podczas przeprowadzania weryfikacji postępuj zgodnie z wyczerpującymi wytycznymi dotyczącymi bezpieczeństwa, aby zapewnić odpowiedni zakres. Korzystaj z odpowiednich standardów wewnętrznych lub zewnętrznych, aby zapewnić spójne i kompletne przeglądy.
- Uruchom narzędzie do sprawdzania kodu, np. linter Android Studio, na całym kodzie aplikacji korzystającym z pakietu Android SDK i popraw wszystkie wykryte problemy.
- Analizuj kod natywny za pomocą automatycznego narzędzia, które może wykrywać problemy z zarządzaniem pamięcią, takie jak przepełnienie bufora i błędy o jeden.
- System kompilacji Androida obsługuje wiele narzędzi LLVM Sanitizers, takich jak AddressSanitizer i UndefinedBehaviorSanitizer, które można wykorzystać do analizy w czasie działania problemów związanych z pamięcią. W połączeniu z testowaniem fuzzingowym, obsługiwanym w Androidzie przez libFuzzer, narzędzia do sprawdzania poprawności mogą wykrywać nietypowe przypadki brzegowe wymagające dalszej analizy.
- Kod o wyższym ryzyku, taki jak kod związany z kryptografią, przetwarzaniem płatności i przetwarzaniem informacji umożliwiających identyfikację, powinien zostać sprawdzony przez doświadczonego specjalistę ds. bezpieczeństwa.
Automatyczne testowanie
Automatyczne testy mogą pomóc w wykryciu wielu problemów z bezpieczeństwem i powinny być przeprowadzane regularnie.
- Regularnie uruchamiaj najnowszą wersję CTS w trakcie procesu tworzenia, aby wcześnie wykrywać problemy i skracać czas potrzebny na ich rozwiązanie. Android używa CTS w ramach ciągłej integracji w naszym zautomatyzowanym procesie kompilacji, który jest przeprowadzany kilka razy dziennie.
- Zautomatyzuj testowanie interfejsów pod kątem bezpieczeństwa, w tym testowanie za pomocą nieprawidłowych danych wejściowych (testowanie fuzzing). System kompilacji Androida obsługuje libFuzzer, który umożliwia pisanie testów fuzzingowych.
Skanowanie pod kątem luk w zabezpieczeniach
Skanowanie pod kątem luk w zabezpieczeniach może pomóc w zapewnieniu, że preinstalowane aplikacje nie zawierają znanych luk w zabezpieczeniach. Zaawansowane wykrywanie może skrócić czas i zmniejszyć koszty związane z usuwaniem tych luk w zabezpieczeniach oraz zapobiegać zagrożeniom dla użytkowników i urządzeń.
- Przeskanuj wszystkie wstępnie zainstalowane aplikacje za pomocą narzędzia do skanowania luk w zabezpieczeniach aplikacji, które jest uznawane w branży, i usuń wykryte luki.
Potencjalnie szkodliwe aplikacje
Ważne jest, aby aplikacje fabrycznie zainstalowane na urządzeniu nie były potencjalnie szkodliwymi aplikacjami (PHA). Odpowiadasz za działanie wszystkich aplikacji zainstalowanych na Twoich urządzeniach. Przed wprowadzeniem urządzenia na rynek przeskanuj wszystkie wstępnie załadowane aplikacje pod kątem luk w zabezpieczeniach.
Więcej informacji o potencjalnie szkodliwych aplikacjach i o tym, jak Google z nimi walczy w Sklepie Play, znajdziesz w dokumentacji dla deweloperów dotyczącej Google Play Protect.
Instalowanie aplikacji i uprawnienia
Nadmierne uprawnienia w przypadku preinstalowanych aplikacji mogą stwarzać zagrożenie dla bezpieczeństwa. Ograniczanie wstępnie zainstalowanych aplikacji do minimalnych niezbędnych uprawnień i zapewnianie, że nie mają one dostępu do niepotrzebnych uprawnień ani przywilejów. Uprawnienia aplikacji są opisane w pliku AndroidManifest.xml.
- Nie przyznawaj niepotrzebnych uprawnień ani przywilejów preinstalowanym aplikacjom. Dokładnie sprawdzaj aplikacje z uprawnieniami systemowymi, ponieważ mogą one mieć bardzo wrażliwe uprawnienia.
- Sprawdź, czy wszystkie wymagane uprawnienia są istotne i niezbędne do działania danej aplikacji.
- Upewnij się, że w przypadku wszystkich preinstalowanych aplikacji, które korzystają z uprawnienia
INSTALL_PACKAGES, użytkownik jest o tym informowany. - Upewnij się, że deweloper jest zobowiązany umową do nieinstalowania żadnych aplikacji jako UID 0.
- Oceniać uprawnienia zadeklarowane w pliku manifestu wszystkich aplikacji, które mają być instalowane w sieci dewelopera.
- Upewnij się, że deweloper jest zobowiązany umową do skanowania wszystkich adresów URL pobierania aplikacji do automatycznej aktualizacji i instalacji za pomocą interfejsu Google Safe Browsing API przed udostępnieniem aplikacji na urządzeniu.
Podpisywanie aplikacji
Podpisy aplikacji odgrywają ważną rolę w bezpieczeństwie urządzenia i są używane do sprawdzania uprawnień oraz aktualizacji oprogramowania. Wybierając klucz do podpisywania aplikacji, warto zastanowić się, czy aplikacja jest dostępna tylko na jednym urządzeniu, czy na wielu.
- Upewnij się, że aplikacje nie są podpisane kluczem, który jest publicznie znany, np. kluczem dewelopera AOSP.
- Zadbaj o to, aby klucze używane do podpisywania aplikacji były zarządzane w sposób zgodny ze standardowymi w branży praktykami dotyczącymi obsługi kluczy poufnych, w tym za pomocą sprzętowego modułu zabezpieczeń (HSM), który zapewnia ograniczony dostęp podlegający audytowi.
- Upewnij się, że aplikacje nie są podpisane kluczem platformy. W ten sposób aplikacja uzyskuje dostęp do uprawnień związanych z podpisem platformy, które są bardzo zaawansowane i przeznaczone wyłącznie do użytku przez komponenty systemu operacyjnego. Aplikacje systemowe powinny używać uprawnień uprzywilejowanych.
- Upewnij się, że aplikacje o tej samej nazwie pakietu nie są podpisywane różnymi kluczami. Często zdarza się to podczas tworzenia aplikacji na różne urządzenia, zwłaszcza gdy używasz klucza platformy. Jeśli aplikacja jest niezależna od urządzenia, używaj tego samego klucza na wszystkich urządzeniach. Jeśli aplikacja jest przeznaczona na konkretne urządzenie, utwórz unikalne nazwy pakietów dla każdego urządzenia i klucza.
Izolowanie aplikacji i procesów
Model piaskownicy Androida zapewnia dodatkowe bezpieczeństwo aplikacji i procesów, jeśli jest prawidłowo używany.
Izolowanie procesów głównych
Procesy główne są najczęstszym celem ataków polegających na podniesieniu uprawnień. Zmniejszenie liczby procesów głównych ogranicza ryzyko podniesienia uprawnień.
- Upewnij się, że urządzenia uruchamiają minimalny wymagany kod jako root. W miarę możliwości używaj zwykłego procesu Androida zamiast procesu z uprawnieniami roota. Jeśli proces musi być uruchamiany na urządzeniu jako root, udokumentuj go w prośbie o funkcję w AOSP, aby można było go publicznie sprawdzić.
- W miarę możliwości kod roota powinien być odizolowany od niezaufanych danych i dostępny za pomocą komunikacji międzyprocesowej (IPC). Na przykład ogranicz funkcje roota do małej usługi dostępnej za pomocą Binder i udostępnij tę usługę z uprawnieniami podpisu aplikacji o niskich lub zerowych uprawnieniach do obsługi ruchu sieciowego.
- Procesy główne nie mogą nasłuchiwać na gnieździe sieciowym.
- Procesy główne nie mogą zawierać środowiska wykonawczego ogólnego przeznaczenia, takiego jak maszyna wirtualna Java.
Izolowanie aplikacji systemowych
Ogólnie rzecz biorąc, preinstalowane aplikacje nie powinny działać ze współdzielonym unikalnym identyfikatorem systemu (UID). Jeśli aplikacja musi używać wspólnego identyfikatora UID systemu lub innej usługi uprzywilejowanej (np. telefonu), nie powinna eksportować żadnych usług, odbiorników transmisji ani dostawców treści, do których dostęp mogą mieć aplikacje innych firm zainstalowane przez użytkowników.
- Upewnij się, że urządzenia działają z minimalnym wymaganym kodem jako system. W miarę możliwości używaj procesu Androida z własnym identyfikatorem UID zamiast ponownie używać identyfikatora UID systemu.
- W miarę możliwości kod systemu powinien być odseparowany od niezaufanych danych i udostępniać komunikację międzyprocesową tylko innym zaufanym procesom.
- Procesy systemowe nie mogą nasłuchiwać na gnieździe sieciowym. Jest to wymaganie CTS.
Izolowanie procesów
Piaskownica aplikacji na Androida zapewnia aplikacjom izolację od innych procesów w systemie, w tym procesów głównych i debuggerów. Żadna aplikacja nie powinna naruszać tego oczekiwania, chyba że debugowanie zostało włączone przez aplikację i użytkownika.
- Dopilnuj, aby procesy główne nie miały dostępu do danych w folderach poszczególnych aplikacji, chyba że korzystasz z udokumentowanej metody debugowania Androida.
- Upewnij się, że procesy główne nie mają dostępu do pamięci aplikacji, chyba że używają udokumentowanej metody debugowania Androida.
- Upewnij się, że urządzenia nie zawierają żadnych aplikacji, które mają dostęp do danych lub pamięci innych aplikacji lub procesów.