Bezpieczeństwo aplikacji

Na tej stronie opisujemy różne aspekty bezpieczeństwa aplikacji.

Elementy aplikacji

Android to platforma open source i środowisko aplikacji na urządzenia mobilne. Podstawowy system operacyjny jest oparty na jądrze Linuksa. Aplikacje na Androida są najczęściej pisane w języku programowania Java i działają w maszynie wirtualnej środowiska wykonawczego Androida (ART). Aplikacje można jednak pisać też w kodzie natywnym. Aplikacje są instalowane z jednego pliku z rozszerzeniem APK.

Główne elementy składowe aplikacji na Androida:

• AndroidManifest.xml: plik AndroidManifest.xml to plik sterujący, który informuje system, co ma zrobić z wszystkimi komponentami najwyższego poziomu (w szczególności z działaniami, usługami, odbiornikami transmisji i dostawcami treści opisanymi poniżej) w aplikacji. Określa też, jakie uprawnienia są wymagane.

• Działania: działanie to ogólnie kod pojedynczego zadania, które ma być wykonane przez użytkownika, przy użyciu klasy Activity. Działanie zwykle obejmuje wyświetlanie interfejsu użytkownika, ale nie musi tak być. Niektóre działania nigdy nie wyświetlają interfejsu. Zazwyczaj jednym z działań aplikacji jest punkt wejścia do aplikacji.

• Usługi: usługa to część kodu, która działa w tle i jest oparta na klasie Service. Może działać w osobnym procesie lub w kontekście procesu innej aplikacji. Inne komponenty wiążą się z usługą i wywołują jej metody za pomocą zdalnych wywołań procedur. Przykładem usługi jest odtwarzacz multimediów: nawet gdy użytkownik zamknie interfejs wyboru multimediów, prawdopodobnie nadal będzie chciał słuchać muzyki. Usługa odtwarza muzykę nawet po zakończeniu działania interfejsu.

• Odbiornik transmisji: odbiornik transmisji to obiekt klasy BroadcastReceiver. Jest on tworzony, gdy system operacyjny lub inna aplikacja wyśle intencję, czyli mechanizm IPC, który jest instancją klasy Intent. Aplikacja może na przykład zarejestrować odbiornik wiadomości o niskim poziomie naładowania baterii i zmienić swoje działanie na podstawie tych informacji.

Model uprawnień Androida: dostęp do chronionych interfejsów API

Wszystkie aplikacje na Androida działają w piaskownicy aplikacji. Domyślnie aplikacja na Androida może uzyskać dostęp tylko do ograniczonego zakresu zasobów systemowych. System zarządza dostępem aplikacji na Androida do zasobów, które w przypadku nieprawidłowego lub złośliwego użycia mogą negatywnie wpłynąć na wygodę użytkownika, sieć lub dane na urządzeniu.

Ograniczenia te są wdrażane w różny sposób. Niektóre funkcje są ograniczone przez celowy brak interfejsów API do funkcji wrażliwych (na przykład nie ma interfejsu API Androida do bezpośredniego manipulowania kartą SIM ). W niektórych przypadkach miarą bezpieczeństwa jest rozdzielenie ról, np. w przypadku izolacji pamięci masowej na poziomie aplikacji. W innych przypadkach wrażliwe interfejsy API są przeznaczone do użytku przez zaufane aplikacje i chronione za pomocą mechanizmu zabezpieczeń znanego jako uprawnienia.

Te chronione interfejsy API obejmują:

• funkcje aparatu,
• dane o lokalizacji (GPS),
• funkcje Bluetootha,
• funkcje telefoniczne,
• funkcje SMS/MMS,
• połączenia sieciowe/dane.

Te zasoby są dostępne tylko za pośrednictwem systemu operacyjnego. Aby korzystać z chronionych interfejsów API na urządzeniu, aplikacja musi zdefiniować w manifeście potrzebne jej funkcje. Wszystkie wersje Androida 6.0 i nowsze korzystają z modelu uprawnień w czasie działania. Jeśli użytkownik poprosi o funkcję aplikacji, która wymaga chronionego interfejsu API, system wyświetli okno z prośbą o odmowę lub zezwolenie na przyznanie uprawnień.

Po przyznaniu uprawnienia są stosowane do aplikacji tak długo, jak jest ona zainstalowana. Aby uniknąć dezorientacji użytkownika, system nie powiadamia go ponownie o uprawnieniach przyznanych aplikacji. Aplikacje, które są częścią podstawowego systemu operacyjnego lub są dołączone przez producenta OEM, nie proszą użytkownika o uprawnienia. Uprawnienia są usuwane po odinstalowaniu aplikacji, więc ponowna instalacja powoduje ponowne wyświetlenie uprawnień.

