Android Uygulamaları Temelleri

Reading time: 20 minutes

Android Güvenlik Modeli

İki katman vardır:

• OS, kurulu 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 kurulumu 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ış tavsiye edilmez.
Aynı UID'yi paylaşmak için, uygulamalar manifestolarında aynı android:sharedUserId değerini tanımlamalıdır.

Sandbox

Android Uygulama Sandbox'ı, her uygulamayı ayrı bir kullanıcı kimliği altında ayrı bir işlem olarak çalıştırmaya 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şimleri yalnızca izin veren politikalar oluşturdu.

İzinler

Bir uygulama kurduğunuzda ve izinler istiyorsa, 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ının başlangıçta tüm izinleri istemesi gerekmediğini, dinamik olarak da izin isteyebileceğini unutmayın, 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ı
• İzin grubu özniteliği, ilgili izinleri gruplamak için kullanılır.
• İzinlerin nasıl verildiğini belirten protection-level. Dört tür vardır:
• Normal: Uygulama için bilinen tehditler 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
• Cep telefonu 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 başarılı olduktan sonra, 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 mevcut) gibi uygulamalardır.

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ı uzatmak, 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.

Özel bir yazılım yüklemek için cihazı rootlamak her zaman gerekli değildir. Bazı üreticiler, bootloader'larının iyi belgelenmiş ve güvenli bir şekilde kilidini açılmasına izin verir.

Sonuçlar

Bir cihaz rootlandığında, herhangi bir uygulama root olarak erişim isteyebilir. 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: ikili XML gibi önceden derlenmiş kaynakları 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) devralmaktadır.

Tersine mühendislik için, Smali kritik hale gelir. 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 olmak gerekirse, Niyet şu amaçlarla kullanılabilir:

• Bir Aktivite başlatmak için, genellikle bir uygulama için bir kullanıcı arayüzü açar
• Sistemi ve uygulamaları değişiklikler hakkında bilgilendirmek için yayınlar olarak
• Arka planda bir hizmet başlatmak, durdurmak ve onunla iletişim kurmak için
• ContentProviders aracılığıyla verilere erişmek için
• 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 bunları kodlamak da bir seçenektir.

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 tutarak, diğer uygulamalarla istemeden etkileşimde bulunmamalarını sağlamak için açık bir yol vardır. Bu, manifest tanımlarında exported özniteliğini false olarak ayarlayarak 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, kimlerin 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 intentin Eylemi ACTION_SEND ve Ek bir mailto Uri'dir (Ek, intentin 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 verebilmesi için bir "chooser" penceresi açılı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 intent'e 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 beyan edilen intent Açık Değilse (hangi intentin bunu çağırabileceğini belirtmiyorsa) kötü niyetli bir uygulama, mağdur uygulama adına beyan edilen 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ınanlar, broadcast intents 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ıralama, 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 bile gerek kalmaz.

Sticky Broadcasts

Bu tür Yayınlar gönderildikten uzun süre sonra erişilebilir.
Bunlar API seviye 21'de kullanımdan kaldırıldı ve kullanılmamaları önerilmektedir.
Herhangi bir uygulamanın verileri dinlemesine, aynı zamanda da 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ı beyan edilerek 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 beyan edilmelidir:

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

Web'den erişmek için 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 süreci basitleştirir ve 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'nin 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 uygulamanın birçok aktivitesi olabilir ve her biri kullanıcıya benzersiz bir ekran sunar.

Başlatıcı aktivite, bir uygulamanın ana kapısıdır ve uygulamanın simgesine dokunduğunuzda başlatılır. 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, manifestte "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. Endişe, hassas verilerin yanlış bir şekilde paylaşılması durumunda 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 birimlerdir. 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ı bir uygulamanın giriş noktası olarak başlatmanın birincil yöntemidir. Bir hizmet startService yöntemi kullanılarak 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 Alıcıları

Broadcast alıcıları, bir mesajlaşma sisteminde dinleyici olarak işlev görür ve birden fazla uygulamanın sistemden gelen aynı mesajlara yanıt vermesine olanak tanır. Bir uygulama, iki ana yolla bir alıcı kaydedebilir: uygulamanın Manifest dosyası aracılığıyla veya uygulamanın 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 ve uygulamanın buna göre tepki vermesini sağlar; örneğin, düşük pil uyarısına yanıt olarak davranışını ayarlamak gibi.

Yayınlar ya asenkron olabilir, tüm alıcılara sırasız ulaşır, ya da 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, Intent'i değiştirebilir veya düşürebilir.

İçerik Sağlayıcı

İçerik Sağlayıcılar, uygulamalar arasında yapılandırılmış verilerin paylaşımı için gereklidir 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 verilere 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; path, pathPrefix ve pathPattern gibi nitelikler detaylı erişim kontrolü için kullanılır.

Girdi doğrulaması, SQL enjeksiyonu gibi güvenlik açıklarını önlemek için son derece önemlidir. İçerik Sağlayıcılar, veri manipülasyonu ve uygulamalar arasında paylaşımı kolaylaştıran temel işlemleri destekler: insert(), update(), delete() ve query().

FileProvider, dosyaları güvenli bir şekilde paylaşmaya odaklanan özel bir İçerik Sağlayıcı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. Duyarlı verilerin yanlışlıkla ifşa edilmesini önlemek için dizinleri paylaşırken dikkatli olunması önerilir.

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>

For further information check:

• Android Developers: Content Providers
• Android Developers: FileProvider

WebViews

WebViews, Android uygulamaları içinde mini web tarayıcıları gibidir, içerikleri ya webden ya da yerel dosyalardan çeker. Normal tarayıcılarla benzer risklerle karşılaşırlar, ancak belirli ayarlar ile 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 yakın bir şekilde çalışır.

