Android Uygulamaları Temelleri

Reading time: 16 minutes

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).

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.

<activity android:name=".MyActivity" android:exported="false">
<!-- Intent filters go here -->
</activity>

İkincil Niyetler

Niyetler, bir Niyet yapıcısı kullanılarak programatik olarak oluşturulur:

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:

<activity android:name="ShareActivity">
<intent-filter>
<action android:name="android.intent.action.SEND" />
<category android:name="android.intent.category.DEFAULT" />
</intent-filter>
</activity>

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, intent-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:

Intent downloadIntent = new (this, DownloadService.class):

Diğer uygulamalarda daha önce tanımlanan niyete erişmek için şunu kullanabilirsiniz:

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:

[...]
<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>
[...]

Önceki örnekteki şema examplescheme:// (aynı zamanda category BROWSABLE'ı da not edin)

Daha sonra, veri alanında host ve path belirtebilirsiniz:

<data android:scheme="examplescheme"
android:host="example"
/>

Bir web üzerinden erişmek için şu şekilde bir bağlantı ayarlamak mümkündür:

<a href="examplescheme://example/something">click here</a>
<a href="examplescheme://example/javascript://%250dalert(1)">click here</a>

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.

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 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:

<activity android:name=".LauncherActivity">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>

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:

<service android:name=".ExampleExportedService" android:exported="true"/>

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.

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 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:

<service android:name=".ExampleExportedService" android:exported="true"/>

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:

<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>

Ve filepaths.xml dosyasında paylaşılan klasörleri belirtmenin bir örneği:

<paths>
<files-path path="images/" name="myimages" />
</paths>

Daha fazla bilgi için kontrol edin:

• Android Developers: Content Providers
• Android Developers: FileProvider

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.

// 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);
}