W ustawieniach urządzenia użytkownicy mogą wyświetlać uprawnienia aplikacji, które zostały wcześniej zainstalowane. Użytkownicy mogą też wyłączyć niektóre funkcje globalnie, np. GPS, radio lub Wi-Fi.

Jeśli aplikacja spróbuje użyć chronionej funkcji, która nie została zadeklarowana w jej manifeście, zwykle spowoduje to zgłoszenie do aplikacji wyjątku związanego z bezpieczeństwem. Sprawdzanie uprawnień chronionych interfejsów API jest wymuszane na najniższym możliwym poziomie, aby uniemożliwić obejście zabezpieczeń. Na rysunku 2 pokazano przykład wiadomości wyświetlanej użytkownikowi podczas instalowania aplikacji, która prosi o dostęp do chronionych interfejsów API.

Domyślne uprawnienia systemowe są opisane w sekcji Manifest.permission. Aplikacje mogą deklarować własne uprawnienia, z których mogą korzystać inne aplikacje. Takie uprawnienia nie są wymienione w powyższej lokalizacji.

Podczas definiowania uprawnienia atrybut protectionLevel informuje system, jak należy powiadomić użytkownika o aplikacjach wymagających uprawnień lub kto może mieć uprawnienia. Szczegółowe informacje o tworzeniu i używaniu uprawnień specyficznych dla aplikacji znajdziesz w sekcji Lista kontrolna bezpieczeństwa.

Niektóre funkcje urządzenia, takie jak możliwość wysyłania intencji transmisji SMS, nie są dostępne dla aplikacji innych firm, ale mogą być używane przez aplikacje preinstalowane przez producenta OEM. Te uprawnienia używają uprawnienia signatureOrSystem.

Jak użytkownicy rozumieją aplikacje innych firm

Android stara się informować użytkowników, kiedy wchodzą w interakcje z aplikacjami innych firm, i informować ich o możliwościach tych aplikacji. Przed zainstalowaniem aplikacji użytkownik widzi wyraźny komunikat o różnych uprawnieniach, o które prosi aplikacja. Po zainstalowaniu użytkownik nie jest ponownie proszony o potwierdzenie żadnych uprawnień.

Istnieje wiele powodów, dla których warto wyświetlać uprawnienia bezpośrednio przed instalacją. W tym momencie użytkownik aktywnie sprawdza informacje o aplikacji, deweloperze i funkcjach, aby określić, czy spełnia ona jego potrzeby i oczekiwania. Ważne jest też, aby użytkownik nie był jeszcze psychicznie ani finansowo związany z aplikacją i mógł łatwo porównać ją z innymi aplikacjami.

Niektóre platformy stosują inne podejście do powiadamiania użytkowników, prosząc o uprawnienia na początku każdej sesji lub podczas korzystania z aplikacji. Android ma na celu umożliwienie użytkownikom płynnego przełączania się między aplikacjami. Potwierdzanie za każdym razem spowolniłoby użytkownika i uniemożliwiło Androidowi zapewnienie doskonałej wygody. Sprawdzenie uprawnień przez użytkownika podczas instalacji daje mu możliwość nieinstalowania aplikacji, jeśli nie czuje się z tym komfortowo.

Wiele badań interfejsu użytkownika wykazało też, że nadmierne wyświetlanie okien z prośbą o zgodę powoduje, że użytkownik zaczyna klikać OK w każdym wyświetlanym oknie. Jednym z celów bezpieczeństwa Androida jest skuteczne przekazywanie użytkownikowi ważnych informacji o bezpieczeństwie , co nie jest możliwe w przypadku okien, które użytkownik nauczył się ignorować. Wyświetlając ważne informacje tylko raz i tylko wtedy, gdy jest to ważne, użytkownik ma większe szanse na zastanowienie się nad tym, na co się zgadza.

Niektóre platformy nie wyświetlają żadnych informacji o funkcjach aplikacji. Takie podejście uniemożliwia użytkownikom łatwe zrozumienie i omówienie możliwości aplikacji. Chociaż nie jest możliwe, aby wszyscy użytkownicy zawsze podejmowali w pełni świadome decyzje, model uprawnień Androida sprawia, że informacje o aplikacjach są łatwo dostępne dla szerokiego grona użytkowników. Na przykład nieoczekiwane prośby o uprawnienia mogą skłonić bardziej zaawansowanych użytkowników do zadawania krytycznych pytań dotyczących funkcji aplikacji i dzielenia się swoimi obawami w miejscach takich jak Google Play, gdzie są one widoczne dla wszystkich użytkowników.

