Güvenlik kontrol listesi

Android'de, uygulama güvenliği sorunlarının sıklığını ve etkisini önemli ölçüde azaltan yerleşik güvenlik özellikleri vardır. Sistem, genellikle uygulamalarınızı varsayılan sistem ve dosya izinleriyle derleyebilmeniz ve güvenlikle ilgili zor kararlar almaktan kaçınabilmeniz için tasarlanmıştır.

Aşağıdaki temel güvenlik özellikleri, güvenli uygulamalar geliştirmenize yardımcı olur:

  • Uygulama verilerinizi ve kod yürütme işleminizi diğer uygulamalardan izole eden Android uygulama korumalı alanı.
  • Kriptografi, izinler ve güvenli işlemler arası iletişim (IPC) gibi yaygın güvenlik işlevlerinin güçlü bir şekilde uygulandığı bir uygulama çerçevesi.
  • Sık karşılaşılan bellek yönetimi hatalarıyla ilgili riskleri azaltmak için adres alanı düzeni rastgeleleştirme (ASLR), no-execute (NX), ProPolice, safe_iop, OpenBSD dlmalloc ve calloc ile Linux mmap_min_addr gibi teknolojiler.
  • Sistem özelliklerine ve kullanıcı verilerine erişimi kısıtlamak için kullanıcı tarafından verilen izinler.
  • Uygulama verilerini uygulama bazında kontrol etmek için uygulama tanımlı izinler.

Bu sayfada yer alan Android güvenlikle ilgili en iyi uygulamalar hakkında bilgi sahibi olmanız önemlidir. Bu uygulamaları genel kodlama alışkanlıkları olarak uygulamak, kullanıcılarınızı olumsuz yönde etkileyen güvenlik sorunlarını yanlışlıkla ortaya çıkarmaktan kaçınmanıza yardımcı olur.

Kimlik doğrulama

Kimlik doğrulama, birçok önemli güvenlik işlemi için ön koşuldur. Kullanıcı verileri, uygulama işlevleri ve diğer kaynaklar gibi korunan öğelere erişimi kontrol etmek için Android uygulamanıza kimlik doğrulama eklemeniz gerekir.

Uygulamanızı Kimlik Bilgisi Yöneticisi ile entegre ederek kullanıcılarınızın kimlik doğrulama deneyimini iyileştirebilirsiniz. Kimlik Bilgisi Yöneticisi, geçiş anahtarları, şifreler ve Google ile oturum aç gibi birleşik oturum açma çözümleri dahil olmak üzere en önemli kimlik doğrulama yöntemleri için API desteğini birleştiren bir Android Jetpack kitaplığıdır.

Uygulamanızın güvenliğini daha da artırmak için parmak izi taramaları veya yüz tanıma gibi biyometrik kimlik doğrulama yöntemleri ekleyebilirsiniz. Biyometrik kimlik doğrulamayı eklemek için iyi adaylar arasında finans, sağlık veya kimlik yönetimi uygulamaları yer alabilir.

Android'in otomatik doldurma çerçevesi, kayıt ve oturum açma sürecini kolaylaştırarak hata oranlarını ve kullanıcı sorunlarını azaltabilir. Otomatik doldurma, şifre yöneticileriyle entegre olarak kullanıcıların kolayca ve güvenli bir şekilde depolanıp alınabilecek karmaşık, rastgele şifreler seçmesine olanak tanır.

Uygulama bütünlüğü

Play Integrity API, etkileşimlerin ve sunucu isteklerinin orijinal Android cihazda çalışan orijinal uygulama ikili programınızdan gelip gelmediğini kontrol etmenize yardımcı olur. Uygulamanızın arka uç sunucusu, değiştirilmiş uygulama sürümlerinden ve güvenilmeyen ortamlardan gelenler gibi riskli olabilecek sahte etkileşimleri tespit ederek saldırıları önlemek ve kötüye kullanımı azaltmak için uygun işlemleri gerçekleştirerek gereken yanıtı verebilir.

Veri depolama

Android'deki uygulamalar için en yaygın güvenlik sorunu, cihaza kaydettiğiniz verilerin diğer uygulamaların erişimine açık olup olmamasıdır. Cihaza veri kaydetmenin başlıca üç yolu vardır:

  • Dahili depolama
  • Harici depolama
  • İçerik sağlayıcılar

Aşağıdaki bölümlerde her yaklaşımla ilişkili güvenlik sorunları açıklanmaktadır.

Dahili depolama

Dahili depolama alanında oluşturduğunuz dosyalara varsayılan olarak yalnızca uygulamanız erişebilir. Android bu korumayı uygular ve bu koruma çoğu uygulama için yeterlidir.

Desteği sonlandırılan MODE_WORLD_WRITEABLE ve MODE_WORLD_READABLE modlarını IPC dosyaları için kullanmayın. Bu modlar belirli uygulamalara veri erişimini sınırlandırmanıza olanak tanımaz ve veri biçimi konusunda kontrolü size vermez. Verilerinizi diğer uygulama süreçleriyle paylaşmak istiyorsanız bunun yerine diğer uygulamalara okuma ve yazma izinleri sunan ve duruma göre dinamik izinler verebilecek bir içerik sağlayıcı kullanmayı düşünebilirsiniz.

Harici depolama

SD kartlar gibi harici depolama alanında oluşturulan dosyalar herkes tarafından okunabilir ve yazılabilir. Harici depolama alanı kullanıcı tarafından kaldırılabileceği ve herhangi bir uygulama tarafından değiştirilebileceği için harici depolama alanında yalnızca hassas olmayan bilgileri saklayın.

Harici depolama alanındaki verileri güvenilmeyen bir kaynaktan gelen verilerle yaptığınız gibi işlerken giriş doğrulaması yapın. Yürütülebilir dosyaları veya sınıf dosyalarını dinamik yüklemeden önce harici depolamaya kaydetmeyin. Uygulamanız harici depolama alanından yürütülebilir dosya alıyorsa dosyaların dinamik yüklemeden önce imzalandığından ve kriptografik olarak doğrulandığından emin olun.

İçerik sağlayıcılar

İçerik sağlayıcılar, kendi uygulamanızla sınırlı tutulabilen veya diğer uygulamaların erişmesine izin vermek için dışa aktarılabilen yapılandırılmış bir depolama mekanizması sunar. Diğer uygulamalara ContentProvider erişimi sağlamak istemiyorsanız uygulama manifest dosyasında android:exported=false olarak işaretleyin. Aksi takdirde, diğer uygulamaların depolanan verilere erişmesine izin vermek için android:exported özelliğini true olarak ayarlayın.

