hacktricks/mobile-pentesting/android-app-pentesting/android-applications-basics.md

# Podstawy Aplikacji na Androida

<details>

<summary><strong>Nauka hakowania AWS od zera do bohatera z</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>

Inne sposoby wsparcia HackTricks:

* Jeśli chcesz zobaczyć swoją **firmę reklamowaną w HackTricks** lub **pobrać HackTricks w formacie PDF**, sprawdź [**PLANY SUBSKRYPCYJNE**](https://github.com/sponsors/carlospolop)!
* Zdobądź [**oficjalne gadżety PEASS & HackTricks**](https://peass.creator-spring.com)
* Odkryj [**Rodzinę PEASS**](https://opensea.io/collection/the-peass-family), naszą kolekcję ekskluzywnych [**NFT**](https://opensea.io/collection/the-peass-family)
* **Dołącz do** 💬 [**grupy Discord**](https://discord.gg/hRep4RUj7f) lub [**grupy telegramowej**](https://t.me/peass) lub **śledź** nas na **Twitterze** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Podziel się swoimi sztuczkami hakerskimi, przesyłając PR-y do** [**HackTricks**](https://github.com/carlospolop/hacktricks) i [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) na GitHubie.

</details>

**Try Hard Security Group**

<figure><img src="/.gitbook/assets/telegram-cloud-document-1-5159108904864449420.jpg" alt=""><figcaption></figcaption></figure>

{% embed url="https://discord.gg/tryhardsecurity" %}

***

## Model Bezpieczeństwa Androida

**Składa się z dwóch warstw:**

* **Systemu operacyjnego (OS)**, który izoluje zainstalowane aplikacje od siebie.
* **Samej aplikacji**, która pozwala deweloperom **udostępniać określone funkcjonalności** i konfigurować zdolności aplikacji.

### Separacja UID

**Każda aplikacja jest przypisana określone ID użytkownika (UID)**. Jest to wykonywane podczas instalacji aplikacji, dzięki czemu **aplikacja może komunikować się tylko z plikami należącymi do swojego UID lub plikami współdzielonymi**. Dlatego tylko sama aplikacja, pewne komponenty systemu operacyjnego i użytkownik root mogą uzyskać dostęp do danych aplikacji.

### Współdzielenie UID

**Dwie aplikacje mogą być skonfigurowane do korzystania z tego samego UID**. Może to być przydatne do udostępniania informacji, ale jeśli jedna z nich zostanie skompromitowana, dane obu aplikacji zostaną naruszone. Dlatego ten sposób postępowania jest **niezalecany**.\
**Aby współdzielić to samo UID, aplikacje muszą zdefiniować tę samą wartość `android:sharedUserId` w swoich manifestach.**

### Izolacja

**Piaskownica Aplikacji Androida** pozwala uruchamiać **każdą aplikację** jako **oddzielny proces pod oddzielnym identyfikatorem użytkownika**. Każdy proces ma swoją własną maszynę wirtualną, więc kod aplikacji działa w izolacji od innych aplikacji.\
Od Androida 5.0(L) jest stosowany **SELinux**. W skrócie, SELinux odrzuca wszystkie interakcje procesów, a następnie tworzy zasady, aby **zezwolić tylko na oczekiwane interakcje między nimi**.

### Uprawnienia

Podczas instalacji **aplikacji i prośby o uprawnienia**, aplikacja prosi o uprawnienia skonfigurowane w elementach **`uses-permission`** w pliku **AndroidManifest.xml**. Element **uses-permission** wskazuje nazwę żądanego uprawnienia w atrybucie **name**. Ma również atrybut **maxSdkVersion**, który przestaje prosić o uprawnienia w wersjach wyższych niż określona.\
Zauważ, że aplikacje na Androida nie muszą prosić o wszystkie uprawnienia na początku, mogą również **prosić o uprawnienia dynamicznie**, ale wszystkie uprawnienia muszą być **zadeklarowane** w **manifeście**.

Gdy aplikacja udostępnia funkcjonalność, może ograniczyć **dostęp tylko do aplikacji posiadających określone uprawnienie**.\
Element uprawnienia ma trzy atrybuty:

* Nazwę uprawnienia
* Atrybut **permission-group**, który pozwala na grupowanie powiązanych uprawnień.
* **Poziom ochrony**, który wskazuje, w jaki sposób uprawnienia są udzielane. Istnieją cztery typy:
* **Normal**: Używane, gdy nie ma **znanych zagrożeń** dla aplikacji. Użytkownik **nie musi go zatwierdzać**.
* **Niebezpieczne**: Wskazuje, że uprawnienie nadaje żądającej aplikacji pewne **podwyższone uprawnienia**. **Użytkownicy są proszeni o ich zatwierdzenie**.
* **Podpis**: Tylko **aplikacje podpisane tym samym certyfikatem co ta**, eksportująca komponent, mogą uzyskać uprawnienie. Jest to najwyższy poziom ochrony.
* **PodpisLubSystem**: Tylko **aplikacje podpisane tym samym certyfikatem co ta**, eksportująca komponent, lub **aplikacje działające z poziomem dostępu systemowego** mogą uzyskać uprawnienia.

## Zainstalowane Wstępnie Aplikacje

Te aplikacje zazwyczaj znajdują się w katalogach **`/system/app`** lub **`/system/priv-app`**, a niektóre z nich są **zoptymalizowane** (możesz nawet nie znaleźć pliku `classes.dex`). Warto sprawdzić te aplikacje, ponieważ czasami działają zbyt wieloma uprawnieniami (jako root).

* Te dostarczone z **AOSP** (Android OpenSource Project) **ROM**
* Dodane przez **producenta urządzenia**
* Dodane przez **dostawcę telefonu komórkowego** (jeśli zakupione od nich)

## Rootowanie

Aby uzyskać dostęp roota do fizycznego urządzenia z systemem Android, zazwyczaj trzeba **wykorzystać** 1 lub 2 **luki**, które zazwyczaj są **specyficzne** dla **urządzenia** i **wersji**.\
Gdy exploit zadziała, zazwyczaj binarny `su` systemu Linux jest kopiowany do lokalizacji określonej w zmiennej środowiskowej PATH użytkownika, np. `/system/xbin`.

Po skonfigurowaniu binarnego su, inna aplikacja na Androida jest używana do interakcji z binarnym `su` i **przetwarzania żądań dostępu roota** jak **Superuser** i **SuperSU** (dostępne w sklepie Google Play).

{% hint style="danger" %}
Zauważ, że proces rootowania jest bardzo niebezpieczny i może poważnie uszkodzić urządzenie
{% endhint %}

### ROM-y

Możliwe jest **zastąpienie systemu operacyjnego instalując niestandardowe oprogramowanie**. Dzięki temu można rozszerzyć użyteczność starego urządzenia, ominąć ograniczenia oprogramowania lub uzyskać dostęp do najnowszego kodu Androida.\
**OmniROM** i **LineageOS** to dwa z najpopularniejszych oprogramowań do użytku.

Zauważ, że **nie zawsze jest konieczne zrootowanie urządzenia** do zainstalowania niestandardowego oprogramowania. **Niektórzy producenci pozwalają** na odblokowanie ich bootloaderów w sposób dobrze udokumentowany i bezpieczny.

### Konsekwencje

Po zrootowaniu urządzenia, dowolna aplikacja może żądać dostępu jako root. Jeśli złośliwa aplikacja go uzyska, będzie miała dostęp do prawie wszystkiego i będzie mogła uszkodzić telefon.

## Podstawy Aplikacji na Androida <a href="#2-android-application-fundamentals" id="2-android-application-fundamentals"></a>

- Format aplikacji na Androida nazywany jest _formatem pliku APK_. Jest to w zasadzie **plik ZIP** (poprzez zmianę rozszerzenia pliku na .zip, zawartość można wyodrębnić i przeglądać).
- Zawartość APK (niepełna)
- **AndroidManifest.xml**
- resources.arsc/strings.xml
- resources.arsc: zawiera skompilowane zasoby, takie jak binarne XML.
- res/xml/files\_paths.xml
- META-INF/
- Tutaj znajduje się Certyfikat!
- **classes.dex**
- Zawiera kod bajtowy Dalvika, reprezentujący skompilowany kod Java (lub Kotlin), który aplikacja wykonuje domyślnie.
- lib/
- Zawiera biblioteki natywne, podzielone według architektury CPU w podkatalogach.
- `armeabi`: kod dla procesorów opartych na ARM
- `armeabi-v7a`: kod dla procesorów opartych na ARMv7 i nowszych
- `x86`: kod dla procesorów X86
- `mips`: kod tylko dla procesorów MIPS
- assets/
- Przechowuje różne pliki potrzebne przez aplikację, potencjalnie zawierające dodatkowe biblioteki natywne lub pliki DEX, czasami używane przez autorów złośliwego oprogramowania do ukrycia dodatkowego kodu.
- res/
- Zawiera zasoby, które nie są skompilowane do resources.arsc
### **Dalvik & Smali**

W rozwoju aplikacji na Androida używa się **Javy lub Kotlin**. Zamiast korzystać z JVM jak w aplikacjach na komputery stacjonarne, Android kompiluje ten kod do **wykonywalnego kodu Dalvika (DEX)**. Wcześniej ten kod obsługiwała maszyna wirtualna Dalvika, ale teraz w nowszych wersjach Androida przejmuje to Android Runtime (ART).

W przypadku inżynierii wstecznej **Smali** staje się kluczowy. Jest to czytelna dla człowieka wersja kodu DEX, działająca jak język asemblera, tłumacząca kod źródłowy na instrukcje bajtowe. Smali i baksmali odnoszą się do narzędzi montażu i demontażu w tym kontekście.

## Intents

Intents są głównym środkiem komunikacji między komponentami aplikacji na Androida lub z innymi aplikacjami. Obiekty tych wiadomości mogą również przekazywać dane między aplikacjami lub komponentami, podobnie jak w przypadku żądań GET/POST w komunikacji HTTP.

Więc Intent to w zasadzie **wiadomość przekazywana między komponentami**. Intents **mogą być kierowane** do konkretnych komponentów lub aplikacji, **lub mogą być wysyłane bez określonego odbiorcy**.\
Aby to uprościć, Intent można użyć:

* Do uruchamiania Activity, zazwyczaj otwierając interfejs użytkownika aplikacji
* Jako transmisje, informujące system i aplikacje o zmianach
* Do uruchamiania, zatrzymywania i komunikowania się z usługą w tle
* Do uzyskiwania dostępu do danych za pośrednictwem dostawców treści
* Jako wywołania zwrotne do obsługi zdarzeń

Jeśli są podatne, **Intents mogą być wykorzystane do przeprowadzenia różnorodnych ataków**.

### Intent-Filter

**Filtry Intents** definiują **jak aktywność, usługa lub odbiornik nadawany może współdziałać z różnymi typami Intents**. W zasadzie opisują one możliwości tych komponentów, takie jak jakie działania mogą wykonywać lub jakie rodzaje transmisji mogą przetwarzać. Głównym miejscem deklaracji tych filtrów jest plik **AndroidManifest.xml**, chociaż dla odbiorników nadawanych istnieje również opcja ich kodowania.

Filtry Intents składają się z kategorii, działań i filtrów danych, z możliwością dodania dodatkowych metadanych. Taka konfiguracja pozwala komponentom obsługiwać konkretne Intents, które spełniają określone kryteria.

Krytycznym aspektem komponentów Androida (aktywności/usług/dostawców treści/odbiorców nadawanych) jest ich widoczność lub **status publiczny**. Komponent jest uważany za publiczny i może współdziałać z innymi aplikacjami, jeśli jest **`eksportowany`** z wartością **`true`** lub jeśli dla niego zadeklarowany jest filtr Intent w manifeście. Jednak deweloperzy mają możliwość jawnego zachowania tych komponentów jako prywatnych, zapewniając, że nie będą one niezamierzenie współdziałać z innymi aplikacjami. Można to osiągnąć, ustawiając atrybut **`eksportowany`** na **`false`** w ich definicjach manifestu.

Co więcej, deweloperzy mają możliwość dodatkowego zabezpieczenia dostępu do tych komponentów, wymagając określonych uprawnień. Atrybut **`permission`** może być ustawiony, aby wymusić, że tylko aplikacje z określonym uprawnieniem mogą uzyskać dostęp do komponentu, dodając dodatkową warstwę bezpieczeństwa i kontroli nad tym, kto może z nim współdziałać.
```java
<activity android:name=".MyActivity" android:exported="false">
<!-- Intent filters go here -->
</activity>
```
### Impliitytne Intencje

Intencje są tworzone programistycznie za pomocą konstruktora Intent:
```java
Intent email = new Intent(Intent.ACTION_SEND, Uri.parse("mailto:"));
```
Akcja **Action** wcześniej zadeklarowanego zamiaru to **ACTION\_SEND**, a **Extra** to mailto **Uri** (Extra to dodatkowe informacje, których oczekuje zamiar).

Ten zamiar powinien być zadeklarowany wewnątrz manifestu, jak w poniższym przykładzie:
```xml
<activity android:name="ShareActivity">
<intent-filter>
<action android:name="android.intent.action.SEND" />
<category android:name="android.intent.category.DEFAULT" />
</intent-filter>
</activity>
```
Intent-filter musi pasować do **działania**, **danych** i **kategorii**, aby otrzymać wiadomość.

Proces "Rozstrzygania intencji" określa, która aplikacja powinna otrzymać każdą wiadomość. Proces ten uwzględnia atrybut **priorytetu**, który może być ustawiony w deklaracji **intent-filter**, a **ten z wyższym priorytetem zostanie wybrany**. Priorytet ten można ustawić między -1000 a 1000, a aplikacje mogą używać wartości `SYSTEM_HIGH_PRIORITY`. Jeśli **wystąpi konflikt**, pojawia się okno "wyboru", dzięki czemu **użytkownik może zdecydować**.

### Jawne intencje

Jawna intencja określa nazwę klasy, do której jest kierowana:
```java
Intent downloadIntent = new (this, DownloadService.class):
```
W innych aplikacjach, aby uzyskać dostęp do wcześniej zadeklarowanego zamiaru, można użyć:
```java
Intent intent = new Intent();
intent.setClassName("com.other.app", "com.other.app.ServiceName");
context.startService(intent);
```
### Intencje oczekujące

Pozwalają innym aplikacjom **wykonywać czynności w imieniu Twojej aplikacji**, korzystając z tożsamości i uprawnień Twojej aplikacji. Konstruując Intencję oczekującą, należy **określić intencję i akcję do wykonania**. Jeśli **zadeklarowana intencja nie jest jawna** (nie określa, która intencja może ją wywołać), **złośliwa aplikacja może wykonać zadeklarowaną akcję** w imieniu aplikacji ofiary. Ponadto, **jeśli akcja nie jest określona**, złośliwa aplikacja będzie mogła wykonać **dowolną akcję w imieniu ofiary**.

### Intencje rozgłoszeniowe

W przeciwieństwie do poprzednich intencji, które są odbierane tylko przez jedną aplikację, intencje rozgłoszeniowe **mogą być odbierane przez wiele aplikacji**. Jednakże, począwszy od wersji API 14, jest **możliwe określenie aplikacji, która powinna otrzymać** wiadomość, korzystając z Intent.set Package.

Alternatywnie, jest również możliwe **określenie uprawnienia podczas wysyłania rozgłoszenia**. Aplikacja odbiorcza będzie musiała posiadać to uprawnienie.

Istnieją **dwa rodzaje** rozgłoszeń: **Normalne** (asynchroniczne) i **Uporządkowane** (synchroniczne). **Kolejność** jest ustalana na podstawie **skonfigurowanego priorytetu w elemencie odbiorcy**. **Każda aplikacja może przetwarzać, przekazywać lub odrzucać rozgłoszenie**.

Możliwe jest **wysłanie** rozgłoszenia za pomocą funkcji `sendBroadcast(intent, receiverPermission)` z klasy `Context`.\
Można również użyć funkcji **`sendBroadcast`** z **`LocalBroadCastManager`**, co zapewnia, że **wiadomość nigdy nie opuści aplikacji**. Dzięki temu nie będzie nawet konieczne eksportowanie komponentu odbiorcy.

### Rozgłoszenia trwałe

Ten rodzaj rozgłoszeń **może być dostępny długo po ich wysłaniu**.\
Zostały one oznaczone jako przestarzałe w poziomie API 21 i zaleca się **nie korzystanie z nich**.\
**Pozwalają one dowolnej aplikacji na podsłuchanie danych, ale także na ich modyfikację**.

Jeśli znajdziesz funkcje zawierające słowo "trwałe" jak **`sendStickyBroadcast`** lub **`sendStickyBroadcastAsUser`**, **sprawdź wpływ i spróbuj je usunąć**.

## Głębokie linki / schematy URL

W aplikacjach Androida, **głębokie linki** są używane do uruchamiania akcji (Intencji) bezpośrednio za pomocą adresu URL. Jest to realizowane poprzez zadeklarowanie określonego **schematu URL** wewnątrz aktywności. Gdy urządzenie z systemem Android próbuje **uzyskać dostęp do adresu URL z tym schematem**, uruchamiana jest określona aktywność w aplikacji.

Schemat musi być zadeklarowany w pliku **`AndroidManifest.xml`**:
```xml
[...]
<activity android:name=".MyActivity">
<intent-filter>
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.DEFAULT" />
<category android:name="android.intent.category.BROWSABLE" />
<data android:scheme="examplescheme" />
</intent-filter>
[...]
```
Schemat z poprzedniego przykładu to `exampleapp://` (zauważ również **`kategoria BROWSABLE`**)

Następnie, w polu danych, możesz określić **host** i **ścieżkę**:
```xml
<data android:scheme="examplescheme"
android:host="example"
/>
```
Aby uzyskać do niego dostęp z sieci, można ustawić link w ten sposób:
```xml
<a href="examplescheme://example/something">click here</a>
<a href="examplescheme://example/javascript://%250dalert(1)">click here</a>
```
Aby znaleźć **kod, który zostanie wykonany w aplikacji**, przejdź do aktywności wywołanej przez deeplink i wyszukaj funkcję **`onNewIntent`**.

Dowiedz się, jak [wywoływać głębokie linki bez użycia stron HTML](./#exploiting-schemes-deep-links).

## AIDL - Android Interface Definition Language

**Android Interface Definition Language (AIDL)** został zaprojektowany w celu ułatwienia komunikacji między klientem a usługą w aplikacjach Android za pomocą **komunikacji międzyprocesowej** (IPC). Ponieważ bezpośredni dostęp do pamięci innego procesu nie jest dozwolony w systemie Android, AIDL upraszcza proces poprzez marshaling obiektów do formatu zrozumiałego przez system operacyjny, ułatwiając tym samym komunikację między różnymi procesami.

### Kluczowe koncepcje

- **Usługi powiązane**: Te usługi wykorzystują AIDL do IPC, umożliwiając aktywnościom lub komponentom powiązanie się z usługą, składanie żądań i odbieranie odpowiedzi. Metoda `onBind` w klasie usługi jest kluczowa dla inicjowania interakcji, co czyni ją istotnym obszarem do przeglądu pod kątem bezpieczeństwa w poszukiwaniu podatności.

- **Messenger**: Działając jako usługa powiązana, Messenger ułatwia IPC z naciskiem na przetwarzanie danych za pomocą metody `onBind`. Istotne jest dokładne sprawdzenie tej metody pod kątem niebezpiecznego przetwarzania danych lub wykonywania funkcji wymagających ochrony.

- **Binder**: Chociaż bezpośrednie użycie klasy Binder jest mniej powszechne ze względu na abstrakcję AIDL, warto zrozumieć, że Binder działa jako sterownik na poziomie jądra ułatwiający transfer danych między przestrzeniami pamięci różnych procesów. Dla lepszego zrozumienia dostępny jest zasób pod adresem [https://www.youtube.com/watch?v=O-UHvFjxwZ8](https://www.youtube.com/watch?v=O-UHvFjxwZ8).

## Komponenty

Obejmują one: **Aktywności, Usługi, Odbiorniki nadawcze i Dostawcy.**

### Aktywność uruchamiająca i inne aktywności

W aplikacjach Android **aktywności** są jak ekrany, prezentujące różne części interfejsu użytkownika aplikacji. Aplikacja może mieć wiele aktywności, z których każda prezentuje użytkownikowi unikalny ekran.

**Aktywność uruchamiająca** jest głównym wejściem do aplikacji, uruchamianym po naciśnięciu ikony aplikacji. Jest zdefiniowana w pliku manifestu aplikacji za pomocą konkretnych intencji MAIN i LAUNCHER:
```markup
<activity android:name=".LauncherActivity">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>
```
Nie wszystkie aplikacje potrzebują aktywności uruchomieniowej, zwłaszcza te bez interfejsu użytkownika, takie jak usługi w tle.

Aby udostępnić aktywności innym aplikacjom lub procesom, można oznaczyć je jako "eksportowane" w pliku manifestu. Ta opcja pozwala innym aplikacjom uruchamiać tę aktywność:
```markdown
<service android:name=".ExampleExportedService" android:exported="true"/>
```
Jednakże dostęp do aktywności z innej aplikacji nie zawsze stanowi ryzyko dla bezpieczeństwa. Obawa pojawia się, jeśli poufne dane są udostępniane nieprawidłowo, co może prowadzić do wycieku informacji.

Cykl życia aktywności **rozpoczyna się od metody onCreate**, która ustawia interfejs użytkownika i przygotowuje aktywność do interakcji z użytkownikiem.

### Podklasa aplikacji

W rozwoju aplikacji na Androida, aplikacja ma opcję utworzenia **podklasy** klasy [Application](https://developer.android.com/reference/android/app/Application), chociaż nie jest to obowiązkowe. Gdy taka podklasa jest zdefiniowana, staje się pierwszą klasą do zainicjowania w aplikacji. Metoda **`attachBaseContext`**, jeśli zaimplementowana w tej podklasie, jest wykonywana przed metodą **`onCreate`**. To ustawienie pozwala na wczesną inicjalizację przed uruchomieniem reszty aplikacji.
```java
public class MyApp extends Application {
@Override
protected void attachBaseContext(Context base) {
super.attachBaseContext(base);
// Initialization code here
}

@Override
public void onCreate() {
super.onCreate();
// More initialization code
}
}
```
### Usługi

[Usługi](https://developer.android.com/guide/components/services) to **operacje w tle** zdolne do wykonywania zadań bez interfejsu użytkownika. Te zadania mogą kontynuować działanie nawet gdy użytkownicy przełączają się na inne aplikacje, co czyni usługi niezbędnymi do **długotrwałych operacji**.

Usługi są wszechstronne; mogą być uruchamiane na różne sposoby, przy użyciu **Intents** jako głównego sposobu uruchamiania jako punktu wejścia aplikacji. Gdy usługa zostanie uruchomiona za pomocą metody `startService`, jej metoda `onStart` rozpoczyna działanie i działa do momentu wywołania metody `stopService`. Alternatywnie, jeśli rola usługi zależy od aktywnego połączenia klienta, używana jest metoda `bindService` do powiązania klienta z usługą, wywołując metodę `onBind` do przekazywania danych.

Interesującym zastosowaniem usług jest odtwarzanie muzyki w tle lub pobieranie danych z sieci bez zakłócania interakcji użytkownika z aplikacją. Ponadto, usługi mogą być udostępnione innym procesom na tym samym urządzeniu poprzez **eksportowanie**. To nie jest zachowanie domyślne i wymaga jawnego skonfigurowania w pliku Android Manifest:
```xml
<service android:name=".ExampleExportedService" android:exported="true"/>
```
### Odbiorniki nadawcze

**Odbiorniki nadawcze** działają jako słuchacze w systemie komunikacyjnym, pozwalając wielu aplikacjom reagować na te same wiadomości z systemu. Aplikacja może **zarejestrować odbiornik** na **dwa podstawowe sposoby**: poprzez **Manifest** aplikacji lub **dynamicznie** w kodzie aplikacji za pomocą interfejsu API **`registerReceiver`**. W przypadku Manifestu, nadawane są filtrowane z uprawnieniami, podczas gdy dynamicznie zarejestrowane odbiorniki mogą również określić uprawnienia podczas rejestracji.

**Filtry intencji** są kluczowe w obu metodach rejestracji, określając, które nadawane są wyzwalane przez odbiornik. Po wysłaniu pasującego nadawania, metoda **`onReceive`** odbiornika jest wywoływana, umożliwiając aplikacji reagowanie odpowiednio, na przykład dostosowanie zachowania w odpowiedzi na alert o niskim poziomie baterii.

Nadawania mogą być albo **asynchroniczne**, docierając do wszystkich odbiorników bez kolejności, albo **synchroniczne**, gdzie odbiorniki otrzymują nadawanie na podstawie ustawionych priorytetów. Jednak ważne jest zauważenie potencjalnego ryzyka bezpieczeństwa, ponieważ dowolna aplikacja może nadać sobie priorytet, aby przechwycić nadawanie.

Aby zrozumieć funkcjonalność odbiornika, należy szukać metody **`onReceive`** wewnątrz jego klasy. Kod tej metody może manipulować otrzymaną intencją, podkreślając potrzebę walidacji danych przez odbiorniki, zwłaszcza w przypadku **Nadawań uporządkowanych**, które mogą modyfikować lub odrzucać intencję.

### Dostawca treści

**Dostawcy treści** są niezbędne do **udostępniania strukturyzowanych danych** między aplikacjami, podkreślając znaczenie implementacji **uprawnień** w celu zapewnienia bezpieczeństwa danych. Pozwalają aplikacjom uzyskiwać dostęp do danych z różnych źródeł, w tym baz danych, systemów plików lub sieci. Określone uprawnienia, takie jak **`readPermission`** i **`writePermission`**, są kluczowe dla kontroli dostępu. Dodatkowo, tymczasowy dostęp można udzielić za pomocą ustawień **`grantUriPermission`** w manifestacji aplikacji, wykorzystując atrybuty takie jak `path`, `pathPrefix` i `pathPattern` do szczegółowej kontroli dostępu.

Walidacja danych jest kluczowa dla zapobiegania podatnościom, takim jak wstrzyknięcie SQL. Dostawcy treści obsługują podstawowe operacje: `insert()`, `update()`, `delete()` i `query()`, ułatwiając manipulację danymi i ich udostępnianie między aplikacjami.

**FileProvider**, specjalizowany dostawca treści, skupia się na bezpiecznym udostępnianiu plików. Jest zdefiniowany w manifestacji aplikacji z określonymi atrybutami do kontroli dostępu do folderów, oznaczonych przez `android:exported` i `android:resource` wskazujące na konfiguracje folderów. Zaleca się ostrożność podczas udostępniania katalogów, aby uniknąć przypadkowego ujawnienia wrażliwych danych.

Przykładowe oświadczenie manifestu dla FileProvider:
```xml
<provider android:name="androidx.core.content.FileProvider"
android:authorities="com.example.myapp.fileprovider"
android:grantUriPermissions="true"
android:exported="false">
<meta-data android:name="android.support.FILE_PROVIDER_PATHS"
android:resource="@xml/filepaths" />
</provider>
```
I przykład określenia współdzielonych folderów w `filepaths.xml`:
```xml
<paths>
<files-path path="images/" name="myimages" />
</paths>
```
Dla dalszych informacji sprawdź:
- [Deweloperzy Androida: Dostawcy treści](https://developer.android.com/guide/topics/providers/content-providers)
- [Deweloperzy Androida: FileProvider](https://developer.android.com/training/secure-file-sharing/setup-sharing)

## WebViews

WebViews są jak **mini przeglądarki internetowe** wewnątrz aplikacji na Androida, pobierające treści z sieci lub z plików lokalnych. Stoją w obliczu podobnych zagrożeń jak zwykłe przeglądarki, ale istnieją sposoby na **zmniejszenie tych zagrożeń** poprzez konkretne **ustawienia**.

Android oferuje dwa główne typy WebView:

- **WebViewClient** jest świetny do podstawowego HTML, ale nie obsługuje funkcji alert JavaScript, co wpływa na sposób testowania ataków XSS.
- **WebChromeClient** działa bardziej jak pełne doświadczenie przeglądarki Chrome.

Kluczowym punktem jest to, że przeglądarki WebView **nie dzielą plików cookie** z główną przeglądarką urządzenia.

Do ładowania treści dostępne są metody takie jak ````loadUrl````, ````loadData````, i ````loadDataWithBaseURL````. Ważne jest, aby upewnić się, że te adresy URL lub pliki są **bezpieczne do użycia**. Ustawienia zabezpieczeń można zarządzać za pomocą klasy ````WebSettings````. Na przykład, wyłączenie JavaScript za pomocą ````setJavaScriptEnabled(false)```` może zapobiec atakom XSS.

Most JavaScript "Bridge" pozwala obiektom Javy współdziałać z JavaScript, wymagając oznaczenia metod za pomocą ````@JavascriptInterface```` dla bezpieczeństwa od wersji Androida 4.2.

Zezwalanie na dostęp do treści (````setAllowContentAccess(true)````) pozwala WebView na dostęp do dostawców treści, co może stanowić ryzyko, chyba że adresy URL treści są zweryfikowane jako bezpieczne.

Aby kontrolować dostęp do plików:
- Wyłączenie dostępu do plików (````setAllowFileAccess(false)````) ogranicza dostęp do systemu plików, z wyjątkami dla określonych zasobów, zapewniając, że są one używane tylko do treści niewrażliwej.

## Inne składniki aplikacji i zarządzanie urządzeniami mobilnymi

### **Cyfrowe podpisywanie aplikacji**

- **Cyfrowe podpisywanie** jest konieczne dla aplikacji na Androida, zapewniając, że są **autentycznie autoryzowane** przed instalacją. Proces ten wykorzystuje certyfikat do identyfikacji aplikacji i musi zostać zweryfikowany przez menedżera pakietów urządzenia podczas instalacji. Aplikacje mogą być **podpisane przez siebie lub certyfikowane przez zewnętrzne CA**, chroniąc przed nieautoryzowanym dostępem i zapewniając, że aplikacja pozostaje nietknięta podczas dostarczania na urządzenie.

### **Weryfikacja aplikacji dla zwiększonego bezpieczeństwa**

- Począwszy od **Androida 4.2**, funkcja o nazwie **Weryfikuj aplikacje** pozwala użytkownikom sprawdzać aplikacje pod kątem bezpieczeństwa przed instalacją. Ten **proces weryfikacji** może ostrzegać użytkowników przed potencjalnie szkodliwymi aplikacjami lub nawet uniemożliwiać instalację szczególnie złośliwych, zwiększając bezpieczeństwo użytkownika.

### **Zarządzanie urządzeniami mobilnymi (MDM)**

- **Rozwiązania MDM** zapewniają **nadzór i bezpieczeństwo** dla urządzeń mobilnych za pomocą **API Administracji urządzeń**. Wymagają one instalacji aplikacji na Androida do skutecznego zarządzania i zabezpieczania urządzeń mobilnych. Kluczowe funkcje obejmują **narzucanie polityk haseł**, **obowiązkowe szyfrowanie pamięci**, i **zezwolenie na zdalne wymazywanie danych**, zapewniając kompleksową kontrolę i bezpieczeństwo nad urządzeniami mobilnymi.
```java
// Example of enforcing a password policy with MDM
DevicePolicyManager dpm = (DevicePolicyManager) getSystemService(Context.DEVICE_POLICY_SERVICE);
ComponentName adminComponent = new ComponentName(context, AdminReceiver.class);

if (dpm.isAdminActive(adminComponent)) {
// Set minimum password length
dpm.setPasswordMinimumLength(adminComponent, 8);
}
```
**Grupa Try Hard Security**

<figure><img src="/.gitbook/assets/telegram-cloud-document-1-5159108904864449420.jpg" alt=""><figcaption></figcaption></figure>

{% embed url="https://discord.gg/tryhardsecurity" %}

<details>

<summary><strong>Zdobądź wiedzę na temat hakowania AWS od zera do bohatera z</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>

Inne sposoby wsparcia HackTricks:

* Jeśli chcesz zobaczyć swoją **firmę reklamowaną w HackTricks** lub **pobrać HackTricks w formacie PDF**, sprawdź [**PLANY SUBSKRYPCYJNE**](https://github.com/sponsors/carlospolop)!
* Zdobądź [**oficjalne gadżety PEASS & HackTricks**](https://peass.creator-spring.com)
* Odkryj [**Rodzinę PEASS**](https://opensea.io/collection/the-peass-family), naszą kolekcję ekskluzywnych [**NFT**](https://opensea.io/collection/the-peass-family)
* **Dołącz do** 💬 [**grupy Discord**](https://discord.gg/hRep4RUj7f) lub [**grupy telegramowej**](https://t.me/peass) lub **śledź** nas na **Twitterze** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Podziel się swoimi sztuczkami hakerskimi, przesyłając PR-y do** [**HackTricks**](https://github.com/carlospolop/hacktricks) i [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.

</details>