Mobil Uygulamalarda Token, Deep Link ve API Güven Sınırları

Kısa cevap

Mobil uygulamada temel soru paketin gizli olup olmadığı değil, saldırgan cihazı ve client’ı kontrol ettiğinde backend’in hangi işlemleri hâlâ yetkilendirdiğidir. Token saklama, uygulamaya gelen deep link’ler, WebView ve cihaz sinyalleri incelenmeli; her hassas kararın sunucuda tekrar doğrulandığı kanıtlanmalıdır.

Bu rehber genel mobil pentest kapsamını yinelemez. Üç sınıra odaklanır: cihazdaki kimlik bilgileri, uygulamaya gelen bağlantılar ve client’ın API’ye taşıdığı yetki. Bu sınırlar bankacılık, fintech, e-ticaret ve kurumsal uygulamalarda hesap ele geçirme ya da işlem suistimaline yol açabilir.

Token nerede saklanıyor?

Access ve refresh token’larının hangi depoda ve erişim kontrolüyle tutulduğunu belirleyin. Android Keystore veya iOS Keychain kullanımı tek başına yeterli değildir. Yedekleme, debug logu, crash raporu, clipboard, ekran görüntüsü ve üçüncü taraf SDK’ları kontrol edin. Şifreli depolama, anahtar aynı uygulamayla çıkarılabiliyorsa güvence sağlamaz.

Kontrollü test cihazında uygulama dosyalarını, yedekleri, logları, IPC’yi ve runtime davranışını inceleyin. Root/jailbreak tespitini mutlak güvenlik kontrolü saymayın. Asıl soru hangi token’ın hangi koşulda açığa çıktığı ve bunun sunucu tarafında hangi yetkiyi sağladığıdır.

Logout, parola değişimi, MFA sıfırlama, cihaz kaldırma ve hesabın askıya alınması sonrası token’ı izleyin. Yalnızca yerel token’ı silen logout, kopyalanmış refresh token’ı geçersiz kılmayabilir. Hassas işlem öncesi backend’in güncel oturum durumunu kontrol ettiğini doğrulayın.

Deep link güvenilmeyen girdi taşır

Custom URL scheme birden fazla uygulama tarafından kaydedilebilir. Callback veya hassas aksiyon bu scheme’e bağlıysa başka uygulamanın aynı adı sahiplenebildiği senaryoyu test edin. Android App Links ve iOS Universal Links doğrulanmış alan adı bağları sağlar; parametre doğrulama ihtiyacını ortadan kaldırmaz.

redirect, next, account, code, sipariş ID’si ve kampanya alanlarını güvenilmeyen girdi olarak ele alın. Linki açmak para transferi, parola değişimi veya MFA kaldırma işlemini tamamlamamalıdır. Hassas aksiyon sunucu yetkilendirmesi ve kullanıcı onayı gerektirir.

Login callback’inde state ve uygun akışlarda PKCE, uygulama kapanıp açılsa da aynı işlemi bağlamalıdır. Hata halinde token URL, analitik olayı ya da kullanıcıya görünen hata metninde kalmamalıdır.

Client kontrolü backend yetkisi değildir

Buton gizleme, rol ekranını kapatma veya biyometrik prompt API erişim kontrolü değildir. Sunucu kullanıcı kimliğini, nesne sahipliğini, tenant üyeliğini ve güncel iş kuralını doğrulamalıdır. Güvenli test hesabıyla client kontrolleri atlanmış isteğin API’de reddedildiğini gösterin.

Cihaz parmak izi, root durumu veya uygulama bütünlüğü sinyali risk kararına katkı sağlayabilir; kalıcı tek yetki kanıtı olmamalıdır. Sinyal servisi çalışmadığında uygulama ya ek doğrulama istemeli ya da hassas işlemi sınırlamalıdır; filtresiz izin vermemelidir.

Test sırası

1. Android/iOS sürümlerini ve login, ödeme, kurtarma akışlarını belirleyin.
2. Test hesabında token depolama, yedek, log ve logout davranışını inceleyin.
3. Deep link’leri bozuk, süresi geçmiş, tekrar kullanılan ve başka hesaba ait parametrelerle deneyin.
4. Client kontrolü atlayıp API isteğini gönderin; server-side reddi doğrulayın.
5. Biyometri, cihaz değişimi, root sinyali, ağ kesintisi ve uygulama restart’ını değerlendirin.
6. Raporu sürüm, cihaz, rol, etkilenen işlem ve retest koşuluyla tamamlayın.

Cihaz sinyalini ve kullanıcı onayını doğru konumlandırın

Biyometri genellikle cihazda saklanan bir anahtara erişim açar; backend’in kullanıcının kimliğini ve işlem yetkisini yeniden kontrol etmesinin yerini almaz. Özellikle transfer, yeni alıcı ekleme veya güvenlik ayarı değiştirme gibi işlemlerde uygulamanın biyometri başarısızlığında daha zayıf bir fallback’e düşüp düşmediğini test edin. Oturumun yeniden açılması, başka cihazdan gelen deep link ve bildirimden başlatılan aksiyon da aynı iş kuralını kullanmalıdır.

Bildirim içeriğinde hassas veri veya tek başına yetki veren link token’ı bulunmamalıdır. Ekran kilitliyken görünen içerik, uygulama arka plana geçince alınan snapshot ve ekran paylaşımı gibi durumları test kapsamına alın. Uygulama hassas ekranda ekran görüntüsünü kısıtlıyorsa bunun erişilebilirlik ve platform davranışlarıyla tutarlı çalıştığını doğrulayın; bu kontrol de backend yetkilendirmesinin alternatifi değildir.

Bulguyu tekrar üretilebilir raporlayın

Rapor; uygulama sürümü, OS sürümü, cihaz durumu, kullanılan test rolü, başlangıç oturumu ve etkilenen API/işlem adımlarını belirtmelidir. Token değerlerini redakte edin. Mümkün olduğunda hassas gerçek veri yerine sentetik hesap kullanın. Düzeltme sonrası aynı akışla retest yapın ve negatif kontrol ekleyin: normal link, normal login ve yetkili işlem çalışmaya devam ederken saldırgan varyantı reddedilmelidir.

Bir deep link bulgusunun şiddeti linkin açılabilmesine göre belirlenmez; hangi kullanıcı bağlamında hangi hassas aksiyonu tetiklediğiyle belirlenir. Yalnızca zararsız bir ekranı açan route ile session’ı başka uygulamaya taşıyan auth callback aynı etkiye sahip değildir.

Platforma özgü kontroller

Android tarafında exported activity ve intent filter’ların hangi uygulamalardan çağrılabildiğini; iOS tarafında universal link association dosyasının doğru domain ve path’leri kapsadığını gözden geçirin. Link parser’ın aynı parametrenin birden çok kez gelmesi, boş değer, farklı encoding veya beklenmeyen Unicode içeren varyantlarda nasıl davrandığını test edin. Platformun linki doğru uygulamaya açması, uygulama içindeki hedef ekranın parametreyi güvenle işlediği anlamına gelmez. Bu nedenle her route için beklenen parametre tipini, izinli hedefleri ve hassas aksiyon öncesi gereken oturum seviyesini yazılı hale getirin.

Mobil ve API sahiplik kontrollerini birlikte incelemek için mobil uygulama güvenliği hizmetimize bakabilirsiniz.