Diğer uygulamalar tarafından kullanılmak üzere dışa aktarılan bir ContentProvider oluştururken okuma ve yazma için tek bir izin belirtebilir veya okuma ve yazma için farklı izinler belirtebilirsiniz. İzinlerinizi, söz konusu görevi tamamlamak için gerekenlerle sınırlandırın. Yeni işlevleri kullanıma sunmak için izinleri daha sonra eklemenin, mevcut kullanıcıları etkileyecek şekilde izinleri kaldırmaktan genellikle daha kolay olduğunu unutmayın.

Yalnızca kendi uygulamalarınız arasında veri paylaşmak için içerik sağlayıcı kullanıyorsanız android:protectionLevel özelliğini signature koruma olarak ayarlamanızı öneririz. İmza izinleri kullanıcı onayı gerektirmez. Bu nedenle, verilere erişen uygulamalar aynı anahtarla imzalandığında daha iyi bir kullanıcı deneyimi ve içerik sağlayıcı verilerine daha kontrollü erişim sağlar.

İçerik sağlayıcılar, android:grantUriPermissions özelliğini tanımlayarak ve bileşeni etkinleştiren Intent nesnesinde FLAG_GRANT_READ_URI_PERMISSION ve FLAG_GRANT_WRITE_URI_PERMISSION işaretlerini kullanarak daha ayrıntılı erişim de sağlayabilir. Bu izinlerin kapsamı, <grant-uri-permission> öğesiyle daha da sınırlanabilir.

Güvenilir olmayan kaynaklardan olası SQL yerleştirme işlemlerini önlemek için bir içerik sağlayıcıya erişirken query, update ve delete() gibi parametrelendirilmiş sorgu yöntemlerini kullanın. selection bağımsız değişkeni, yönteme gönderilmeden önce kullanıcı verileri birleştirilerek oluşturuluyorsa parametreli yöntemlerin kullanılmasının yeterli olmadığını unutmayın.

Yazma izni konusunda kendinizi güvende hissetmeyin. Yazma izni, bazı verilerin reklam öğesi WHERE yan tümceleri kullanılarak ve sonuçların ayrıştırılmasıyla doğrulanmasını sağlayan SQL ifadelerine olanak tanır. Örneğin, bir saldırgan yalnızca belirli bir telefon numarası zaten mevcutsa bir satırı değiştirerek arama günlüğünde belirli bir telefon numarasının bulunup bulunmadığını araştırabilir. İçerik sağlayıcı verilerinin yapısı tahmin edilebilirse yazma izni, hem okuma hem de yazma izni vermeye eşdeğer olabilir.

İzinler

Android, uygulamaları birbirinden korumalı alana aldığından uygulamaların kaynakları ve verileri açıkça paylaşması gerekir. Bunu, temel korumalı alan tarafından sağlanmayan ek özellikler için ihtiyaç duydukları izinleri (ör. kamera gibi cihaz özelliklerine erişim) açıklayarak yaparlar.

İzin istekleri

Uygulamanızın istediği izinlerin sayısını en aza indirin. Hassas izinlere erişimin kısıtlanması bu izinlerin kazara hatalı bir şekilde kullanılması riskini azaltır, kullanıcıların uygulamayı daha fazla benimsemesini sağlar ve uygulamanızı saldırganlara karşı daha güvenli hale getirir. Genel olarak, uygulamanızın çalışması için gerekli olmayan izinleri istemeyin. Uygulamanızın izin beyan etmesi gerekip gerekmediğini değerlendirme konulu kılavuzu inceleyin.

Mümkünse uygulamanızı herhangi bir izin gerektirmeyecek şekilde tasarlayın. Örneğin, benzersiz bir tanımlayıcı oluşturmak için cihaz bilgilerine erişim isteğinde bulunmak yerine uygulamanız için bir UUID oluşturun. (Kullanıcı verileri hakkındaki bölümde daha fazla bilgi edinin.) Alternatif olarak, harici depolama alanı kullanmak yerine (izin gerektirir) verileri dahili depolama alanında saklayın.

Uygulamanız, izin istemenin yanı sıra güvenlik açısından hassas olan ve ContentProvider gibi diğer uygulamalara maruz kalan IPC'yi korumak için <permission> öğesini kullanabilir. Genel olarak, izinler kullanıcılar için kafa karıştırıcı olabileceğinden mümkün olduğunda kullanıcı onaylı izinler dışında erişim denetimleri kullanmanızı öneririz. Örneğin, tek bir geliştirici tarafından sağlanan uygulamalar arasında IPC iletişimi için izinlerde imza koruma düzeyini kullanabilirsiniz.

İzin korumalı verileri sızdırmayın. Bu durum, uygulamanız IPC üzerinden yalnızca uygulamanızın bu verilere erişme iznine sahip olması nedeniyle kullanılabilen verileri gösterdiğinde ortaya çıkar. Uygulamanızın IPC arayüzünün istemcileri aynı veri erişimi iznine sahip olmayabilir. Bu sorunun sıklığı ve olası etkileri hakkında daha fazla bilgiyi USENIX'te yayınlanan Permission Re-Delegation: Attacks and Defenses (İzin Yeniden Yetkilendirmesi: Saldırılar ve Savunmalar) adlı araştırma makalesinde bulabilirsiniz.

İzin tanımları

Güvenlik gereksinimlerinizi karşılayan en küçük izin grubunu tanımlayın. Sistem tarafından tanımlanan izinler birçok durumu kapsadığından, çoğu uygulamada yeni izin oluşturma işlemi nispeten nadirdir. Uygun durumlarda, mevcut izinleri kullanarak erişim kontrolleri yapın.

Yeni bir izne ihtiyacınız varsa görevinizi imza koruma düzeyiyle tamamlayıp tamamlayamayacağınızı düşünün. İmza izinleri kullanıcı için şeffaftır ve yalnızca izin kontrolünü gerçekleştiren uygulamayla aynı geliştirici tarafından imzalanan uygulamaların erişmesine izin verir.

Yeni bir izin oluşturmanız gerekiyorsa <permission> öğesini kullanarak uygulama manifestinde beyan edin. Yeni izni kullanan uygulamalar, manifest dosyalarına <uses-permission> öğesi ekleyerek bu izne referans verebilir. addPermission() yöntemini kullanarak izinleri dinamik olarak da ekleyebilirsiniz.

Tehlikeli koruma düzeyine sahip bir izin oluşturursanız dikkate almanız gereken bazı karmaşıklıklar vardır:

  • İzinde, kullanıcıya vermesi gereken güvenlik kararını kısaca ifade eden bir dize bulunmalıdır.
  • İzin dizesi birçok farklı dile yerelleştirilmelidir.
  • Kullanıcılar, izinler kafa karıştırıcı olduğu veya riskli olarak algılandığı için bir uygulamayı yüklememeyi tercih edebilir.
  • Uygulamalar, izni veren uygulama yüklenmemişken izin isteğinde bulunabilir.

