# Android Uygulamaları Temelleri
{{#include ../../banners/hacktricks-training.md}}
## Android Güvenlik Modeli
**İki katman vardır:**
- **OS**, yüklü uygulamaları birbirinden izole tutar.
- **uygulamanın kendisi**, geliştiricilerin **belirli işlevsellikleri açığa çıkarmasına** ve uygulama yeteneklerini yapılandırmasına olanak tanır.
### UID Ayrımı
**Her uygulamaya belirli bir Kullanıcı Kimliği atanır**. Bu, uygulamanın yüklenmesi sırasında yapılır, böylece **uygulama yalnızca kendi Kullanıcı Kimliğine ait dosyalarla veya paylaşılan** dosyalarla etkileşimde bulunabilir. Bu nedenle, yalnızca uygulamanın kendisi, OS'nin belirli bileşenleri ve root kullanıcısı uygulama verilerine erişebilir.
### UID Paylaşımı
**İki uygulama aynı UID'yi kullanacak şekilde yapılandırılabilir**. Bu, bilgi paylaşmak için yararlı olabilir, ancak bunlardan biri tehlikeye girerse, her iki uygulamanın verileri de tehlikeye girecektir. Bu nedenle bu davranış **kaçınılması gereken bir durumdur**.\
**Aynı UID'yi paylaşmak için, uygulamalar manifestolarında aynı `android:sharedUserId` değerini tanımlamalıdır.**
### Sandbox
**Android Uygulama Sandbox'ı**, **her uygulamanın** **ayrı bir kullanıcı kimliği altında ayrı bir işlem olarak çalıştırılmasına olanak tanır**. Her işlem kendi sanal makinesine sahiptir, bu nedenle bir uygulamanın kodu diğer uygulamalardan izole bir şekilde çalışır.\
Android 5.0(L) itibarıyla **SELinux** uygulanmaktadır. Temelde, SELinux tüm işlem etkileşimlerini reddetti ve ardından **aralarındaki beklenen etkileşimlere yalnızca izin vermek için politikalar oluşturdu**.
### İzinler
Bir **uygulama yüklendiğinde ve izinler istediğinde**, uygulama **AndroidManifest.xml** dosyasındaki **`uses-permission`** öğelerinde yapılandırılan izinleri istemektedir. **uses-permission** öğesi, istenen iznin adını **name** **özniteliği içinde belirtir.** Ayrıca, belirtilen sürümden daha yüksek sürümlerde izin istemeyi durduran **maxSdkVersion** özniteliğine de sahiptir.\
Android uygulamaları başlangıçta tüm izinleri istemek zorunda değildir, ayrıca **dinamik olarak izin isteyebilirler**, ancak tüm izinler **manifestoda** **belirtilmelidir.**
Bir uygulama işlevsellik açığa çıkardığında, **yalnızca belirli bir izne sahip uygulamalara erişimi sınırlayabilir**.\
Bir izin öğesinin üç özniteliği vardır:
- İznin **adı**
- İzinlerin gruplandırılmasına olanak tanıyan **permission-group** özniteliği.
- İzinlerin nasıl verildiğini belirten **protection-level**. Dört tür vardır:
- **Normal**: Uygulama için **bilinen bir tehdit yoksa** kullanılır. Kullanıcının **onaylaması gerekmez**.
- **Tehlikeli**: İznin, istek yapan uygulamaya bazı **yükseltilmiş erişimler** verdiğini belirtir. **Kullanıcılardan onay istenir**.
- **İmza**: Yalnızca **bileşeni dışa aktaranla aynı sertifika ile imzalanmış uygulamalar** izin alabilir. Bu, en güçlü koruma türüdür.
- **İmza veya Sistem**: Yalnızca **bileşeni dışa aktaranla aynı sertifika ile imzalanmış uygulamalar veya **sistem düzeyinde erişimle çalışan uygulamalar** izin alabilir.
## Önceden Yüklenmiş Uygulamalar
Bu uygulamalar genellikle **`/system/app`** veya **`/system/priv-app`** dizinlerinde bulunur ve bazıları **optimize edilmiştir** (belki de `classes.dex` dosyasını bile bulamazsınız). Bu uygulamalar, bazen **çok fazla izinle çalıştıkları** için kontrol edilmeye değerdir (root olarak).
- **AOSP** (Android Açık Kaynak Projesi) **ROM** ile birlikte gelenler
- Cihaz **üreticisi** tarafından eklenenler
- **Telefon sağlayıcısı** tarafından eklenenler (eğer onlardan satın alındıysa)
## Rootlama
Bir fiziksel android cihazda root erişimi elde etmek için genellikle **1 veya 2 güvenlik açığını istismar etmeniz** gerekir; bu açılar genellikle **cihaz** ve **sürüm** için **özeldir**.\
İstismar çalıştığında, genellikle Linux `su` ikili dosyası, kullanıcının PATH ortam değişkeninde belirtilen bir konuma, örneğin `/system/xbin`'e kopyalanır.
Su ikili dosyası yapılandırıldıktan sonra, `su` ikili dosyası ile etkileşimde bulunmak için başka bir Android uygulaması kullanılır ve **root erişimi için istekleri işler**; bu uygulamalar **Superuser** ve **SuperSU** (Google Play mağazasında mevcuttur).
> [!CAUTION]
> Rootlama işleminin çok tehlikeli olduğunu ve cihazı ciddi şekilde zarar verebileceğini unutmayın.
### ROM'lar
**Özel bir yazılım yükleyerek işletim sistemini değiştirmek mümkündür**. Bunu yaparak, eski bir cihazın kullanımını genişletmek, yazılım kısıtlamalarını aşmak veya en son Android koduna erişmek mümkündür.\
**OmniROM** ve **LineageOS**, kullanılacak en popüler yazılımlardan ikisidir.
**Cihazı rootlamak her zaman gerekli değildir**; bazı **üreticiler**, bootloader'larını iyi belgelenmiş ve güvenli bir şekilde kilidini açmaya izin verir.
### Sonuçlar
Bir cihaz rootlandığında, herhangi bir uygulama root olarak erişim isteyebilir. Eğer kötü niyetli bir uygulama bunu elde ederse, neredeyse her şeye erişimi olacak ve telefonu zarar verebilecektir.
## Android Uygulama Temelleri
- Android uygulamalarının formatı _APK dosya formatı_ olarak adlandırılır. Temelde bir **ZIP dosyasıdır** (dosya uzantısını .zip olarak değiştirerek, içerikler çıkarılabilir ve görüntülenebilir).
- APK İçerikleri (kapsamlı değil)
- **AndroidManifest.xml**
- resources.arsc/strings.xml
- resources.arsc: önceden derlenmiş kaynakları, ikili XML gibi içerir.
- res/xml/files_paths.xml
- META-INF/
- Sertifikanın bulunduğu yer burasıdır!
- **classes.dex**
- Uygulamanın varsayılan olarak çalıştırdığı derlenmiş Java (veya Kotlin) kodunu temsil eden Dalvik bytecode içerir.
- lib/
- CPU mimarisine göre alt dizinlerde ayrılmış yerel kütüphaneleri barındırır.
- `armeabi`: ARM tabanlı işlemciler için kod
- `armeabi-v7a`: ARMv7 ve daha yüksek tabanlı işlemciler için kod
- `x86`: X86 işlemciler için kod
- `mips`: yalnızca MIPS işlemcileri için kod
- assets/
- Uygulamanın ihtiyaç duyduğu çeşitli dosyaları depolar; bunlar, bazen kötü amaçlı yazılım yazarları tarafından ek kodu gizlemek için kullanılan ek yerel kütüphaneler veya DEX dosyalarını içerebilir.
- res/
- resources.arsc içine derlenmemiş kaynakları içerir.
### **Dalvik & Smali**
Android geliştirmede, **Java veya Kotlin** uygulama oluşturmak için kullanılır. Masaüstü uygulamalarındaki gibi JVM kullanmak yerine, Android bu kodu **Dalvik Executable (DEX) bytecode**'a derler. Daha önce, Dalvik sanal makinesi bu bytecode'u yönetiyordu, ancak şimdi, daha yeni Android sürümlerinde Android Runtime (ART) devralmıştır.
Tersine mühendislik için, **Smali** kritik hale gelir. Bu, DEX bytecode'un insan tarafından okunabilir versiyonudur ve kaynak kodunu bytecode talimatlarına çevirerek montaj dili gibi işlev görür. Smali ve baksmali, bu bağlamda montaj ve ayrıştırma araçlarını ifade eder.
## Niyetler
Niyetler, Android uygulamalarının bileşenleri arasında veya diğer uygulamalarla iletişim kurmanın birincil yoludur. Bu mesaj nesneleri, uygulamalar veya bileşenler arasında veri taşıyabilir; bu, HTTP iletişimlerinde GET/POST isteklerinin nasıl kullanıldığına benzer.
Yani bir Niyet, temelde **bileşenler arasında iletilen bir mesajdır**. Niyetler **belirli bileşenlere veya uygulamalara yönlendirilebilir** veya **belirli bir alıcı olmadan gönderilebilir**.\
Basitçe, Niyet şu amaçlarla kullanılabilir:
- Bir Aktivite başlatmak, genellikle bir uygulama için bir kullanıcı arayüzü açmak
- Sistemi ve uygulamaları değişiklikler hakkında bilgilendirmek için yayınlar olarak
- Arka planda bir hizmeti başlatmak, durdurmak ve onunla iletişim kurmak
- ContentProviders aracılığıyla verilere erişmek
- Olayları işlemek için geri çağırmalar olarak
Eğer savunmasızsa, **Niyetler çeşitli saldırılar gerçekleştirmek için kullanılabilir**.
### Niyet-Filtre
**Niyet Filtreleri**, **bir aktivite, hizmet veya Yayın Alıcısının farklı türdeki Niyetlerle nasıl etkileşimde bulunabileceğini tanımlar**. Temelde, bu bileşenlerin hangi eylemleri gerçekleştirebileceği veya hangi tür yayınları işleyebileceği gibi yeteneklerini tanımlar. Bu filtreleri beyan etmenin birincil yeri **AndroidManifest.xml dosyasıdır**, ancak Yayın Alıcıları için kodlama da bir seçenek olabilir.
Niyet Filtreleri, kategoriler, eylemler ve veri filtrelerinden oluşur ve ek meta verilerin dahil edilmesi mümkündür. Bu yapı, bileşenlerin beyan edilen kriterlere uyan belirli Niyetleri işleyebilmesini sağlar.
Android bileşenlerinin (aktivite/hizmet/içerik sağlayıcıları/yayın alıcıları) kritik bir yönü, görünürlükleri veya **kamusal durumlarıdır**. Bir bileşen, **`exported`** değeri **`true`** olarak ayarlandığında kamuya açık kabul edilir ve diğer uygulamalarla etkileşimde bulunabilir. Ancak, geliştiricilerin bu bileşenleri özel tutma seçeneği vardır; bu, diğer uygulamalarla istemeden etkileşimde bulunmamalarını sağlamak için **`exported`** özniteliğini **`false`** olarak ayarlamakla gerçekleştirilir.
Ayrıca, geliştiricilerin bu bileşenlere erişimi daha da güvence altına almak için belirli izinler talep etme seçeneği vardır. **`permission`** özniteliği, yalnızca belirlenen izne sahip uygulamaların bileşene erişebilmesini sağlamak için ayarlanabilir ve bu, kimin etkileşimde bulunabileceği üzerinde ek bir güvenlik ve kontrol katmanı ekler.
```java
```
### İkincil Niyetler
Niyetler, bir Niyet yapıcısı kullanılarak programatik olarak oluşturulur:
```java
Intent email = new Intent(Intent.ACTION_SEND, Uri.parse("mailto:"));
```
**Daha önce tanımlanan** intent'in **Eylemi** **ACTION_SEND** ve **Ek** bir mailto **Uri**'dir (Ek, intent'in beklediği ek bilgidir).
Bu intent, aşağıdaki örnekte olduğu gibi manifest içinde tanımlanmalıdır:
```xml
```
Bir intent-filter'ın bir mesajı alabilmesi için **action**, **data** ve **category** ile eşleşmesi gerekir.
"Intent çözümleme" süreci, her mesajın hangi uygulama tarafından alınacağını belirler. Bu süreç, **priority attribute**'unu dikkate alır; bu, i**ntent-filter bildirimi** içinde ayarlanabilir ve **daha yüksek önceliğe sahip olan seçilecektir**. Bu öncelik -1000 ile 1000 arasında ayarlanabilir ve uygulamalar `SYSTEM_HIGH_PRIORITY` değerini kullanabilir. Eğer bir **çelişki** oluşursa, **kullanıcının karar verebileceği** bir "chooser" penceresi görünür.
### Açık Intents
Açık bir intent, hedef aldığı sınıf adını belirtir:
```java
Intent downloadIntent = new (this, DownloadService.class):
```
Diğer uygulamalarda daha önce tanımlanan niyete erişmek için şunu kullanabilirsiniz:
```java
Intent intent = new Intent();
intent.setClassName("com.other.app", "com.other.app.ServiceName");
context.startService(intent);
```
### Pending Intents
Bunlar diğer uygulamaların **uygulamanız adına eylemler gerçekleştirmesine** olanak tanır, uygulamanızın kimliği ve izinlerini kullanarak. Bir Pending Intent oluştururken **bir intent ve gerçekleştirilecek eylem belirtilmelidir**. Eğer **belirtilen intent Açık Değilse** (hangi intentin çağrılabileceğini belirtmiyorsa) **kötü niyetli bir uygulama, mağdur uygulama adına belirtilen eylemi gerçekleştirebilir**. Dahası, **bir eylem belirtilmemişse**, kötü niyetli uygulama **mağdur adına herhangi bir eylem gerçekleştirebilir**.
### Broadcast Intents
Önceki intentlerden farklı olarak, yalnızca bir uygulama tarafından alınan, broadcast intentler **birden fazla uygulama tarafından alınabilir**. Ancak, API sürüm 14'ten itibaren, mesajı alacak uygulamanın **belirtilmesi mümkündür**; bu, Intent.setPackage kullanılarak yapılır.
Alternatif olarak, **yayın gönderirken bir izin belirtmek de mümkündür**. Alıcı uygulamanın bu izne sahip olması gerekecektir.
**İki tür** Yayın vardır: **Normal** (asenkron) ve **Sıralı** (senkron). **Sıra**, **alıcı** öğesindeki **yapılandırılmış önceliğe** dayanır. **Her uygulama Yayını işleyebilir, iletebilir veya atlayabilir.**
`Context` sınıfından `sendBroadcast(intent, receiverPermission)` fonksiyonunu kullanarak **bir yayın göndermek** mümkündür.\
Ayrıca, **`LocalBroadCastManager`**'dan **`sendBroadcast`** fonksiyonunu kullanarak **mesajın uygulamadan çıkmamasını** sağlayabilirsiniz. Bunu kullanarak bir alıcı bileşenini dışa aktarmanıza gerek kalmaz.
### Sticky Broadcasts
Bu tür Yayınlar **gönderildikten uzun süre sonra erişilebilir**.\
API seviye 21'de kullanımdan kaldırılmıştır ve **kullanılmaması önerilir**.\
**Herhangi bir uygulamanın verileri dinlemesine, aynı zamanda bunları değiştirmesine olanak tanır.**
"sticky" kelimesini içeren fonksiyonlar bulursanız, örneğin **`sendStickyBroadcast`** veya **`sendStickyBroadcastAsUser`**, **etkisini kontrol edin ve bunları kaldırmaya çalışın**.
## Deep links / URL schemes
Android uygulamalarında, **deep links** bir eylemi (Intent) doğrudan bir URL aracılığıyla başlatmak için kullanılır. Bu, bir aktivite içinde belirli bir **URL şeması** tanımlanarak yapılır. Bir Android cihazı bu şemaya sahip bir **URL'ye erişmeye çalıştığında**, uygulama içindeki belirtilen aktivite başlatılır.
Şema, **`AndroidManifest.xml`** dosyasında belirtilmelidir:
```xml
[...]
[...]
```
Önceki örnekteki şema `examplescheme://` (aynı zamanda **`category BROWSABLE`**'ı da not edin)
Daha sonra, veri alanında **host** ve **path** belirtebilirsiniz:
```xml
```
Bir web üzerinden erişmek için şu şekilde bir bağlantı ayarlamak mümkündür:
```xml
click here
click here
```
Uygulamada **çalıştırılacak kodu** bulmak için, derin bağlantı tarafından çağrılan aktiviteye gidin ve **`onNewIntent`** fonksiyonunu arayın.
HTML sayfaları kullanmadan [derin bağlantıları nasıl çağıracağınızı öğrenin](#exploiting-schemes-deep-links).
## AIDL - Android Arayüz Tanım Dili
**Android Arayüz Tanım Dili (AIDL)**, Android uygulamalarında istemci ve hizmet arasında **işlem arası iletişim** (IPC) sağlamak için tasarlanmıştır. Android'de başka bir işlemin belleğine doğrudan erişim izni verilmediğinden, AIDL, nesneleri işletim sistemi tarafından anlaşılan bir formata marşallayarak, farklı işlemler arasında iletişimi kolaylaştırır.
### Temel Kavramlar
- **Bağlı Hizmetler**: Bu hizmetler IPC için AIDL kullanır, aktivitelerin veya bileşenlerin bir hizmete bağlanmasına, isteklerde bulunmasına ve yanıt almasına olanak tanır. Hizmetin sınıfındaki `onBind` metodu, etkileşimi başlatmak için kritik öneme sahiptir ve güvenlik incelemesi için zafiyet arayışında önemli bir alan olarak işaretlenmelidir.
- **Messenger**: Bağlı bir hizmet olarak çalışan Messenger, `onBind` metodu aracılığıyla veri işleme odaklı IPC'yi kolaylaştırır. Bu metodun, güvensiz veri işleme veya hassas fonksiyonların yürütülmesi açısından dikkatlice incelenmesi önemlidir.
- **Binder**: Binder sınıfının doğrudan kullanımı AIDL'in soyutlaması nedeniyle daha az yaygın olsa da, Binder'ın farklı işlemlerin bellek alanları arasında veri transferini kolaylaştıran bir çekirdek düzeyinde sürücü olduğunu anlamak faydalıdır. Daha fazla bilgi için [https://www.youtube.com/watch?v=O-UHvFjxwZ8](https://www.youtube.com/watch?v=O-UHvFjxwZ8) adresine başvurabilirsiniz.
## Bileşenler
Bunlar: **Aktiviteler, Hizmetler, Yayın Alıcıları ve Sağlayıcılar.**
### Başlatıcı Aktivite ve diğer aktiviteler
Android uygulamalarında, **aktiviteler** ekranlar gibidir ve uygulamanın kullanıcı arayüzünün farklı bölümlerini gösterir. Bir uygulama birçok aktiviteye sahip olabilir, her biri kullanıcıya benzersiz bir ekran sunar.
**Başlatıcı aktivite**, bir uygulamanın simgesine dokunduğunuzda başlatılan ana geçittir. Uygulamanın manifest dosyasında belirli MAIN ve LAUNCHER niyetleri ile tanımlanmıştır:
```html
```
Tüm uygulamaların bir başlatıcı aktiviteye ihtiyacı yoktur, özellikle kullanıcı arayüzü olmayanlar, arka plan hizmetleri gibi.
Aktiviteler, manifestoda "exported" olarak işaretlenerek diğer uygulamalara veya süreçlere sunulabilir. Bu ayar, diğer uygulamaların bu aktiviteyi başlatmasına izin verir:
```markdown
```
Ancak, başka bir uygulamadan bir aktiviteye erişmek her zaman bir güvenlik riski değildir. Hassas verilerin yanlış bir şekilde paylaşılması durumunda endişe ortaya çıkar, bu da bilgi sızıntılarına yol açabilir.
Bir aktivitenin yaşam döngüsü **onCreate yöntemi ile başlar**, UI'yı kurar ve aktiviteyi kullanıcı ile etkileşim için hazırlar.
### Uygulama Alt Sınıfı
Android geliştirmede, bir uygulama **Application** sınıfının bir **alt sınıfını** oluşturma seçeneğine sahiptir, ancak bu zorunlu değildir. Böyle bir alt sınıf tanımlandığında, uygulama içinde oluşturulan ilk sınıf olur. Bu alt sınıfta uygulanmışsa, **`attachBaseContext`** yöntemi **`onCreate`** yönteminden önce çalıştırılır. Bu kurulum, uygulamanın geri kalanı başlamadan önce erken başlatma sağlar.
```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
}
}
```
### Services
[Services](https://developer.android.com/guide/components/services) **arka plan operatifleri** olarak, kullanıcı arayüzü olmadan görevleri yerine getirebilen birimlere denir. Bu görevler, kullanıcılar farklı uygulamalara geçse bile çalışmaya devam edebilir, bu da hizmetleri **uzun süreli işlemler** için kritik hale getirir.
Hizmetler çok yönlüdür; çeşitli şekillerde başlatılabilirler, **Intents** bunları başlatmanın birincil yöntemidir ve bir uygulamanın giriş noktası olarak kullanılır. Bir hizmet `startService` yöntemi ile başlatıldığında, `onStart` yöntemi devreye girer ve `stopService` yöntemi açıkça çağrılana kadar çalışmaya devam eder. Alternatif olarak, bir hizmetin rolü aktif bir istemci bağlantısına bağlıysa, istemciyi hizmete bağlamak için `bindService` yöntemi kullanılır ve veri geçişi için `onBind` yöntemi devreye girer.
Hizmetlerin ilginç bir uygulaması, arka planda müzik çalma veya kullanıcıların bir uygulama ile etkileşimini engellemeden ağ verisi alma gibi işlemlerdir. Ayrıca, hizmetler **dışa aktarma** yoluyla aynı cihazdaki diğer süreçlere erişilebilir hale getirilebilir. Bu, varsayılan bir davranış değildir ve Android Manifest dosyasında açık bir yapılandırma gerektirir:
```xml
```
### Broadcast Receivers
**Broadcast receivers** mesajlaşma sisteminde dinleyici olarak işlev görür, böylece birden fazla uygulama sistemden gelen aynı mesajlara yanıt verebilir. Bir uygulama **iki ana yolla** **bir alıcı kaydedebilir**: uygulamanın **Manifest** dosyası aracılığıyla veya uygulama kodu içinde **dinamik olarak** **`registerReceiver`** API'si ile. Manifest'te, yayınlar izinlerle filtrelenirken, dinamik olarak kaydedilen alıcılar kaydedilme sırasında izinleri de belirtebilir.
**Intent filtreleri**, her iki kayıt yönteminde de kritik öneme sahiptir ve hangi yayınların alıcıyı tetikleyeceğini belirler. Eşleşen bir yayın gönderildiğinde, alıcının **`onReceive`** metodu çağrılır, bu da uygulamanın düşük pil uyarısına yanıt olarak davranışını ayarlamasını sağlar.
Yayınlar **asenkron** olabilir, tüm alıcılara sırasız ulaşır, veya **senkron** olabilir, burada alıcılar belirlenen önceliklere göre yayını alır. Ancak, herhangi bir uygulamanın kendisini önceliklendirebileceği ve bir yayını kesebileceği potansiyel güvenlik riskini not etmek önemlidir.
Bir alıcının işlevselliğini anlamak için, sınıfı içinde **`onReceive`** metodunu arayın. Bu metodun kodu, alınan Intent'i manipüle edebilir ve alıcıların veri doğrulama ihtiyacını vurgular, özellikle **Sıralı Yayınlar**'da, bu Intent'i değiştirebilir veya düşürebilir.
### Content Provider
**Content Providers**, uygulamalar arasında **yapılandırılmış verilerin paylaşımı** için esastır ve veri güvenliğini sağlamak için **izinlerin** uygulanmasının önemini vurgular. Uygulamaların veritabanları, dosya sistemleri veya web gibi çeşitli kaynaklardan veri erişmesine olanak tanır. **`readPermission`** ve **`writePermission`** gibi belirli izinler, erişimi kontrol etmek için kritik öneme sahiptir. Ayrıca, uygulamanın manifestinde **`grantUriPermission`** ayarları aracılığıyla geçici erişim sağlanabilir ve `path`, `pathPrefix` ve `pathPattern` gibi nitelikler kullanılarak ayrıntılı erişim kontrolü yapılabilir.
Girdi doğrulaması, SQL enjeksiyonu gibi güvenlik açıklarını önlemek için son derece önemlidir. Content Providers temel işlemleri destekler: `insert()`, `update()`, `delete()`, ve `query()`, bu da uygulamalar arasında veri manipülasyonu ve paylaşımını kolaylaştırır.
**FileProvider**, dosyaları güvenli bir şekilde paylaşmaya odaklanan özel bir Content Provider'dır. Erişimi kontrol etmek için belirli niteliklerle uygulamanın manifestinde tanımlanır; bu nitelikler `android:exported` ve klasör yapılandırmalarını gösteren `android:resource` ile belirtilir. Hassas verilerin yanlışlıkla ifşa edilmesini önlemek için dizinleri paylaşırken dikkatli olunmalıdır.
FileProvider için örnek manifest bildirimi:
```xml
```
Ve `filepaths.xml` dosyasında paylaşılan klasörleri belirtmenin bir örneği:
```xml
```
Daha fazla bilgi için kontrol edin:
- [Android Developers: Content Providers](https://developer.android.com/guide/topics/providers/content-providers)
- [Android Developers: FileProvider](https://developer.android.com/training/secure-file-sharing/setup-sharing)
## WebViews
WebViews, Android uygulamaları içinde **mini web tarayıcıları** gibidir ve içerikleri ya webden ya da yerel dosyalardan çeker. Normal tarayıcılarla benzer risklerle karşılaşırlar, ancak belirli **ayarlar** aracılığıyla bu **riskleri azaltmanın** yolları vardır.
Android, iki ana WebView türü sunar:
- **WebViewClient**, temel HTML için harikadır ancak JavaScript uyarı fonksiyonunu desteklemez, bu da XSS saldırılarının nasıl test edileceğini etkiler.
- **WebChromeClient**, tam Chrome tarayıcı deneyimine daha çok benzer.
Önemli bir nokta, WebView tarayıcılarının cihazın ana tarayıcısıyla **çerez paylaşmamasıdır**.
İçerik yüklemek için `loadUrl`, `loadData` ve `loadDataWithBaseURL` gibi yöntemler mevcuttur. Bu URL'lerin veya dosyaların **kullanım için güvenli** olduğundan emin olmak kritik öneme sahiptir. Güvenlik ayarları `WebSettings` sınıfı aracılığıyla yönetilebilir. Örneğin, `setJavaScriptEnabled(false)` ile JavaScript'in devre dışı bırakılması, XSS saldırılarını önleyebilir.
JavaScript "Bridge", Java nesnelerinin JavaScript ile etkileşimde bulunmasına olanak tanır ve Android 4.2'den itibaren güvenlik için yöntemlerin `@JavascriptInterface` ile işaretlenmesi gerekmektedir.
İçerik erişimine izin vermek (`setAllowContentAccess(true)`), WebView'ların Content Providers'a ulaşmasına olanak tanır; bu, içerik URL'leri güvenli olarak doğrulanmadıkça bir risk oluşturabilir.
Dosya erişimini kontrol etmek için:
- Dosya erişimini devre dışı bırakmak (`setAllowFileAccess(false)`), dosya sistemine erişimi sınırlar; belirli varlıklar için istisnalarla, yalnızca hassas olmayan içerikler için kullanılmasını sağlar.
## Diğer Uygulama Bileşenleri ve Mobil Cihaz Yönetimi
### **Uygulamaların Dijital İmzalanması**
- **Dijital imzalama**, Android uygulamaları için zorunludur ve uygulamaların yüklemeden önce **gerçekten yazıldığı** garantisini sağlar. Bu süreç, uygulama kimliği için bir sertifika kullanır ve yükleme sırasında cihazın paket yöneticisi tarafından doğrulanmalıdır. Uygulamalar **kendinden imzalı veya harici bir CA tarafından sertifikalandırılmış** olabilir, yetkisiz erişime karşı koruma sağlar ve uygulamanın cihaza teslimatı sırasında değiştirilmediğini garanti eder.
### **Geliştirilmiş Güvenlik için Uygulama Doğrulaması**
- **Android 4.2**'den itibaren, **Uygulamaları Doğrula** adlı bir özellik, kullanıcıların yüklemeden önce uygulamaların güvenliğini kontrol etmelerine olanak tanır. Bu **doğrulama süreci**, kullanıcıları potansiyel olarak zararlı uygulamalar hakkında uyarabilir veya özellikle kötü niyetli olanların yüklenmesini engelleyebilir, kullanıcı güvenliğini artırır.
### **Mobil Cihaz Yönetimi (MDM)**
- **MDM çözümleri**, **Cihaz Yönetimi API'si** aracılığıyla mobil cihazlar için **denetim ve güvenlik** sağlar. Mobil cihazları etkili bir şekilde yönetmek ve güvence altına almak için bir Android uygulamasının yüklenmesini gerektirir. Ana işlevler arasında **şifre politikalarının uygulanması**, **depolama şifrelemesinin zorunlu kılınması** ve **uzaktan veri silme izni verme** bulunur; bu da mobil cihazlar üzerinde kapsamlı kontrol ve güvenlik sağlar.
```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);
}
```
{{#include ../../banners/hacktricks-training.md}}