Ta sekcja zawiera rekomendacje dotyczące zapewnienia bezpieczeństwa aplikacji na urządzeniach z Androidem.
Weryfikacja kodu źródłowego
Inspekcja 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ęczną, jak i automatyczną inspekcję kodu źródłowego.
- Podczas sprawdzania przestrzegaj kompleksowych wytycznych dotyczących bezpieczeństwa, aby zapewnić ochronę. Korzystaj z odpowiednich standardów wewnętrznych lub zewnętrznych, aby zapewnić spójne i kompletne weryfikacje.
- Uruchom narzędzie do sprawdzania kodu, np. linter Androida 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 kryptograficzny, kod przetwarzania płatności i kod przetwarzania 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 zabezpieczeniami i powinny być przeprowadzane regularnie.
- Regularnie uruchamiaj najnowszą wersję CTS w trakcie procesu programowania, aby wcześnie wykrywać problemy i skracać czas potrzebny na ich rozwiązanie. Android używa CTS w ramach trybu ciągłej integracji w naszym zautomatyzowanym procesie kompilacji, który jest przeprowadzany kilka razy dziennie.
- Automatyzacja testowania interfejsów pod kątem bezpieczeństwa, w tym testowanie za pomocą nieprawidłowych danych wejściowych (testowanie fuzzingowe). System kompilacji Androida obsługuje libFuzzer do pisania 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ą uznanego w branży narzędzia do skanowania luk w zabezpieczeniach aplikacji 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ą 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ć uprawnienia o charakterze kontrowersyjnym.
- Upewnij się, że wszystkie wymagane uprawnienia są istotne i niezbędne do działania danej aplikacji.
- Upewnij się, że użytkownik jest informowany o wszystkich preinstalowanych aplikacjach, które korzystają z uprawnienia
INSTALL_PACKAGES. - 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ć zainstalowane 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ą podpisywane kluczem, który jest publicznie znany, np. kluczem dewelopera AOSP.
- Zapewnij, 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.
- Sprawdź, czy 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 zabezpieczenia 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 eskalacji uprawnień. Zmniejszenie liczby procesów głównych ogranicza ryzyko eskalacji 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 roota. Jeśli proces musi być uruchamiany na urządzeniu jako root, udokumentuj go w prośbie o dodanie funkcji w AOSP, aby można było go publicznie sprawdzić.
- W miarę możliwości kod główny powinien być odseparowany od niezaufanych danych i dostępny za pomocą komunikacji międzyprocesowej (IPC). Możesz na przykład ograniczyć funkcje roota do małej usługi dostępnej przez Binder i udostępnić tę usługę z uprawnieniami podpisu aplikacji o niskich lub zerowych uprawnieniach do obsługi ruchu w sieci.
- Procesy główne nie mogą nasłuchiwać na gnieździe sieciowym.
- Procesy główne nie mogą zawierać środowiska wykonawczego do zwykłych obciążeń, takiego jak maszyna wirtualna Java.
Izolowanie aplikacji systemowych
Ogólnie rzecz biorąc, fabrycznie zainstalowane aplikacje nie powinny działać ze wspólnym 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 mogą mieć dostęp 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ć IPC tylko innym zaufanym procesom.
- Procesy systemowe nie mogą nasłuchiwać na gnieździe sieciowym. Jest to wymóg CTS.
Izolowanie procesów
Piaskownica aplikacji na Androida zapewnia aplikacjom izolację od innych procesów w systemie, w tym procesów root 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 używają udokumentowanej metody debugowania Androida.
- Upewnij się, że procesy główne nie mają dostępu do pamięci aplikacji, chyba że korzystają z 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.