Bunların her biri, geliştirici olarak teknik olmayan önemli bir zorluk teşkil ederken kullanıcılarınızın kafasını da karıştırır. Bu nedenle, tehlikeli izin düzeyinin kullanımını önermiyoruz.

Ağ Ürünleri

Ağ işlemleri, kullanıcıya özel verilerin iletimini içerdiğinden güvenlik açısından doğal olarak risklidir. Kullanıcılar, mobil cihazlarla ilgili gizlilik sorunları konusunda gittikçe daha bilinçli hale geliyor. Özellikle de cihazlar ağ işlemleri gerçekleştirirken bu sorunlar öne çıkıyor. Bu yüzden uygulamanızın, kullanıcı verilerini her zaman güvende tutmaya yönelik en iyi uygulamaları eksiksiz bir şekilde hayata geçirmesi çok önemlidir.

IP ağı

Android'de ağ oluşturma, diğer Linux ortamlarından önemli ölçüde farklı değildir. En önemli nokta, hassas veriler için uygun protokollerin (ör. güvenli web trafiği için HttpsURLConnection) kullanılmasını sağlamaktır. Mobil cihazlar genellikle herkese açık kablosuz hotspot'lar gibi güvenli olmayan ağlara bağlandığından, sunucuda HTTPS'nin desteklendiği her yerde HTTP yerine HTTPS kullanın.

Kimlik doğrulanmış, şifrelenmiş soket düzeyinde iletişim, SSLSocket sınıfı kullanılarak kolayca uygulanabilir. Android cihazların kablosuz ağları kullanarak güvenli olmayan kablosuz ağlara bağlanma sıklığı göz önüne alındığında, ağ üzerinden iletişim kuran tüm uygulamalar için güvenli ağ bağlantısı kullanılması önemle tavsiye edilir.

Bazı uygulamalar, hassas IPC'yi işlemek için localhost ağ bağlantı noktalarını kullanır. Bu arayüzlere cihazdaki diğer uygulamalar tarafından erişilebildiği için bu yaklaşımı kullanmayın. Bunun yerine, kimlik doğrulamanın mümkün olduğu bir Android IPC mekanizması (ör. Service) kullanın. Belirli olmayan INADDR_ANY IP adresine bağlama, uygulamanızın herhangi bir IP adresinden istek almasına izin verdiği için geri bağlama kullanmaktan daha kötüdür.

HTTP veya diğer güvenli olmayan protokollerden indirilen verilere güvenmediğinizden emin olun. Buna, WebView içindeki girişlerin doğrulanması ve HTTP'ye karşı gönderilen intent yanıtları da dahildir.

Telefon ağ iletişimi

Short Message Service (SMS) protokolü, temel olarak kullanıcılar arası iletişim için tasarlanmıştır ve veri aktarmak isteyen uygulamalar için uygun değildir. SMS'nin sınırlamaları nedeniyle, bir web sunucusundan kullanıcı cihazındaki uygulamanıza veri mesajları göndermek için Firebase Cloud Messaging'i (FCM) ve IP ağını kullanmanızı öneririz.

SMS'lerin ağda veya cihazda şifrelenmediğini ya da güçlü bir şekilde kimlik doğrulamasının yapılmadığını unutmayın. Özellikle SMS alıcıları, SMS'yi kötü amaçlı bir kullanıcının uygulamanıza göndermiş olabileceğini göz önünde bulundurmalıdır. Hassas komutları gerçekleştirmek için kimliği doğrulanmamış SMS verilerine güvenmeyin. Ayrıca, SMS'lerin ağda kimliğe bürünme ve/veya müdahaleye tabi olabileceğini unutmayın. Android işletim sistemli cihazda SMS mesajları yayın intent'leri olarak iletilir. Bu sayede, READ_SMS iznine sahip diğer uygulamalar tarafından okunabilir veya yakalanabilir.

Giriş doğrulaması

Yetersiz giriş doğrulaması, çalıştırıldığı platformdan bağımsız olarak uygulamaları etkileyen en yaygın güvenlik sorunlarından biridir. Android, uygulamaların giriş doğrulama sorunlarına maruz kalmasını azaltan platform düzeyinde karşı önlemlere sahiptir. Mümkün olduğunda bu özellikleri kullanmanızı öneririz. Ayrıca, giriş doğrulama sorunlarının olasılığını azaltmak için tür açısından güvenli diller kullanmanızı öneririz.

Yerel kod kullanıyorsanız dosyalardan okunan, ağ üzerinden alınan veya bir IPC'den alınan tüm veriler güvenlik sorunu oluşturabilir. En yaygın sorunlar arabellek taşmaları, serbest bırakıldıktan sonra kullanma ve birlik hataları'dır. Android, ASLR ve Veri Yürütme Önleme (DEP) gibi bu hataların istismar edilebilirliğini azaltan çeşitli teknolojiler sunar ancak bu teknolojiler temel sorunu çözmez. İşaretçileri dikkatli bir şekilde kullanarak ve arabellekleri yöneterek bu güvenlik açıklarını önleyebilirsiniz.

JavaScript ve SQL gibi dinamik, dize tabanlı diller de kaçış karakterleri ve komut dosyası ekleme nedeniyle giriş doğrulama sorunlarına tabidir.

SQL veritabanına veya içerik sağlayıcıya gönderilen sorgularda veri kullanıyorsanız SQL yerleştirme sorunuyla karşılaşabilirsiniz. En iyi savunma, içerik sağlayıcılar bölümünde açıklandığı gibi parametreli sorgular kullanmaktır. İzinleri salt okuma veya salt yazma olarak sınırlamak, SQL yerleştirmeyle ilgili zarar olasılığını da azaltabilir.

Bu bölümde açıklanan güvenlik özelliklerini kullanamıyorsanız iyi yapılandırılmış veri biçimleri kullandığınızdan emin olun ve verilerin beklenen biçime uygun olduğunu doğrulayın. Belirli karakterleri engellemek veya karakter değiştirmek etkili bir strateji olabilir ancak bu teknikler uygulamada hatalara yol açabileceğinden mümkün olduğunda bu tekniklerden kaçınmanızı öneririz.

Kullanıcı verileri

Kullanıcı verilerinin güvenliği için en iyi yaklaşım, hassas veya kişisel bilgilere erişen API'lerin kullanımını en aza indirmektir. Kullanıcı verilerine erişiminiz varsa mümkünse bunları saklamayın veya iletmeyin. Uygulama mantığının karma değer oluşturarak uygulanıp uygulanamayacağını değerlendirin. Örneğin, uygulamanız, bir e-posta adresini iletmemek veya saklamamak için birincil anahtar olarak o e-posta adresinin karma değerini kullanabilir. Böylece verilerin yanlışlıkla açığa çıkması ve saldırganların uygulamanızı kötüye kullanması ihtimali azalır.

