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

Android Uygulamaları Temelleri

{% hint style="success" %} AWS Hacking'i öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking'i öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE)

HackTricks'i Destekleyin

• abonelik planlarını kontrol edin!
• Bize katılın 💬 Discord grubuna veya telegram grubuna veya Twitter'da bizi takip edin 🐦 @hacktricks_live.
• Hacking ipuçlarını paylaşmak için HackTricks ve HackTricks Cloud github reposuna PR gönderin.

{% endhint %}

Android Güvenlik Modeli

İki katman vardır:

• OS, kurulu uygulamaları birbirinden izole tutar.
• uygulamanın kendisi, geliştiricilerin belirli işlevleri 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ış 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 uygulamanın ayrı bir kullanıcı kimliği altında ayrı bir işlem olarak çalışması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şimleri yalnızca izin vermek için politikalar oluşturdu.

İzinler

Bir uygulama yüklediğinizde 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ı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 koruma seviyesi. 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şim sağladığını 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
• Hücresel 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 genellikle cihaz ve sürüm için özgüdür.
İstismar çalıştığında, genellikle Linux su ikili dosyası, kullanıcının PATH ortam değişkeninde belirtilen bir konuma kopyalanır, örneğin /system/xbin.

Su ikili dosyası yapılandırıldıktan sonra, su ikili dosyası ile etkileşimde bulunmak ve root erişim taleplerini işlemek için başka bir Android uygulaması kullanılır, örneğin Superuser ve SuperSU (Google Play mağazasında mevcuttur).

{% hint style="danger" %} Rootlama işleminin çok tehlikeli olduğunu ve cihazı ciddi şekilde zarar verebileceğini unutmayın. {% endhint %}

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.

Cihazı rootlamanın her zaman gerekli olmadığını unutmayın; 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 talep edebilir. 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, potansiyel olarak ek yerel kütüphaneler veya DEX dosyaları içerebilir; bazen kötü amaçlı yazılım yazarları tarafından ek kodu gizlemek için kullanılır.
• 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) devralıyor.

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 çalışı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; 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 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 tutmak için açıkça ayarlama imkanı vardır; bu, exported özniteliğini false olarak ayarlayarak sağlanır.

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:"));

The Action of the previously declared intent is ACTION_SEND and the Extra is a mailto Uri (the Extra if the extra information the intent is expecting).

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ç, intent-filter bildiriminde ayarlanabilen öncelik niteliğini dikkate alır 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 çatışma ortaya çıkarsa, kullanıcının karar verebilmesi için bir "seçici" 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 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 izin verir, uygulamanızın kimliğini 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 intent'in bunu çağırabileceğini belirtmiyorsa) kötü niyetli bir uygulama, belirtilen eylemi mağdur uygulama adına 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 intent'lerin aksine, yalnızca bir uygulama tarafından alınan, broadcast intent'ler birden fazla uygulama tarafından alınabilir. Ancak, API sürüm 14'ten itibaren, mesajı alması gereken uygulamayı belirtmek mümkündür Intent.setPackage kullanarak.

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 düşürebilir.

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 asla çı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.
Bunlar API seviyesi 21'de kullanımdan kaldırıldı ve kullanılmamaları önerilir.
Herhangi bir uygulamanın verileri dinlemesine, aynı zamanda bunları değiştirmesine izin verir.

"sticky" kelimesini içeren fonksiyonlar bulursanız, örneğin sendStickyBroadcast veya sendStickyBroadcastAsUser, etkisini kontrol edin ve 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 exampleapp:// (aynı zamanda category BROWSABLE'ı da not edin)

Ardından, veri alanında host ve path belirtebilirsiniz:

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

Web'den 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, deeplink ile ç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 işlem arası iletişim (IPC) yoluyla istemci ve hizmet arasındaki iletişimi kolaylaştırmak 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şal ederek 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 kullanarak, aktivitelerin veya bileşenlerin bir hizmete bağlanmasını, isteklerde bulunmasını ve yanıt almasını sağlar. 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 metodunu kullanarak 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ındır, ancak 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 ana kapısıdır ve uygulamanın simgesine dokunduğunuzda başlatılır. Uygulamanın manifest dosyasında belirli MAIN ve LAUNCHER intentleri 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 kısmı 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 yapılardır. Bu görevler, kullanıcılar farklı uygulamalara geçse bile çalışmaya devam edebilir, bu da servisleri uzun süreli işlemler için kritik hale getirir.

Servisler ç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 servis 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 servisin rolü aktif bir istemci bağlantısına bağlıysa, istemciyi servise bağlamak için bindService yöntemi kullanılır ve veri geçişi için onBind yöntemi devreye girer.

Servislerin 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, servisler 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 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 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 atlayabilir.

Content Provider

Content Providers, 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. Uygulamalara veritabanları, dosya sistemleri veya web gibi çeşitli kaynaklardan verilere erişim sağlar. 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, 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 Content Provider'dır. Erişimi kontrol etmek için belirli niteliklerle uygulamanın manifestinde tanımlanır ve klasör yapılandırmalarını gösteren android:exported ve android:resource ile belirtilir. Duyarlı 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>

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 ç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, JavaScript'i setJavaScriptEnabled(false) ile devre dışı bırakmak, 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 gerekir.

İçerik erişimine izin vermek (setAllowContentAccess(true)), WebView'ların İç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, bunların 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, 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.

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ı uygulamak, depolama şifrelemesini zorunlu kılmak ve uzaktan veri silme izni vermek 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);
}

{% hint style="success" %} AWS Hacking'i öğrenin ve pratik yapın:HackTricks Eğitim AWS Kırmızı Takım Uzmanı (ARTE)
GCP Hacking'i öğrenin ve pratik yapın: HackTricks Eğitim GCP Kırmızı Takım Uzmanı (GRTE)

HackTricks'i Destekleyin

• abonelik planlarını kontrol edin!
• Bize katılın 💬 Discord grubuna veya telegram grubuna veya bizi Twitter'da 🐦 @hacktricks_live** takip edin.**
• Hacking ipuçlarını paylaşarak HackTricks ve HackTricks Cloud github reposuna PR gönderin.

{% endhint %}