Uprawnienia podczas instalacji aplikacji – Tłumacz Google	Uprawnienia aplikacji instalowanej – Gmail

Rysunek 1. Wyświetlanie uprawnień aplikacji.

Komunikacja między procesami

Procesy mogą komunikować się za pomocą dowolnego z tradycyjnych mechanizmów typu Unix. Mogą to być np. system plików, lokalne gniazda lub sygnały. Nadal jednak obowiązują uprawnienia Linuksa.

Android udostępnia też nowe mechanizmy IPC:

• Binder: lekki mechanizm zdalnego wywoływania procedur oparty na możliwościach, zaprojektowany z myślą o wysokiej wydajności podczas wykonywania wywołań w procesie i między procesami. Binder jest implementowany za pomocą niestandardowego sterownika Linuksa. Opis klasy znajdziesz w sekcji Binder.

• Usługi: usługi mogą udostępniać interfejsy bezpośrednio dostępne za pomocą bindera. Szczegółowy opis znajdziesz w sekcji Elementy aplikacji.

• Intencje: intencja to prosty obiekt wiadomości, który reprezentuje zamiar wykonania jakiejś czynności. Jeśli na przykład Twoja aplikacja chce wyświetlić stronę internetową, wyraża zamiar wyświetlenia adresu URL, tworząc instancję intencji i przekazując ją do systemu. System znajduje inny fragment kodu (w tym przypadku przeglądarkę), który wie, jak obsługiwać tę intencję, i uruchamia go. Intencje mogą też służyć do rozgłaszania interesujących zdarzeń (np. a powiadomień) w całym systemie. Opis klasy znajdziesz w sekcji Intent.

• Dostawcy treści: dostawca treści to magazyn danych, który zapewnia dostęp do danych na urządzeniu. Klasycznym przykładem jest dostawca treści używany do uzyskiwania dostępu do listy kontaktów użytkownika. Aplikacja może uzyskiwać dostęp do danych które inne aplikacje udostępniły za pomocą dostawcy treści, a także definiować własnego dostawcę treści, aby udostępniać własne dane. Opis klasy znajdziesz w sekcji ContentProvider.

Chociaż można zaimplementować IPC za pomocą innych mechanizmów, takich jak gniazda sieciowe lub pliki z uprawnieniami do zapisu dla wszystkich, są to zalecane platformy IPC Androida. Zachęcamy deweloperów Androida do stosowania sprawdzonych metod zabezpieczania danych użytkowników i unikania wprowadzania luk w zabezpieczeniach.

Interfejsy API wymagające opłat

Interfejs API wymagający opłat to każda funkcja, która może generować koszty dla użytkownika lub sieci. Platforma Android umieściła interfejsy API wymagające opłat na liście chronionych interfejsów API kontrolowanych przez system operacyjny. Użytkownik musi wyraźnie zezwolić aplikacjom innych firm na korzystanie z interfejsów API wymagających opłat. Te interfejsy API obejmują:

• połączenia telefoniczne,
• SMS/MMS,
• sieć/dane,
• rozliczenia w aplikacji,
• dostęp do NFC.

Android 4.2 dodaje dalszą kontrolę nad użyciem SMS-ów. Android wyświetla powiadomienie, jeśli aplikacja próbuje wysłać SMS-a na krótki numer, który korzysta z usług premium, co może spowodować dodatkowe opłaty. Użytkownik może zezwolić aplikacji na wysłanie wiadomości lub zablokować ją.

Dostęp do karty SIM

Aplikacje innych firm nie mają dostępu do karty SIM na niskim poziomie. System operacyjny obsługuje całą komunikację z kartą SIM, w tym dostęp do danych osobowych (kontaktów) w pamięci karty SIM. Aplikacje nie mają też dostępu do poleceń AT, ponieważ są one zarządzane wyłącznie przez warstwę interfejsu radiowego (RIL). RIL nie udostępnia interfejsów API wysokiego poziomu dla tych poleceń.

Dane osobowe

Android umieścił interfejsy API, które zapewniają dostęp do danych użytkownika, w zbiorze chronionych interfejsów API. Podczas normalnego użytkowania urządzenia z Androidem gromadzą też dane użytkownika w aplikacjach innych firm zainstalowanych przez użytkowników. Aplikacje, które chcą udostępniać te informacje, mogą używać sprawdzania uprawnień systemu operacyjnego Android, aby chronić dane przed aplikacjami innych firm.