Gizli verilere erişim gerektiğinde kullanıcınızın kimliğini doğrulayın ve geçiş anahtarları ve Kimlik Bilgisi Yöneticisi gibi modern kimlik doğrulama yöntemlerini kullanın. Uygulamanızın kişisel bilgilere erişmesi gerekiyorsa bazı yargı alanlarında bu verileri kullanma ve saklama şeklinizi açıklayan bir gizlilik politikası sağlamanız gerekebileceğini unutmayın. Uygunluğu basitleştirmek için kullanıcı verilerine erişimi en aza indirmeyle ilgili güvenlikle ilgili en iyi uygulamayı uygulayın.

Ayrıca, uygulamanızın kişisel bilgileri reklamcılık için üçüncü taraf bileşenleri veya uygulamanız tarafından kullanılan üçüncü taraf hizmetleri gibi diğer taraflara yanlışlıkla ifşa edip edemeyeceğini de göz önünde bulundurun. Bir bileşenin veya hizmetin neden kişisel bilgi gerektirdiğini bilmiyorsanız bu bilgileri vermeyin. Genel olarak, uygulamanızın kişisel bilgilere erişimini azaltmak bu alandaki sorun olasılığını azaltır.

Uygulamanız hassas verilere erişim gerektiriyorsa verileri bir sunucuya aktarmanız gerekip gerekmediğini veya işlemi istemcide çalıştırıp çalıştıramayacağınızı değerlendirin. Kullanıcı verilerinin aktarılmasını önlemek için hassas verileri kullanan tüm kodları istemcide çalıştırabilirsiniz. Ayrıca, aşırı izin verici IPC, herkese açık yazılabilir dosyalar veya ağ soketlerini kullanarak kullanıcı verilerini cihazdaki diğer uygulamalara yanlışlıkla göstermediğinizden emin olun. Aşırı izin verici IPC, izin korumalı verilerin sızmasına yol açan özel bir durumdur ve İzin istekleri bölümünde ele alınmıştır.

Küresel olarak benzersiz tanımlayıcı (GUID) gerekiyorsa büyük ve benzersiz bir sayı oluşturup saklayın. Telefon numarası veya IMEI gibi kişisel bilgilerle ilişkilendirilebilecek telefon tanımlayıcılarını kullanmayın. Bu konu, benzersiz tanımlayıcılar için en iyi uygulamalar başlıklı sayfada daha ayrıntılı olarak ele alınmıştır.

Cihaz üzerindeki günlüklere yazarken dikkatli olun. Android'de günlükler paylaşılan bir kaynaktır ve READ_LOGS iznine sahip uygulamalar tarafından kullanılabilir. Telefon günlüğü verileri geçicidir ve yeniden başlatıldığında silinir. Ancak kullanıcı bilgilerinin uygunsuz şekilde günlüğe kaydedilmesi, kullanıcı verilerinin yanlışlıkla diğer uygulamalara sızmasına neden olabilir. Kimliği tanımlayabilecek bilgileri (PII) günlüğe kaydetmemenin yanı sıra, üretim uygulamalarında günlük kullanımını sınırlayın. Bu özelliği kolayca uygulamak için kolayca yapılandırılabilir günlük kaydı düzeylerine sahip hata ayıklama işaretleri ve özel Log sınıfları kullanın.

Web Görünümü

WebView, HTML ve JavaScript içerebilecek web içeriğini kullandığından, hatalı kullanım siteler arası kod dizimi (JavaScript ekleme) gibi yaygın web güvenliği sorunlarına neden olabilir. Android, WebView'ün kapasitesini uygulamanızın gerektirdiği minimum işlevle sınırlayarak bu potansiyel sorunların kapsamını azaltmak için çeşitli mekanizmalar içerir.

Uygulamanız bir WebView içinde doğrudan JavaScript kullanmıyorsa setJavaScriptEnabled işlevini çağırmayın. Bazı örnek kodlarda bu yöntem kullanılır. Bu yöntemi kullanan örnek kodu bir üretim uygulamasında yeniden kullanırsanız gerekli değilse bu yöntem çağrısını kaldırın. Varsayılan olarak WebView JavaScript'i yürütmez. Bu nedenle siteler arası komut dizisi kullanılamaz.

JavaScript'in normalde Android uygulamaları için ayrılmış işlemleri çağırmasına olanak tanıdığı için addJavaScriptInterface() değerini özellikle dikkatli bir şekilde kullanın. Bu özelliği kullanıyorsanız addJavaScriptInterface()'ü yalnızca tüm girişlerinin güvenilir olduğu web sayfalarına gösterin. Güvenilir olmayan girişlere izin verilirse güvenilir olmayan JavaScript, uygulamanızda Android yöntemlerini çağırabilir. Genel olarak, addJavaScriptInterface()'ü yalnızca uygulama APK'nızdaki JavaScript'e göstermenizi öneririz.

Uygulamanız WebView ile hassas verilere erişiyorsa yerel olarak depolanan dosyaları silmek için clearCache() yöntemini kullanabilirsiniz. Bir uygulamanın belirli içeriği önbelleğe almaması gerektiğini belirtmek için no-store gibi sunucu tarafı üstbilgilerini de kullanabilirsiniz.

Android 4.4'ten (API düzeyi 19) eski platformları çalıştıran cihazlar, webkit'in çeşitli güvenlik sorunları olan bir sürümünü kullanır. Uygulamanız bu cihazlarda çalışıyorsa geçici bir çözüm olarak WebView nesnelerinin yalnızca güvenilir içerik gösterdiğini onaylamalıdır. Uygulamanızın SSL'deki olası güvenlik açıklarına maruz kalmadığından emin olmak için SSL suistimallerine karşı koruma için güvenlik sağlayıcınızı güncelleme başlıklı makalede açıklandığı gibi güncellenebilir güvenlik Provider nesnesini kullanın. Uygulamanızın açık web'den içerik oluşturması gerekiyorsa en son güvenlik yamalarını kullanarak güncel tutabilmek için kendi oluşturma aracınızı sağlamanız önerilir.

Kimlik bilgisi istekleri

Kimlik bilgisi istekleri saldırı vektörüdür. Android uygulamalarınızdaki kimlik bilgisi isteklerini daha güvenli hale getirmenize yardımcı olacak bazı ipuçlarını aşağıda bulabilirsiniz.