Ö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'lerin İçerik Sağlayıcılarına ulaşmasına olanak tanır, bu da 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.

Other App Components and Mobile Device Management

Digital Signing of Applications

• Dijital imza, 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 cihazın teslimatı sırasında değiştirilmeden kalmasını garanti eder.

App Verification for Enhanced Security

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

Mobile Device Management (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);
}

AIDL / Binder Servislerini Belirleme ve Sömürme

Android Binder IPC, birçok sistem ve satıcı tarafından sağlanan hizmet sunar. Bu hizmetler, uygun bir izin kontrolü olmadan dışa aktarıldıklarında bir saldırı yüzeyi haline gelir (AIDL katmanı kendisi hiç erişim kontrolü yapmaz).

1. Çalışan hizmetleri keşfetme

# from an adb shell (USB or wireless)
service list               # simple one-liner
am list services           # identical output, ActivityManager wrapper

1. Android uygulamaları, Java veya Kotlin gibi dillerde yazılmıştır.
2. Uygulamalar, Android SDK kullanılarak geliştirilir.
3. APK dosyaları, uygulamanın dağıtım formatıdır.
4. AndroidManifest.xml, uygulamanın yapılandırma dosyasıdır.
5. Uygulama bileşenleri, Activity, Service, Broadcast Receiver ve Content Provider'dan oluşur.
6. Uygulama verileri, SQLite veritabanları veya Shared Preferences ile saklanır.
7. Uygulama güvenliği, kod obfuscation ve güvenlik testleri ile artırılabilir.

145  mtkconnmetrics: [com.mediatek.net.connectivity.IMtkIpConnectivityMetrics]
146  wifi             : [android.net.wifi.IWifiManager]

• index (ilk sütun) çalışma zamanında atanır – yeniden başlatmalar arasında buna güvenmeyin.
• Binder adı (örneğin mtkconnmetrics), service call'a geçirilecek olandır.
• Parantez içindeki değer, stub'un oluşturulduğu tam nitelikli AIDL arayüzü'dür.

2. Arayüz tanımlayıcısını elde et (PING)

Her Binder stub'u otomatik olarak işlem kodu 0x5f4e5446 (1598968902 ondalık, ASCII "_NTF")'yi uygular.

# "ping" the service
service call mtkconnmetrics 1    # 1 == decimal 1598968902 mod 2^32

Geçerli bir yanıt, bir Parcel içinde UTF-16 dizesi olarak kodlanmış arayüz adını döndürür.

3. Bir işlemi çağırma

Sözdizimi: service call <name> <code> [type value ...]

Yaygın argüman belirteçleri:

• i32 <int> – işaretli 32-bit değer
• i64 <long> – işaretli 64-bit değer
• s16 <string> – UTF-16 dizesi (Android 13+ utf16 kullanır)

Örnek – bir MediaTek el cihazında uid 1 ile ağ izlemeyi başlatın:

service call mtkconnmetrics 8 i32 1

4. Bilinmeyen yöntemleri brute-force ile denemek

Header dosyaları mevcut değilse, hatanın şu şekilde değişene kadar kodu yineleyebilirsiniz:

Result: Parcel(00000000 00000000)  # "Not a data message"

normal bir Parcel yanıtı veya SecurityException.

for i in $(seq 1 50); do
printf "[+] %2d -> " $i
service call mtkconnmetrics $i 2>/dev/null | head -1
done

Eğer hizmet proguard ile derlenmişse, eşlemenin tahmin edilmesi gerekir – bir sonraki adıma bakın.

5. Mapping kodları ↔ yöntemler onTransact() aracılığıyla

Arayüzü uygulayan jar/odex dosyasını decompile edin (AOSP stub'ları için /system/framework'e bakın; OEM'ler genellikle /system_ext veya /vendor kullanır). Stub.onTransact() için arama yapın – bu, devasa bir switch(transactionCode) içerir:

case TRANSACTION_updateCtaAppStatus:      // 5
data.enforceInterface(DESCRIPTOR);
int appId  = data.readInt();
boolean ok = data.readInt() != 0;
updateCtaAppStatus(appId, ok);
reply.writeNoException();
return true;

Artık prototip ve parametre türleri tamamen net.

6. Eksik izin kontrollerini tespit etme

Uygulama (genellikle bir iç Impl sınıfı) yetkilendirmeden sorumludur:

private void updateCtaAppStatus(int uid, boolean status) {
if (!isPermissionAllowed()) {
throw new SecurityException("uid " + uid + " rejected");
}
/* privileged code */
}

Böyle bir mantığın veya ayrıcalıklı UID'lerin (örneğin uid == 1000 /*system*/) beyaz listesinin yokluğu bir zayıflık göstergesidir.

Vaka çalışması – MediaTek startMonitorProcessWithUid() (işlem 8) herhangi bir izin kapısı olmadan bir Netlink mesajını tamamen yürütür, bu da ayrıcalıksız bir uygulamanın çekirdek Netfilter modülü ile etkileşimde bulunmasına ve sistem günlüğünü spam yapmasına olanak tanır.

7. Değerlendirmeyi otomatikleştirme

Binder keşfini hızlandıran araçlar / betikler:

• binderfs – hizmet başına düğümlerle /dev/binderfs'yi açar
• binder-scanner.py – binder tablosunu dolaşır ve ACL'leri yazdırır
• Frida kısayolu: Java.perform(()=>console.log(android.os.ServiceManager.listServices().toArray()))

Referanslar

• Android Services 101 – Pentest Partners
• Android Developer Docs – AIDL
• Android Developer Docs – IBinder
• Understanding Binder, Talk @ Google