Rysunek 2. Dostęp do wrażliwych danych użytkownika jest możliwy tylko za pomocą chronionych interfejsów API.

Systemowi dostawcy treści, którzy mogą zawierać dane osobowe lub informacje umożliwiające identyfikację, takie jak kontakty i kalendarz, zostały utworzone z wyraźnie określonymi uprawnieniami. Ta szczegółowość zapewnia użytkownikowi wyraźne wskazanie typów informacji, które mogą być udostępniane aplikacji. Podczas instalacji aplikacja innej firmy może poprosić o uprawnienia dostępu do tych zasobów. Jeśli uprawnienia zostaną przyznane, aplikacja może zostać zainstalowana i mieć dostęp do żądanych danych w dowolnym momencie, gdy jest zainstalowana.

W przypadku wszystkich aplikacji, które zbierają dane osobowe, te dane są domyślnie ograniczone tylko do konkretnej aplikacji. Jeśli aplikacja zdecyduje się udostępnić dane innym aplikacjom za pomocą IPC, aplikacja przyznająca dostęp może zastosować uprawnienia do mechanizmu IPC, które są wymuszane przez system operacyjny.

Urządzenia wejściowe danych wrażliwych

Urządzenia z Androidem często udostępniają urządzenia wejściowe danych wrażliwych, które umożliwiają aplikacjom interakcję z otoczeniem, takie jak aparat, mikrofon czy GPS. Aby aplikacja innej firmy mogła uzyskać dostęp do tych urządzeń, musi najpierw wyraźnie przyznać jej dostęp za pomocą uprawnień systemu operacyjnego Android. Podczas instalacji instalator wyświetla prośbę o przyznanie uprawnień do czujnika według nazwy.

Jeśli aplikacja chce poznać lokalizację użytkownika, wymaga uprawnień dostępu do lokalizacji użytkownika. Podczas instalacji instalator wyświetla prośbę o przyznanie aplikacji dostępu do lokalizacji użytkownika. Jeśli użytkownik nie chce, aby jakakolwiek aplikacja miała dostęp do jego lokalizacji, może w dowolnym momencie uruchomić aplikację Ustawienia, przejść do sekcji Lokalizacja i bezpieczeństwo i odznaczyć opcje Używaj sieci bezprzewodowych i Włącz satelity GPS. Spowoduje to wyłączenie usług lokalizacyjnych dla wszystkich aplikacji na urządzeniu użytkownika.

Metadane urządzenia

Android stara się też ograniczać dostęp do danych, które nie są z natury wrażliwe, ale mogą pośrednio ujawniać cechy użytkownika, jego preferencje i sposób korzystania z urządzenia.

Domyślnie aplikacje nie mają dostępu do logów systemu operacyjnego, historii przeglądarki, numeru telefonu ani informacji o identyfikacji sprzętu lub sieci informacji. Jeśli aplikacja poprosi o dostęp do tych informacji podczas instalacji, instalator wyświetli prośbę o przyznanie aplikacji dostępu do tych informacji. Jeśli użytkownik nie przyzna dostępu, aplikacja nie zostanie zainstalowana.

Urzędy certyfikacji

Android zawiera zestaw zainstalowanych systemowych urzędów certyfikacji, które są zaufane w całym systemie. Przed Androidem 7.0 producenci urządzeń mogli modyfikować zestaw urzędów certyfikacji dostarczanych na urządzeniach. Urządzenia z Androidem 7.0 i nowszymi wersjami mają jednak jednolity zestaw systemowych urzędów certyfikacji, ponieważ producenci urządzeń nie mogą już ich modyfikować.