Kimlik bilgilerinin ifşa edilmesini en aza indirme

  • Gereksiz kimlik bilgisi isteklerinden kaçının. Kimlik avı saldırılarını daha kolay anlaşılır hale getirerek başarıya ulaşma şansını azaltmak için kullanıcı kimlik bilgilerinin istenme sıklığını en aza indirin. Bunun yerine, yenilenebilir bir yetkilendirme jetonu kullanın. Yalnızca kimlik doğrulama ve yetkilendirme için gereken minimum düzeyde kimlik bilgisi isteyin.
  • Kimlik bilgilerini güvenli bir şekilde saklayın. Geçiş anahtarları kullanarak şifresiz kimlik doğrulamayı etkinleştirmek veya Google ile oturum açma gibi şemalar kullanarak birleşik oturum açmayı uygulamak için Kimlik Bilgisi Yöneticisi'ni kullanın. Geleneksel şifre kimlik doğrulamasını kullanmanız gerekiyorsa kullanıcı kimliklerini ve şifrelerini cihazda saklamayın. Bunun yerine, başta kullanıcının sağladığı kullanıcı adı ve şifreyle kimlik doğrulama yaptıktan sonra kısa ömürlü ve hizmete özgü bir yetkilendirme jetonu kullanın.
  • İzinlerin kapsamını sınırlayın. Yalnızca daha dar bir kapsam gerektiren bir görev için geniş izinler istemeyin.
  • Erişim jetonlarını sınırlayın. Kısa süreli jeton işlemleri ve API çağrıları kullanın.
  • Kimlik doğrulama oranlarını sınırlayın. Hızlı ve art arda gelen kimlik doğrulama veya yetkilendirme istekleri, kaba kuvvet saldırısının işareti olabilir. İşlevsel ve kullanıcı dostu bir uygulama deneyimi sunmaya devam ederken bu oranları makul bir sıklıkta sınırlayın.

Güvenli kimlik doğrulama kullanın

  • Geçiş anahtarlarını uygulayın. Şifrelere daha güvenli ve kullanıcı dostu bir yükseltme olarak geçiş anahtarlarını etkinleştirin.
  • Biyometrik veriler ekleyin. Daha fazla güvenlik için parmak izi veya yüz tanıma gibi biyometrik kimlik doğrulama yöntemlerini kullanma olanağı sunun.
  • Birleştirilmiş kimlik sağlayıcıları kullanın. Kimlik Bilgisi Yöneticisi, Google ile oturum aç gibi birleşik kimlik doğrulama sağlayıcılarını destekler.
  • İletişimi şifreleyin Uygulamanızın bir ağ üzerinden gönderdiği verilerin korunmasını sağlamak için HTTPS ve benzer teknolojileri kullanın.

Güvenli hesap yönetimi yapma

  • AccountManager kullanarak birden fazla uygulamanın erişebildiği hizmetlere bağlanın. Bulut tabanlı bir hizmeti çağırmak için AccountManager sınıfını kullanın ve şifreleri cihazda saklamayın.
  • Account almak için AccountManager'ü kullandıktan sonra, kimlik bilgilerini yanlışlıkla yanlış uygulamaya göndermemek için kimlik bilgilerini göndermeden önce CREATOR'i kullanın.
  • Kimlik bilgileri yalnızca oluşturduğunuz uygulamalar tarafından kullanılıyorsa checkSignatures kullanarak AccountManager'e erişen uygulamayı doğrulayabilirsiniz. Alternatif olarak, kimlik bilgisini yalnızca bir uygulama kullanıyorsa depolama için KeyStore kullanabilirsiniz.

Tedbirli olun

  • Kodu güncel tutun. En son güvenlik açıklarına karşı korunmak için üçüncü taraf kitaplıkları ve bağımlılıklar da dahil olmak üzere kaynak kodunuzu güncellediğinizden emin olun.
  • Şüpheli etkinliği izleyin. Yetkilendirmenin kötüye kullanımıyla ilgili kalıplar gibi olası kötüye kullanımları arayın.
  • Kodu denetimden geçirin. Olası kimlik bilgisi isteği sorunlarını tespit etmek için kod tabanınızda düzenli olarak güvenlik kontrolleri yapın.

API anahtarı yönetimi

API anahtarları, birçok Android uygulamasının kritik bir bileşenidir. Bu anahtarlar, uygulamaların harita hizmetlerine, kimlik doğrulama hizmetlerine ve hava durumu hizmetlerine bağlanma gibi temel işlevleri gerçekleştirmesine ve harici hizmetlere erişmesine olanak tanır. Ancak bu hassas anahtarları açığa çıkarmak, veri ihlalleri, yetkisiz erişim ve mali kayıplar da dahil olmak üzere ciddi sonuçlar doğurabilir. Geliştiricilerin bu tür senaryoları önlemek için geliştirme süreci boyunca API anahtarlarını işlemek üzere güvenli stratejiler uygulaması gerekir.

Hizmetleri kötüye kullanıma karşı korumak için API anahtarlarının dikkatli bir şekilde korunması gerekir. Uygulama ile API anahtarı kullanan bir hizmet arasındaki bağlantıyı güvence altına almak için API'ye erişimi güvence altına almanız gerekir. Uygulamanız derlendiğinde ve uygulamanızın kaynak kodu API anahtarları içerdiğinde, saldırganların uygulamayı derlemeyi kaldırıp bu kaynakları bulması mümkündür.

Bu bölüm, sürekli yayınlama ardışık düzenlerinde altyapı ekipleriyle çalışan ve Play Store'da bağımsız uygulamalar dağıtan iki Android geliştirici grubuna yöneliktir. Bu bölümde, uygulamanızın hizmetlerle güvenli bir şekilde iletişim kurabilmesi için API anahtarlarının nasıl kullanılacağıyla ilgili en iyi uygulamalar açıklanmaktadır.

Oluşturma ve depolama

Geliştiriciler, API anahtarı depolamayı veri koruma ve kullanıcı gizliliğinin kritik bir bileşeni olarak ele almalı ve kapsamlı savunma yaklaşımı kullanmalıdır.

Güçlü anahtar depolama

En iyi anahtar yönetimi güvenliği için Android KeyStore'u kullanın ve depolanan anahtarları Tink Java gibi güçlü bir araç kullanarak şifreleyin.

Kaynak kontrolü hariç tutma

API anahtarlarını hiçbir zaman kaynak kodu deponuza kaydetmeyin. API anahtarlarını kaynak koda eklemek, anahtarların herkese açık depolara, paylaşılan kod örneklerine ve yanlışlıkla paylaşılan dosyalara maruz kalma riskini artırır. Bunun yerine, projenizde API anahtarlarıyla çalışmak için secrets-gradle-plugin gibi Gradle eklentilerini kullanın.

Ortamlara özgü anahtarlar

