60 saniyede Android App Links
Android App Links gerçek bir güvenlik problemini çözer: işletim sisteminin bir HTTPS alan adı ile cihaza yüklenmiş bir uygulamanın birbirine ait olduğunu doğrulamasını sağlar. Bu durum, ikinci bir kötü niyetli uygulamanın aynı web bağlantısını normal doğrulanmış bağlantı işleme mantığı altında sessizce sahiplenmesini engeller.
Ancak birçok güvenlik değerlendirmesinin çok erken durduğu nokta da tam olarak burasıdır.
Bir verified (doğrulandı) sonucu, yalnızca URL’yi hangi uygulamanın aldığını kanıtlar. URL’nin güvenli olduğunu, açılan ekranın mevcut oturumdaki kullanıcı için uygun olduğunu veya durumu değiştiren (state-changing) bir işlemin sunucu tarafında yetkilendirildiğini kanıtlamaz. Bağlantı doğru uygulamaya ulaşıp yine de yanlış bir eylemi tetikleyebilir.
Bu saha notu, bu kritik ayrımı test etmek için tekrarlanabilir bir metodoloji sunar. Hedef, yüzeysel yapılandırma zayıflığı ile kanıtlanmış güvenlik etkisini birbirinden ayırt etmektir.
Tek bir URL dört bağımsız karardan geçer
“Deep-link güvenliği”ni tek bir kontrolden ibaret görmek asıl başarısızlık modellerini gizler. Anlamlı bir güvenlik değerlendirmesi dört bağımsız kararı birbirinden ayırır:
- İlişkilendirme (Association): Bu alan adının bu imzalı uygulamayı açmasına izin var mı? (
assetlinks.json) - Rota Ayrıştırma (Parsing): Uygulama yalnızca amaçlanan scheme, host, path ve parametreleri mi kabul ediyor?
- Uygulama Durumu (App State): Kullanıcı oturum açmış mı, beklenen hesapta mı ve bu rota için yetkili mi?
- Sunucu Yetkilendirmesi (Authorization): Sunucu, hedeflenen nesne üzerindeki okuma veya yazma işlemini bu kullanıcı için onaylıyor mu?
Bu ayrım hem test metodolojisini hem de raporlamayı değiştirir: Eksik bir assetlinks.json ilişkilendirmesi araya girme (interception) riski yaratabilir; ancak tek başına hesap ele geçirmeyi kanıtlamaz. Buna karşılık, kusursuz doğrulanmış bir alan adının tehlikeli bir action parametresini doğrudan çalıştırması, platform konfigürasyonu mükemmel olsa dahi çok daha kritik bir zafiyettir.
Doğrulama kasten dar kapsamlı bir soruyu yanıtlar
Bir Android App Link, AndroidManifest.xml dosyasında android:autoVerify="true" ile tanımlanan bir HTTP/HTTPS deep link’tir. Android işletim sistemi https://<host>/.well-known/assetlinks.json dosyasını çeker ve paket adı ile sertifika parmak izini yüklü uygulamayla karşılaştırır. Eşleşme sağlandığında sistem eşleşen linkleri doğrudan o uygulamaya yönlendirir.
Bu süreç yalnızca alan adı ile uygulama arasındaki mülkiyeti doğrular. /transfer/confirm rotasının iş mantığını incelemez, gelen accountId değerinin oturum açmış kullanıcıya ait olup olmadığını denetlemez ya da bir ödemeyi onaylamaz. Bunlar App Links’in eksikliği değil, mimarinin farklı katmanlarına ait kararlardır.
myapp:// gibi özel URL şemaları (custom schemes) ise tamamen farklı bir sınıftır. Digital Asset Links ile bir web alan adına bağlı olmadıkları için, cihaza yüklenen başka herhangi bir uygulama aynı şemayı bildirebilir. Düşük riskli navigasyon için kabul edilebilir olsa da, asla doğrulanmış bir HTTPS linkinin güvenlik varsayımlarını devralamaz.
Bu nedenle ilk sızma testi sorusu “link açılıyor mu” olmamalıdır:
Gözlemlenen davranış gerçekte hangi iddiayı kanıtlıyor?
pm get-app-links cihazın mevcut ilişkilendirme durumunu kanıtlar. Uygulamada bir ekranın belirmesi yönlendirmenin çalıştığını kanıtlar. Ancak yetkilendirilmiş ya da yetkisiz bir eylemi kanıtlamak için mutlaka sunucu yanıtı ve öncesi/sonrası durumu içeren somut kanıtlar gerekir.
Payload göndermeden önce rota sözleşmesini (Route Contract) çıkarın
Bir URL’deki her karakteri körü körüne değiştirmek yalnızca gürültü üretir. Kabul edilen her bağlantı için rota sözleşmesini belgeleyerek başlayın:
| Özellik | Yanıtlanacak soru |
|---|---|
| Giriş türü | Doğrulanmış HTTPS App Link mi, doğrulanmamış web linki mi, custom scheme mi? |
| Karşılayıcı (Receiver) | Hangi exported activity veya navigation router karşılıyor? |
| Rota grameri | Hangi path’ler mevcut ve path segmentleri kaç kez decode ediliyor? |
| Parametreler | Hangi parametreler nesne, hesap, hedef, URL veya eylem seçiyor? |
| Ön koşullar | Kullanıcının oturum açmış olması veya belirli bir hesapta bulunması şart mı? |
| Yan etki (Side effect) | Link açıldığında yalnızca gezinme mi yapıyor, veri mi ifşa ediyor, eylem mi tetikliyor? |
| Sunucu kararı | Hangi API endpoint’i mülkiyeti, rolü, oturumu ve replay durumunu yeniden denetliyor? |
| Hata davranışı | Geçersiz girdide güvenle duruyor mu, yoksa varsayılan yetkilerle devam mı ediyor? |
next, target, destination ve continue parametrelerinin tümü aynı yeteneği temsil ediyor olabilir: yürütmenin bir sonraki adımda nereye gideceğini belirlemek. Parametre isimlerine değil, neyi kontrol ettiklerine odaklanın.
Ayrılması gereken temel hata kalıpları
1. Linkin başka bir uygulama tarafından sahiplenilmesi (Collision)
Custom scheme’lerde ve doğrulanmamış web linklerinde ikinci bir zararlı uygulama aynı rotayı kaydedebilir ve tek kullanımlık bir login token’ını çalabilir.
2. Geçerli bir linkin komut diline dönüşmesi
Link bir gezinme bağlantısı olarak başlar ve zamanla parametre biriktirir:
https://mobile.example.test/open?screen=account&account_id=LAB-002&action=confirm
Serbest formdaki girdi ayrıcalıklı ekranları, durum değiştiren işlemleri veya rastgele hedefleri katı bir beyaz liste (allowlist) olmadan seçebiliyorsa zafiyet vardır.
3. Public handler’ın iç içe (nested) Intent yönlendirmesi
Bazı router’lar gelen Intent’in extra alanından başka bir Intent nesnesi çıkarır ve doğrudan startActivity() ile başlatır. Bu durum, dışarıya açık olmayan (exported=false) özel bileşenlerin saldırgan tarafından tetiklenmesine yol açan tipik bir Intent Redirection zafiyetidir.
Evidence matrix
| Sinyal | Neyi kanıtlar | Negatif kontrol | Savunmacı doğrulaması |
|---|---|---|---|
pm get-app-links verified dönüyor | Alan adı ile uygulama sertifikasının eşleştiğini | Geçersiz bir alan adı deneyip doğrulanmadığını görün | assetlinks.json içeriğini ve HTTPS yanıt başlıklarını denetleyin |
| İkinci bir uygulamanın aynı şemayı yakalaması | Şemanın korunmadığını ve çakışma riskini | Aynı cihazda doğrulanmış bir App Link ile kıyaslayın | Hassas akışları custom scheme yerine doğrulanmış App Links’e taşıyın |
| Link üzerinden oturum açıkken doğrudan işlem yapılması | Mobil istemcinin ek bir onay veya sunucu denetimi aramadığını | Oturumu kapatıp linki tekrar açın; akış durmalıdır | Durum değiştiren eylemler için sunucuda re-auth ve CSRF token zorunlu kılın |
| Exported activity’nin harici Intent’i iç bileşene iletmesi | Intent redirection ve bileşen yetki sızıntısını | Yetkisiz bir hedef bileşen adı gönderip reddedildiğini görün | Gelen Intent’in component adını, flags ve action değerlerini allowlist’ten geçirin |
Sonuç
Android App Links mükemmel bir kimlik ve yönlendirme katmanıdır; ancak bir güvenlik doğrulama duvarı değildir. Linkin doğrulanmış olması eylemin onaylandığı anlamına gelmez. Mobil mimaride her derin bağlantı; alan adı sahipliği, güvenli rota ayrıştırma, uygulama oturum durumu ve sunucu seviyesinde yetkilendirme olmak üzere dört bağımsız süzgeçten geçmek zorundadır.
Bu teknik not ne kadar güncel?
En son kaynak incelemesi, içerik güncellemesi veya yayın tarihi gösterilmektedir.
Yazar teknik incelemeyi tamamladı. Bu etiket tek başına laboratuvar yeniden üretimi iddiası taşımaz.