Aby dodać nowy publiczny urząd certyfikacji do domyślnego zestawu Androida, musi on przejść proces włączania urzędu certyfikacji Mozilli, a następnie przesłać prośbę o dodanie funkcji do Androida ( https://code.google.com/p/android/issues/entry), aby dodać urząd certyfikacji do domyślnego zestawu urzędów certyfikacji Androida w projekcie Projekt Android Open Source (AOSP).

Nadal istnieją urzędy certyfikacji, które są specyficzne dla urządzenia i nie powinny być uwzględniane w podstawowym zestawie urzędów certyfikacji AOSP, np. prywatne urzędy certyfikacji operatorów, które mogą być potrzebne do bezpiecznego uzyskiwania dostępu do komponentów infrastruktury operatora, takich jak bramy SMS/MMS. Zachęcamy producentów urządzeń do uwzględniania prywatnych urzędów certyfikacji tylko w komponentach i aplikacjach, które muszą ufać tym urzędom. Więcej informacji znajdziesz w sekcji Konfiguracja zabezpieczeń sieci.

Podpisywanie aplikacji

Podpisywanie kodu umożliwia deweloperom identyfikowanie autora aplikacji i aktualizowanie aplikacji bez tworzenia skomplikowanych interfejsów i uprawnień. Każda aplikacja uruchamiana na platformie Android musi być podpisana przez dewelopera. Aplikacje, które próbują się zainstalować bez podpisu, są odrzucane przez Google Play lub instalator pakietów na urządzeniu z Androidem.

W Google Play podpisywanie aplikacji buduje zaufanie między Google a deweloperem a zaufanie dewelopera do jego aplikacji. Deweloperzy wiedzą, że ich aplikacja jest dostarczana na urządzenie z Androidem bez zmian, a deweloperzy mogą ponosić odpowiedzialność za zachowanie aplikacji.

Na Androidzie podpisywanie aplikacji to pierwszy krok do umieszczenia aplikacji w piaskownicy aplikacji. Podpisany certyfikat aplikacji określa, który identyfikator użytkownika jest powiązany z którą aplikacją. Różne aplikacje działają pod różnymi identyfikatorami użytkowników. Podpisywanie aplikacji zapewnia, że jedna aplikacja nie może uzyskać dostępu do innej aplikacji, z wyjątkiem dobrze zdefiniowanego IPC.

Gdy aplikacja (plik APK) jest instalowana na urządzeniu z Androidem, Menedżer pakietów sprawdza, czy plik APK został prawidłowo podpisany certyfikatem dołączonym do tego pliku APK. Jeśli certyfikat (a dokładniej klucz publiczny w certyfikacie) pasuje do klucza użytego do podpisania innego pliku APK na urządzeniu, nowy plik APK może określić w manifeście, że udostępnia UID innym podobnie podpisanym plikom APK.

Aplikacje mogą być podpisane przez osobę trzecią (producenta OEM, operatora, alternatywny rynek) lub samodzielnie. Android umożliwia podpisywanie kodu za pomocą certyfikatów z podpisem własnym , które deweloperzy mogą generować bez pomocy zewnętrznej ani uprawnień. Aplikacje nie muszą być podpisane przez centralny urząd. Android obecnie nie przeprowadza weryfikacji urzędu certyfikacji w przypadku certyfikatów aplikacji.

Aplikacje mogą też deklarować uprawnienia zabezpieczeń na poziomie ochrony podpisu , ograniczając dostęp tylko do aplikacji podpisanych tym samym kluczem, przy zachowaniu odrębnych identyfikatorów UID i piaskownic aplikacji. Ściślejsze powiązanie ze wspólną piaskownicą aplikacji jest możliwe dzięki funkcji udostępnionego identyfikatora UID, w której 2 lub więcej aplikacji podpisanych tym samym kluczem dewelopera może zadeklarować udostępniony identyfikator UID w swoim manifeście.

Weryfikacja aplikacji

Android 4.2 i nowsze wersje obsługują weryfikację aplikacji. Użytkownicy mogą włączyć opcję Weryfikacja aplikacji i poprosić o sprawdzenie aplikacji przez weryfikator aplikacji przed instalacją. Weryfikacja aplikacji może ostrzec użytkownika, jeśli spróbuje zainstalować aplikację, która może być szkodliwa. Jeśli aplikacja jest szczególnie szkodliwa, może zablokować jej instalację.

Zarządzanie prawami cyfrowymi

Platforma Android udostępnia rozszerzalną platformę zarządzania prawami cyfrowymi (DRM), która umożliwia aplikacjom zarządzanie treściami chronionymi prawami zgodnie z ograniczeniami licencji powiązanymi z treściami. Platforma DRM obsługuje wiele schematów DRM. To, które schematy DRM są obsługiwane przez urządzenie, zależy od producenta urządzenia.

Platforma DRM Androida jest implementowana w 2 warstwach architektury (patrz rysunek 3):

• Interfejs API platformy DRM, który jest udostępniany aplikacjom za pomocą platformy aplikacji na Androida i działa w maszynie wirtualnej ART w przypadku standardowych aplikacji.

• Menedżer DRM w kodzie natywnym, który implementuje platformę DRM i udostępnia interfejs wtyczek DRM (agentów) do obsługi zarządzania prawami i odszyfrowywania w przypadku różnych schematów DRM.

Rysunek 3. Architektura DRM na platformie Android.