Mümkünse geliştirme, test ve üretim ortamları için ayrı API anahtarları kullanın. Her ortamı birbirinden ayırmak için ortama özgü anahtarlar kullanın. Böylece, üretim verilerinin açığa çıkma riskini azaltır ve üretim ortamınızı etkilemeden güvenliği ihlal edilmiş anahtarları devre dışı bırakabilirsiniz.

Kullanım ve erişim denetimi

API anahtarınızın güvenliğini sağlama uygulamaları, API'nizi ve kullanıcılarınızı korumak için çok önemlidir. Anahtarlarınızı optimum güvenlik için hazırlamak üzere aşağıdaki adımları uygulayın:

  • Her uygulama için benzersiz anahtarlar oluşturun: Güvenliği ihlal edilmiş erişimi tespit edip izole etmek için her uygulama için ayrı API anahtarları kullanın.
  • IP kısıtlamaları uygulayın: Mümkünse API anahtarı kullanımını belirli IP adresleriyle veya aralıklarla sınırlayın.
  • Mobil uygulama anahtarı kullanımını sınırlama: API anahtarını anahtarla paketleyerek veya uygulama sertifikalarını kullanarak belirli mobil uygulamalarla sınırlayın.
  • Şüpheli etkinlikleri günlüğe kaydedin ve izleyin: Şüpheli etkinlikleri tespit etmek ve olası kötüye kullanımları önlemek için API kullanımı günlük kaydı ve izleme mekanizmaları uygulayın.

Not: Hizmetiniz, anahtarları belirli bir paket veya platformla kısıtlamaya yönelik özellikler sağlamalıdır. Örneğin, Google Haritalar API'si, anahtar erişimini paket adına ve imzalama anahtarına göre sınırlar.

OAuth 2.0, kaynaklara erişimi yetkilendirmek için bir çerçeve sağlar. İstemcilerin ve sunucuların nasıl etkileşime geçmesi gerektiğine dair standartları tanımlar ve güvenli yetkilendirmeye olanak tanır. API anahtarı kullanımını belirli istemcilerle kısıtlamak için OAuth 2.0'ı kullanabilir ve erişim kapsamını, her API anahtarının yalnızca amaçlanan amacı için gereken minimum erişim düzeyine sahip olacak şekilde tanımlayabilirsiniz.

Anahtar rotasyonu ve geçerlilik süresi

Keşfedilmemiş API güvenlik açıkları üzerinden yetkisiz erişim riskini azaltmak için API anahtarlarını düzenli olarak değiştirmek önemlidir. ISO 27001 standardı, anahtar rotasyonunun ne sıklıkta yapılacağına dair bir uygunluk çerçevesi tanımlar. Çoğu durumda, 90 gün ile 6 ay arasında bir anahtar rotasyon süresi yeterlidir. Güçlü bir anahtar yönetimi sistemi uygulamak, bu süreçleri kolaylaştırarak anahtar rotasyonu ve geçerlilik süresi ihtiyaçlarınızın verimliliğini artırmanıza yardımcı olabilir.

Genel en iyi uygulamalar

  • SSL/HTTPS kullanın: API isteklerinizi şifrelemek için her zaman HTTPS iletişimini kullanın.
  • Sertifika sabitleme: Daha fazla güvenlik katmanı için hangi sertifikaların geçerli kabul edildiğini kontrol etmek üzere sertifika sabitleme özelliğini uygulayabilirsiniz.
  • Kullanıcı girişini doğrulayın ve temizleyin: API anahtarlarını açığa çıkarabilecek saldırıları önlemek için kullanıcı girişini doğrulayın ve temizleyin.
  • En iyi güvenlik uygulamalarını takip edin: Geliştirme sürecinize güvenli kodlama teknikleri, kod incelemeleri ve güvenlik açığı taraması gibi genel güvenlik en iyi uygulamalarını uygulayın.
  • Bilgi sahibi olun: API anahtar yönetimiyle ilgili en son güvenlik tehditleri ve en iyi uygulamalar hakkında bilgi edinin.
  • SDK'lar güncel: SDK'larınızın ve kitaplıklarınızın en son sürüme güncellendiğinden emin olun.

Kriptografi

Android, veri izolasyonu sağlamanın, tam dosya sistemi şifrelemeyi desteklemenin ve güvenli iletişim kanalları sağlamanın yanı sıra kriptografiyi kullanarak verileri korumak için çok çeşitli algoritmalar sunar.

Yazılımınızın hangi Java Cryptography Architecture (JCA) güvenlik sağlayıcılarını kullandığını öğrenin. Kullanım alanınızı destekleyebilecek, önceden mevcut olan çerçeve uygulamasını en yüksek düzeyde kullanmayı deneyin. Uygun durumlarda, Google tarafından sağlanan sağlayıcıları Google tarafından belirtilen sırayla kullanın.

Bilinen bir ağ konumundan bir dosyayı güvenli bir şekilde almanız gerekiyorsa basit bir HTTPS URI yeterli olabilir ve kriptografi bilgisi gerektirmez. Güvenli bir tünele ihtiyacınız varsa kendi protokolünüzü yazmak yerine HttpsURLConnection veya SSLSocket'i kullanmayı düşünün. SSLSocket kullanıyorsanız ana makine adı doğrulamasının yapılmadığını unutmayın. SSLSocket'u doğrudan kullanmayla ilgili uyarılar başlıklı makaleyi inceleyin.

Kendi protokolünüzü uygulamanız gerektiğini düşünüyorsanız kendi şifreleme algoritmalarınızı uygulamayın. Cipher sınıfında sağlanan AES ve RSA uygulamaları gibi mevcut kriptografik algoritmaları kullanın. Ayrıca şu en iyi uygulamaları da izleyin:

  • Ticari amaçlar için 256 bit AES kullanın. (Kullanılamıyorsa 128 bit AES kullanın.)
  • Eliptik eğri (EC) kriptografisi için 224 veya 256 bit ortak anahtar boyutlarını kullanın.
  • CBC, PBM veya GCM blok modlarını ne zaman kullanacağınızı bilin.
  • TO modunda IV/sayaç yeniden kullanımından kaçının. Bu değerlerin kriptografik olarak rastgele olduğundan emin olun.
  • Şifreleme kullanırken aşağıdaki işlevlerden biriyle CBC veya CTR modunu kullanarak bütünlüğü uygulayın:
    • HMAC-SHA1
    • HMAC-SHA-256
    • HMAC-SHA-512
    • GCM modu

KeyGenerator tarafından oluşturulan şifreleme anahtarlarını başlatmak için güvenli bir rastgele sayı oluşturucu (SecureRandom) kullanın. Güvenli bir rastgele sayı oluşturucu ile oluşturulmayan bir anahtarın kullanılması, algoritmanın gücünü önemli ölçüde zayıflatır ve çevrimdışı saldırılara izin verebilir.

Bir anahtarı tekrar tekrar kullanmanız gerekiyorsa KeyStore gibi, kriptografik anahtarların uzun süreli depolanması ve alınmasını sağlayan bir mekanizma kullanın.

İşlemler arası iletişim

Bazı uygulamalar, ağ soket ve paylaşılan dosya gibi geleneksel Linux tekniklerini kullanarak IPC'yi uygulamaya çalışır. Bunun yerine, IPC için Intent, Binder veya Messenger ile Service ve BroadcastReceiver gibi Android sistem işlevlerini kullanmanızı öneririz. Android IPC mekanizmaları, IPC'nize bağlanan uygulamanın kimliğini doğrulamanıza ve her IPC mekanizması için güvenlik politikası belirlemenize olanak tanır.

Güvenlik öğelerinin çoğu IPC mekanizmaları arasında paylaşılır. IPC mekanizmanız diğer uygulamalar tarafından kullanılmak üzere tasarlanmamışsa bileşenin manifest öğesinde android:exported özelliğini false olarak ayarlayın (ör. <service> öğesi için). Bu, aynı UID içinde birden fazla işlemden oluşan uygulamalar için veya geliştirmenin sonlarında işlevi IPC olarak göstermek istemediğinize karar verirseniz ancak kodu yeniden yazmak istemiyorsanız kullanışlıdır.

IPC'nize diğer uygulamalar erişebiliyorsa <permission> öğesini kullanarak bir güvenlik politikası uygulayabilirsiniz. IPC, size ait olan ve aynı anahtarla imzalanan uygulamalar arasındaysa android:protectionLevel içinde signature-level izni kullanın.

Amaçlar

Etkinlikler ve yayın alıcıları için Android'de asenkron IPC'de tercih edilen mekanizma intent'lerdir. Uygulama gereksinimlerinize bağlı olarak sendBroadcast, sendOrderedBroadcast veya belirli bir uygulama bileşenine yönelik açık bir intent kullanabilirsiniz. Güvenlik nedeniyle açık intent'ler tercih edilir.

Dikkat: **Service**'e bağlanmak için intent kullanıyorsanız uygulamanızın güvenliğini sağlamak amacıyla açık intent kullanın. Bir hizmeti başlatmak için örtülü intent kullanmak güvenlik açısından risklidir. Bunun nedeni, hangi hizmetin intent'e yanıt vereceğinden emin olamama ve kullanıcının hangi hizmetin başlatıldığını görememesinden kaynaklanır. Android 5.0 (API düzeyi 21) sürümünden itibaren, **bindService()** işlevini dolaylı bir intent ile çağırırsanız sistem bir istisna atar.

Sıralı yayınların bir alıcı tarafından kullanılabileceğini ve bu nedenle tüm uygulamalara yayınlanmayabileceğini unutmayın. Belirli bir alıcıya gönderilmesi gereken bir intent gönderiyorsanız alıcıyı adla açıklayan açık bir intent kullanmanız gerekir.

Intent gönderenler, yöntem çağrısında null olmayan bir izin belirterek alıcının izin sahibi olduğunu doğrulayabilir. Yalnızca bu izne sahip uygulamalar intent'i alır. Bir yayın intent'indeki veriler hassas olabilir. Kötü amaçlı uygulamaların, uygun izinler olmadan bu mesajları almaya kaydolmasını önlemek için izin uygulamayı düşünebilirsiniz. Bu gibi durumlarda, yayın başlatmak yerine alıcıyı doğrudan çağırmayı da düşünebilirsiniz.

Not: Intent filtreleri güvenlik özellikleri değildir. Bileşenler açık intent'lerle çağrılabilir ve intent filtresine uygun verilere sahip olmayabilir. Çağrılan alıcı, hizmet veya etkinlik için doğru şekilde biçimlendirildiğini onaylamak üzere intent alıcınızda giriş doğrulaması yapın.

Hizmetler

Service genellikle diğer uygulamaların kullanabileceği işlevler sağlamak için kullanılır. Her hizmet sınıfının manifest dosyasında ilgili bir <service> beyanı olmalıdır.

Hizmetler varsayılan olarak dışa aktarılmaz ve başka bir uygulama tarafından çağrılamaz. Ancak hizmet beyanına intent filtresi eklerseniz varsayılan olarak dışa aktarılır. İstediğiniz şekilde davrandığından emin olmak için android:exported özelliğini açıkça belirtmeniz önerilir. Hizmetler, android:permission özelliği kullanılarak da korunabilir. Bu şekilde, diğer uygulamaların hizmeti başlatmak, durdurmak veya hizmete bağlamak için kendi manifest dosyalarında ilgili bir <uses-permission> öğesi beyan etmesi gerekir.

Not: Uygulamanız Android 5.0 (API düzeyi 21) veya sonraki sürümleri hedefliyorsa arka plan hizmetlerini yürütmek için **JobScheduler** yöntemini kullanın.

Bir hizmet, kendisine yapılan IPC çağrılarını izinlerle koruyabilir. Bu işlem, çağrının uygulanması çalıştırılmadan önce checkCallingPermission() çağrılara başvurarak yapılır. Manifestte açıklayıcı izinleri kullanmanızı öneririz. Bu izinler gözden kaçma olasılığı daha düşüktür.

Dikkat: İstemci ve sunucu izinlerini birbirine karıştırmayın; çağrılan uygulamanın uygun izinlere sahip olduğundan emin olun ve arayan uygulamaya da aynı izinleri verdiğinizden emin olun.

Binder ve Messenger arayüzleri

Android'de RPC tarzı IPC için tercih edilen mekanizma Binder veya Messenger kullanmaktır. Gerekirse uç noktaların karşılıklı kimlik doğrulamasını sağlayan iyi tanımlanmış arayüzler sağlarlar.

Uygulama arayüzlerinizi, arayüze özgü izin kontrolleri gerektirmeyecek şekilde tasarlamanızı öneririz. Binder ve Messenger nesneleri uygulama manifestinde tanımlanmadığından doğrudan bunlara açıklayıcı izinler uygulayamazsınız. Bunlar genellikle, uygulandıkları Service veya Activity için uygulama manifestinde beyan edilen izinleri devralır. Kimlik doğrulama ve/veya erişim denetimleri gerektiren bir arayüz oluşturuyorsanız bu denetimleri Binder veya Messenger arayüzüne kod olarak açıkça eklemeniz gerekir.

Erişim denetimleri gerektiren bir arayüz sağlıyorsanız arayan kullanıcının gerekli izne sahip olup olmadığını doğrulamak için checkCallingPermission() öğesini kullanın. Bu, özellikle uygulamanızın kimliği diğer arayüzlere iletildiği için arayan adına bir hizmete erişmeden önce önemlidir. Bir Service tarafından sağlanan bir arayüzü çağırıyorsunuz. Belirtilen hizmete erişme izniniz yoksa bindService() çağrısı başarısız olabilir. Harici bir sürecin uygulamanızla etkileşime geçmesine izin vermeniz gerekiyorsa ancak bu işlem için gerekli izinlere sahip değilse clearCallingIdentity() yöntemini kullanabilirsiniz. Bu yöntem, uygulamanızın arayüzüne yapılan aramayı harici arayandan ziyade uygulamanız yapıyormuş gibi gerçekleştirir. Daha sonra restoreCallingIdentity() yöntemini kullanarak arayan izinlerini geri yükleyebilirsiniz.

Bir hizmetle IPC gerçekleştirme hakkında daha fazla bilgi için Bağlı Hizmetler başlıklı makaleyi inceleyin.

Yayın alıcıları

BroadcastReceiver, Intent tarafından başlatılan asenkron istekleri işler.

Alıcıları varsayılan olarak dışa aktarırsınız ve başka bir uygulama tarafından çağrılabilir. BroadcastReceiver'ünüz diğer uygulamalar tarafından kullanılmak üzere tasarlandıysa uygulama manifest'indeki <receiver> öğesini kullanarak alıcılara güvenlik izinleri uygulamak isteyebilirsiniz. Bu, uygun izinlere sahip olmayan uygulamaların BroadcastReceiver'e intent göndermesini engeller.

Dinamik olarak yüklenen kodla güvenlik

Uygulama APK'nızın dışından kod yüklemenizi kesinlikle önermeyiz. Bu, kod ekleme veya kodla oynama nedeniyle uygulama güvenliğinin ihlal edilme olasılığını önemli ölçüde artırır. Ayrıca sürüm yönetimi ve uygulama testi konusunda karmaşıklık ekler. Uygulamanın davranışını doğrulamayı imkansız hale getirebilir. Bu nedenle bazı ortamlarda yasaklanabilir.

Uygulamanız dinamik olarak kod yüklüyorsa dinamik olarak yüklenen kodun, uygulama APK'sıyla aynı güvenlik izinleriyle çalıştığını unutmayın. Kullanıcı, uygulamanızı yükleme kararını kimliğinize göre verir ve dinamik olarak yüklenen kod da dahil olmak üzere uygulama içinde çalıştırılan tüm kodları sağlamanızı bekler.

Birçok uygulama, şifrelenmemiş protokoller üzerinden ağdan indirilen veya harici depolama gibi herkese açık olarak yazılabilen konumlardan kod yüklemeye çalışır. Bu konumlar, ağdaki bir kullanıcının aktarma sırasındaki içeriği veya kullanıcının cihazındaki başka bir uygulamanın cihazdaki içeriği değiştirmesine izin verebilir. Öte yandan, doğrudan APK'nıza dahil edilen modüller diğer uygulamalar tarafından değiştirilemez. Bu durum, kodun doğal bir kitaplık veya DexClassLoader kullanılarak yüklenen bir sınıf olması fark etmeksizin geçerlidir.

Sanal makinelerde güvenlik

Dalvik, Android'in çalışma zamanı sanal makinesidir (VM). Dalvik, özellikle Android için tasarlanmıştır ancak diğer sanal makinelerdeki güvenli kodla ilgili endişelerin çoğu Android için de geçerlidir. Genel olarak, sanal makineyle ilgili güvenlik sorunlarıyla ilgilenmeniz gerekmez. Uygulamanız güvenli bir korumalı alan ortamında çalıştığından sistemdeki diğer işlemler kodunuza veya gizli verilerinize erişemez.

Sanal makine güvenliği hakkında daha fazla bilgi edinmek istiyorsanız konuyla ilgili mevcut literatürü inceleyin. En popüler kaynaklardan ikisi şunlardır:

Bu dokümanda, Android'e özgü veya diğer sanal makine ortamlarından farklı olan alanlara odaklanılmıştır. Diğer ortamlarda sanal makine programlama konusunda deneyimli geliştiriciler için Android için uygulama yazma konusunda farklı olabilecek iki genel konu vardır:

  • JVM veya .NET çalışma zamanı gibi bazı sanal makineler, kodu temel işletim sistemi özelliklerinden ayırarak güvenlik sınırı görevi görür. Android'de Dalvik sanal makinesi bir güvenlik sınırı değildir. Uygulama korumalı alanı işletim sistemi düzeyinde uygulanır. Bu nedenle Dalvik, herhangi bir güvenlik kısıtlaması olmadan aynı uygulamadaki yerel kodla birlikte çalışabilir.
  • Mobil cihazlardaki sınırlı depolama alanı göz önüne alındığında, geliştiricilerin modüler uygulamalar oluşturmak ve dinamik sınıf yükleme özelliğini kullanmak istemesi yaygın bir durumdur. Bunu yaparken hem uygulama mantığınızı aldığınız kaynağı hem de yerel olarak depoladığınız kaynağı göz önünde bulundurun. Bu kod, kötü amaçlı davranış içerecek şekilde değiştirilebileceğinden, güvenli olmayan ağ kaynakları veya harici depolama alanı gibi doğrulanmamış kaynaklardan dinamik sınıf yükleme işlemi kullanmayın.

Yerel kodda güvenlik

Genel olarak, uygulama geliştirme için Android NDK ile yerel kod kullanmak yerine Android SDK'sını kullanmanızı öneririz. Yerel kodla oluşturulan uygulamalar daha karmaşıktır, daha az taşınabilirdir ve arabellek taşması gibi yaygın bellek bozulması hatalarını içerme olasılığı daha yüksektir.

Android, Linux çekirdeği kullanılarak oluşturulur. Linux geliştirme güvenlik en iyi uygulamalarına aşina olmak, özellikle yerel kod kullanıyorsanız faydalıdır. Linux güvenlik uygulamaları bu dokümanın kapsamına girmiyor ancak en popüler kaynaklardan biri Secure Programming HOWTO - Creating Secure Software (Güvenli Programlama Kılavuzu - Güvenli Yazılım Oluşturma) başlıklı makaledir.

Android ile çoğu Linux ortamı arasındaki önemli bir fark, uygulama korumalı alanıdır. Android'de, yerel kodla yazılanlar da dahil olmak üzere tüm uygulamalar uygulama korumalı alanında çalışır. Linux'a aşina geliştiriciler için bu konuyu düşünmenin iyi bir yolu, her uygulamaya çok sınırlı izinlere sahip benzersiz bir kullanıcı tanımlayıcısı (UID) atandığını bilmektir. Bu konu Android Güvenliğine Genel Bakış bölümünde daha ayrıntılı olarak ele alınmıştır. Yerel kod kullanıyor olsanız bile uygulama izinleri hakkında bilgi sahibi olmanız gerekir.