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, uygulamalarınızı genellikle varsayılan sistem ve dosya izinleriyle oluşturabilmeniz ve güvenlik konusunda zor kararlar vermenizi önlemek 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ütmenizi diğer uygulamalardan izole eden Android uygulama korumalı alanı.
  • Kriptografi, izinler ve güvenli süreçler arası iletişim (IPC) gibi yaygın güvenlik işlevlerinin güçlü bir şekilde uygulandığı bir uygulama çerçevesi.
  • Adres alanı düzeni rastgeleleştirme (ASLR), no-execute (NX), ProPolice, safe_iop, OpenBSD dlmalloc ve calloc gibi teknolojiler ile Linux mmap_min_addr, yaygın bellek yönetimi hatalarıyla ilişkili riskleri azaltmak için kullanılır.
  • 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 uygulamaya tanımlı izinler.

Bu sayfadaki Android güvenliğiyle ilgili en iyi uygulamaları bilmeniz önemlidir. Bu uygulamaları genel kodlama alışkanlıkları olarak benimsemek, kullanıcılarınızı olumsuz etkileyen güvenlik sorunlarını istemeden ortaya çıkarmanızı önler.

Kimlik doğrulama

Kimlik doğrulama, birçok önemli güvenlik işlemi için ön koşuldur. Kullanıcı verileri, uygulama işlevselliği 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çma gibi federasyon oturum açma çözümleri de dahil olmak üzere çoğu büyük kimlik doğrulama yöntemi 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 tarama veya yüz tanıma gibi biyometrik kimlik doğrulama yöntemleri ekleyebilirsiniz. Biyometrik kimlik doğrulama eklemek için uygun adaylar arasında finans, sağlık hizmetleri 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 çalışır. Bu sayede kullanıcılar, kolay ve güvenli bir şekilde saklanıp alınabilen karmaşık ve rastgele şifreler seçebilir.

Uygulama bütünlüğü

Play Integrity API, etkileşimlerin ve sunucu isteklerinin orijinal bir Android cihazda çalışan orijinal uygulama ikili programınızdan gelip gelmediğini kontrol etmenizi sağlar. Uygulamanızın arka uç sunucusu, değiştirilmiş uygulama sürümleri 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 verilere diğer uygulamaların erişip erişememesidir. 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

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

IPC dosyaları için desteği sonlandırılan MODE_WORLD_WRITEABLE ve MODE_WORLD_READABLE modlarını kullanmayın. Bunlar 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 içerik sağlayıcı kullanmayı düşünebilirsiniz. İçerik sağlayıcı, diğer uygulamalara okuma ve yazma izinleri sunar ve duruma göre dinamik izinler verebilir.

Harici depolama

SD kart gibi harici depolama birimlerinde oluşturulan dosyalar genel olarak 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ından gelen verileri işlerken, güvenilmeyen herhangi bir kaynaktan gelen verilerde olduğu gibi giriş doğrulaması gerçekleştirin. Yürütülebilir dosyaları veya sınıf dosyalarını dinamik yüklemeden önce harici depolamaya kaydetmeyin. Uygulamanız harici depolamadan yürütülebilir dosyalar 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ırlanabilen 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 uygulamaların ContentProvider erişmesini istemiyorsanız uygulama manifestinde android:exported=false olarak işaretleyin. Aksi takdirde, depolanan verilere diğer uygulamaların 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 ayrı izinler belirtebilirsiniz. İzinlerinizi, söz konusu görevi tamamlamak için gerekenlerle sınırlayı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.

Verileri yalnızca kendi uygulamalarınız arasında paylaşmak için bir içerik sağlayıcı kullanıyorsanız android:protectionLevel özelliğini signature koruması olarak ayarlamanızı öneririz. İmza izinleri için kullanıcı onayı gerekmez. 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 sunar.

İçerik sağlayıcılar, android:grantUriPermissions özelliğini bildirerek 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 sağlayabilir. Bu izinlerin kapsamı, <grant-uri-permission> öğesiyle daha da sınırlandırılabilir.

İçerik sağlayıcıya erişirken güvenilmeyen kaynaklardan gelebilecek olası SQL yerleştirme saldırılarını önlemek için query, update ve delete() gibi parametreli 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 izniyle ilgili yanlış bir güvenlik algısına kapılmayın. Yazma izni, bazı verilerin reklam öğesi WHERE ifadeleri kullanılarak onaylanmasını ve sonuçların ayrıştırılmasını sağlayan SQL ifadelerine izin verir. Örneğin, bir saldırgan, yalnızca söz konusu telefon numarası zaten varsa bir satırı değiştirerek arama günlüğünde belirli bir telefon numarasının varlığını araştırabilir. İçerik sağlayıcı verileri tahmin edilebilir bir yapıya sahipse 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. kameraya erişim) beyan ederek yaparlar.

İzin istekleri

Uygulamanızın istediği izin 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 tanımlaması gerekip gerekmediğini değerlendirme ile ilgili kılavuza bakın.

Mümkünse uygulamanızı 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 edinebilirsiniz.) Alternatif olarak, harici depolama birimini kullanmak yerine (izin gerektirir) verileri dahili depolama biriminde saklayın.

Uygulamanız, izin istemenin yanı sıra güvenlikle ilgili hassas olan ve diğer uygulamalara (ör. ContentProvider) açık olan IPC'yi korumak için <permission> öğesini kullanabilir. Genel olarak, mümkün olduğunda kullanıcı tarafından onaylanan izinler dışında erişim kontrolleri kullanmanızı öneririz. Çünkü izinler kullanıcılar için kafa karıştırıcı olabilir. Örneğin, tek bir geliştirici tarafından sağlanan uygulamalar arasındaki IPC iletişimi için izinlerde imza koruma düzeyini kullanmayı düşünebilirsiniz.

İzinle korunan verileri sızdırmayın. Bu durum, uygulamanızın yalnızca bu verilere erişme izni olduğu için kullanılabilen verileri IPC üzerinden kullanıma sunduğunda 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 Devri: 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 uygulama için yeni izin oluşturmak nispeten nadir bir durumdur. Uygun durumlarda, mevcut izinleri kullanarak erişim kontrolleri yapın.

Yeni bir izne ihtiyacınız varsa görevinizi imza koruma düzeyi ile tamamlayıp tamamlayamayacağınızı değerlendirin. İ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şimine izin verir.

Yeni izin oluşturmak hâlâ gerekiyorsa <permission> öğesini kullanarak uygulama manifestinde bunu 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üzeyinde bir izin oluşturursanız dikkate almanız gereken çeşitli karmaşık durumlar vardır:

  • İzin, kullanıcıya yapması gereken güvenlik kararını kısa ve öz bir şekilde açıklayan bir dizeye sahip olmalıdır.
  • İzin dizesi birçok farklı dile yerelleştirilmelidir.
  • Kullanıcılar, bir izin kafa karıştırıcı olduğu veya riskli olarak algılandığı için uygulamayı yüklememeyi tercih edebilir.
  • İzni oluşturan kullanıcı yüklenmediyse uygulamalar izin isteyebilir.

Bunların her biri, geliştirici olarak sizin için önemli bir teknik olmayan zorluk oluştururken kullanıcılarınızı da şaşırtır. Bu nedenle, tehlikeli izin düzeyinin kullanılmasını önermiyoruz.

Ağ İletişimi

Ağ işlemleri, kullanıcıya özel olabilecek verilerin iletimini içerdiğinden güvenlik açısından risk teşkil eder. Kullanıcılar, mobil cihazlarla ilgili gizlilikle ilgili endişeler 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. Önemli olan, hassas veriler için uygun protokollerin kullanılmasını sağlamaktır. Örneğin, güvenli web trafiği için HttpsURLConnection protokolü kullanılmalıdır. Mobil cihazlar genellikle herkese açık kablosuz ağ bağlantı noktaları gibi güvenli olmayan ağlara bağlandığından, sunucuda HTTPS'nin desteklendiği her yerde HTTP yerine HTTPS kullanın.

Kimliği doğrulanmış, şifrelenmiş soket düzeyinde iletişim, SSLSocket sınıfı kullanılarak kolayca uygulanabilir. Android cihazların kablosuz bağlantı 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 uygulamalarda güvenli ağ kullanımı ö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, Service gibi kimlik doğrulamanın mümkün olduğu bir Android IPC mekanizması kullanın. Belirli olmayan IP adresi INADDR_ANY ile bağlama, uygulamanızın herhangi bir IP adresinden istek almasına izin verdiğinden geri döngü kullanmaktan daha kötüdür.

HTTP veya diğer güvenli olmayan protokollerden indirilen verilere güvenmediğinizden emin olun. Buna, WebView girişinin doğrulanması ve HTTP'ye karşı verilen amaçlara yönelik tüm yanıtlar dahildir.

Telefon ağı

Kısa Mesaj Hizmeti (SMS) protokolü öncelikle kullanıcıdan kullanıcıya iletişim için tasarlanmıştır ve veri aktarmak isteyen uygulamalar için uygun değildir. SMS'in sınırlamaları nedeniyle, bir web sunucusundan kullanıcı cihazındaki uygulamanıza veri mesajları göndermek için Firebase Cloud Messaging (FCM) ve IP ağı kullanmanızı öneririz.

SMS'in ne ağda ne de cihazda şifrelenmediğini veya güçlü bir şekilde kimliğinin doğrulanmadığını unutmayın. Özellikle, herhangi bir SMS alıcısı, kötü niyetli bir kullanıcının uygulamanıza SMS göndermiş olabileceğini beklemelidir. Hassas komutları gerçekleştirmek için kimliği doğrulanmamış SMS verilerine güvenmeyin. Ayrıca, SMS'lerin ağda sahteciliğe ve/veya dinlemeye tabi olabileceğini unutmayın. Android destekli cihazın kendisinde SMS mesajları yayın amaçları olarak iletilir. Bu nedenle, READ_SMS iznine sahip diğer uygulamalar tarafından okunabilir veya yakalanabilir.

Giriş doğrulaması

Yeterli giriş doğrulaması olmaması, hangi platformda çalıştıklarına bakılmaksızın uygulamaları etkileyen en yaygın güvenlik sorunlarından biridir. Android'de, uygulamaların giriş doğrulama sorunlarına maruz kalmasını azaltan platform düzeyinde karşı önlemler bulunur. 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 güvenli diller kullanmanızı öneririz.

Yerel kod kullanıyorsanız dosyalardan okunan, ağ üzerinden alınan veya IPC'den alınan tüm veriler güvenlik sorunu oluşturabilir. En yaygın sorunlar arabellek taşmaları, boşaltıldıktan sonra kullanma ve bir birimlik hatalardır. Android, bu hataların kötüye kullanılabilirliğini azaltan ASLR ve Veri Yürütmeyi Önleme (DEP) gibi çeşitli teknolojiler sunsa da 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.

Bir SQL veritabanına veya içerik sağlayıcıya gönderilen sorgularda veri kullanıyorsanız SQL yerleştirme sorun olabilir. 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ştirme ile ilgili olası zararları da azaltabilir.

Bu bölümde ele alınan güvenlik özelliklerini kullanamıyorsanız iyi yapılandırılmış veri biçimleri kullandığınızdan ve verilerin beklenen biçime uygun olduğundan emin olun. Belirli karakterleri engellemek veya karakterleri değiştirmek etkili bir strateji olsa da bu teknikler pratikte hataya açıktır. Bu nedenle, mümkün olduğunda bu tekniklerden kaçınmanızı öneririz.

Kullanıcı verileri

Kullanıcı verilerinin güvenliği konusunda en iyi yaklaşım, hassas veya kişisel bilgilere erişim sağlayan API'lerin kullanımını en aza indirmektir. Kullanıcı verilerine erişiminiz varsa bunları saklamaktan veya iletmekten kaçının. Uygulama mantığınızın, karma değer oluşturarak veya verinin geri döndürülemez bir şekli kullanılarak uygulanmasının mümkün olup olmadığı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ılarınızın kimliğini doğrulayın ve geçiş anahtarları ile 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 verilerin kullanımını ve depolanmasını 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 indirme güvenlik en iyi uygulamasını izleyin.

Ayrıca, uygulamanızın kişisel bilgileri reklamcılık için kullanılan üçüncü taraf bileşenleri veya uygulamanız tarafından kullanılan üçüncü taraf hizmetleri gibi diğer taraflara istemeden ifşa edip etmeyeceğini de göz önünde bulundurun. Bir bileşenin veya hizmetin neden kişisel bilgi istediğ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ın hassas verilere erişmesi gerekiyorsa bu verileri bir sunucuya iletmeniz gerekip gerekmediğini veya işlemi istemcide çalıştırıp çalıştıramayacağınızı değerlendirin. Kullanıcı verilerinin iletilmesini önlemek için hassas verileri kullanan tüm kodları istemcide çalıştırmayı düşünebilirsiniz. Ayrıca, aşırı izin veren IPC, herkese yazılabilir dosyalar veya ağ soketleri aracılığıyla kullanıcı verilerini cihazdaki diğer uygulamalara istemeden de olsa ifşa etmediğinizden emin olun. Aşırı izinli IPC, İzin istekleri bölümünde ele alınan, izinle korunan verilerin sızdırılmasıyla ilgili özel bir durumdur.

Evrensel 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ılarla ilgili en iyi uygulamalar sayfasında daha ayrıntılı olarak ele alınmaktadır.

Cihaz üzerindeki günlük dosyalarına 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çici olsa ve yeniden başlatma sırasında silinse de kullanıcı bilgilerinin uygunsuz şekilde kaydedilmesi, kullanıcı verilerinin diğer uygulamalara istemeden sızmasına neden olabilir. Kimliği tanımlayabilecek bilgilerin (PII) kaydedilmemesinin yanı sıra üretim uygulamalarında günlük kullanımını sınırlayın. Bunu kolayca uygulamak için hata ayıklama işaretlerini ve kolayca yapılandırılabilen günlük düzeylerine sahip özel Log sınıflarını kullanın.

WebView

WebView, HTML ve JavaScript içerebilen web içeriğini kullandığından uygunsuz kullanım, siteler arası komut dosyası çalıştırma (JavaScript ekleme) gibi yaygın web güvenliği sorunlarına yol açabilir. Android, WebView özelliğinin uygulamanızın gerektirdiği minimum işlevsellikle sınırlandırılması yoluyla bu olası sorunların kapsamını azaltmak için çeşitli mekanizmalar içerir.

Uygulamanız 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 çalıştırmadığından siteler arası komut dosyası çalıştırma mümkün değildir.

addJavaScriptInterface(), JavaScript'in normalde Android uygulamalarına ayrılmış işlemleri çağırmasına izin verdiğinden özellikle dikkatli kullanılmalıdır. Kullanıyorsanız addJavaScriptInterface() yalnızca tüm girişlerin güvenilir olduğu web sayfalarına gösterin. Güvenilmeyen girişlere izin verilirse güvenilmeyen JavaScript, uygulamanızdaki Android yöntemlerini çağırabilir. Genel olarak, addJavaScriptInterface() işlevini yalnızca uygulamanızın APK'sında bulunan JavaScript'e sunmanızı öneririz.

Uygulamanız WebView ile hassas verilere erişiyorsa yerel olarak depolanan dosyaları silmek için clearCache() yöntemini kullanabilirsiniz. Ayrıca, bir uygulamanın belirli içerikleri önbelleğe almaması gerektiğini belirtmek için no-store gibi sunucu tarafı başlıklarını da kullanabilirsiniz.

Android 4.4'ten (API düzeyi 19) eski platformları çalıştıran cihazlar, webkit'ın bir dizi güvenlik sorunu içeren bir sürümünü kullanır. Geçici çözüm olarak, uygulamanız bu cihazlarda çalışıyorsa WebView nesnelerinin yalnızca güvenilir içerik gösterdiğini onaylaması gerekir. Uygulamanızın SSL'deki olası güvenlik açıklarına maruz kalmadığından emin olmak için Provider güncellenebilir güvenlik nesnesini SSL suistimallerine karşı koruma için güvenlik sağlayıcınızı güncelleme başlıklı makalede açıklandığı şekilde kullanın. Uygulamanızın açık web'deki içerikleri oluşturması gerekiyorsa en son güvenlik yamalarıyla güncel tutabilmek için kendi oluşturucunuzu sağlamayı düşünebilirsiniz.

Kimlik bilgisi istekleri

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

Kimlik bilgilerinin açığa çıkmasını 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ıyla şifresiz kimlik doğrulamayı etkinleştirmek veya Google ile oturum açma gibi şemaları kullanarak federasyon oturum açmayı uygulamak için Kimlik Bilgisi Yöneticisi'ni kullanın. Geleneksel şifre kimlik doğrulaması kullanmanız gerekiyorsa kullanıcı kimliklerini ve şifrelerini cihazda depolamayın. Daha ziyade, 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 ömürlü 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 deneyimine izin verirken bu oranları makul bir sıklıkla sınırlayın.

Güvenli kimlik doğrulama kullanma

  • Geçiş anahtarlarını uygulama Geçiş anahtarlarını, şifrelere kıyasla daha güvenli ve kullanıcı dostu bir yükseltme olarak etkinleştirin.
  • Biyometri ekleme Ek güvenlik için parmak izi veya yüz tanıma gibi biyometrik kimlik doğrulama kullanma olanağı sunun.
  • Birleştirilmiş kimlik sağlayıcıları kullanın. Kimlik Bilgisi Yöneticisi, Google ile oturum açma gibi birleştirilmiş kimlik doğrulama sağlayıcılarını destekler.
  • İletişimi şifreleme Uygulamanızın ağ üzerinden gönderdiği verilerin korunmasını sağlamak için HTTPS ve benzer teknolojileri kullanın.

Güvenli hesap yönetimi

  • 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 depolamayın.
  • AccountManager kullanarak bir Account aldıktan sonra, kimlik bilgilerini yanlışlıkla yanlış uygulamaya aktarmamak için kimlik bilgilerini aktarmadan önce CREATOR kullanın.
  • Kimlik bilgileri yalnızca sizin oluşturduğunuz uygulamalar tarafından kullanılıyorsa AccountManager öğesine erişen uygulamayı checkSignatures kullanarak doğrulayabilirsiniz. Alternatif olarak, kimlik bilgisini yalnızca bir uygulama kullanıyorsa depolama için KeyStore kullanabilirsiniz.

Tetikte olun

  • Kodunuzu 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. Yetkilendirme ile ilgili kötüye kullanım kalıpları gibi olası kötüye kullanımları arayın.
  • Kodunuzu denetleyin. Olası kimlik bilgisi isteği sorunlarını aramak 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 önemli bir bileşenidir. Bu anahtarlar, uygulamaların harici hizmetlere erişmesini ve harita hizmetlerine bağlanma, kimlik doğrulama ve hava durumu hizmetleri gibi temel işlevleri gerçekleştirmesini sağlar. Ancak bu hassas anahtarların açığa çıkması, veri ihlalleri, yetkisiz erişim ve maddi kayıplar gibi ciddi sonuçlara yol açabilir. Bu tür senaryoları önlemek için geliştiricilerin, geliştirme süreci boyunca API anahtarlarını işlemek üzere güvenli stratejiler uygulaması gerekir.

Hizmetlerin kötüye kullanımını önlemek için API anahtarları dikkatli bir şekilde korunmalıdır. Uygulama ile API anahtarı kullanan bir hizmet arasındaki bağlantıyı güvenli hale getirmek için API'ye erişimi güvenli hale getirmeniz gerekir. Uygulamanız derlendiğinde ve uygulamanızın kaynak kodunda API anahtarları varsa saldırganlar uygulamayı derleyip kaynak koduna dönüştürerek bu kaynakları bulabilir.

Bu bölüm, iki Android geliştirici grubu için hazırlanmıştır: Sürekli teslim ardışık düzeninde altyapı ekipleriyle çalışanlar ve Play Store'da bağımsız uygulamalar dağıtanlar. Bu bölümde, uygulamanızın hizmetlerle güvenli bir şekilde iletişim kurabilmesi için API anahtarlarının nasıl işleneceğine dair en iyi uygulamalar özetlenmektedir.

Üretme ve depolama

Geliştiriciler, API anahtarı depolamayı derinlemesine savunma yaklaşımı kullanarak veri koruma ve kullanıcı gizliliğinin kritik bir bileşeni olarak ele almalı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çla şifreleyin.

Kaynak kontrolü hariç tutma

API anahtarlarını hiçbir zaman kaynak kodu deponuza yüklemeyin. Kaynak koda API anahtarı eklemek, anahtarların herkese açık depolarda, paylaşılan kod örneklerinde ve yanlışlıkla paylaşılan dosyalarda görünmesine neden olabilir. Bunun yerine, projenizdeki API anahtarlarıyla çalışmak için secrets-gradle-plugin gibi Gradle eklentilerini kullanın.

Ortama özgü anahtarlar

Mümkünse geliştirme, test ve üretim ortamları için ayrı API anahtarları kullanın. Her ortamı yalıtmak için ortama özgü anahtarlar kullanın. Bu sayede üretim verilerinin açığa çıkma riskini azaltabilir ve üretim ortamınızı etkilemeden güvenliği ihlal edilmiş anahtarları devre dışı bırakabilirsiniz.

Kullanım ve erişim denetimi

API'nizi ve kullanıcılarınızı korumak için güvenli API anahtarı uygulamaları çok önemlidir. Anahtarlarınızı optimum güvenlik için nasıl hazırlayacağınız aşağıda açıklanmıştır:

  • Her uygulama için benzersiz anahtarlar oluşturun: Güvenliği ihlal edilmiş erişimi tanımlamaya ve izole etmeye yardımcı olmak 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 adresleri veya aralıklarıyla sınırlayın.
  • Mobil uygulama anahtarı kullanımını sınırlama: API anahtarı kullanımını, anahtarla birlikte paketleyerek veya uygulama sertifikaları kullanarak belirli mobil uygulamalarla sınırlayın.
  • Şüpheli etkinlikleri günlüğe kaydetme ve izleme: Şüpheli etkinlikleri tespit etmek ve olası kötüye kullanımı önlemek için API kullanımını günlüğe kaydetme ve izleme mekanizmalarını uygulayın.

Not: Hizmetiniz, anahtarları belirli bir paket veya platformla sınırlama özellikleri sunmalıdır. Örneğin, Google Haritalar API'si, anahtar erişimini paket adı ve imzalama anahtarıyla sınırlar.

OAuth 2.0, kaynaklara erişimi yetkilendirmek için bir çerçeve sağlar. İstemcilerle sunucuların nasıl etkileşimde bulunması 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 kullanım için gereken minimum erişim düzeyine sahip olacak şekilde tanımlayabilirsiniz.

Anahtar rotasyonu ve geçerlilik süresi sonu

Keşfedilmemiş API güvenlik açıkları üzerinden yetkisiz erişim riskini azaltmak için API anahtarlarının düzenli olarak değiştirilmesi ö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 rotasyonu süresi yeterli olmalıdır. Güçlü bir anahtar yönetim sistemi uygulamak, bu süreçleri kolaylaştırmanıza yardımcı olabilir. Böylece anahtar rotasyonu ve geçerlilik süresi ihtiyaçlarınızın verimliliği artar.

Genel en iyi uygulamalar

  • SSL/HTTPS kullanma: API isteklerinizi şifrelemek için her zaman HTTPS iletişimi kullanın.
  • Sertifika sabitleme: Ek bir güvenlik katmanı için hangi sertifikaların geçerli kabul edildiğini kontrol etmek üzere sertifika sabitleme özelliğini kullanabilirsiniz.
  • Kullanıcı girişini doğrulama ve temizleme: API anahtarlarını açığa çıkarabilecek ekleme saldırılarını önlemek için kullanıcı girişini doğrulayın ve temizleyin.
  • En iyi güvenlik uygulamalarını takip etme: Geliştirme sürecinizde genel güvenlik en iyi uygulamalarını (güvenli kodlama teknikleri, kod incelemeleri ve güvenlik açığı taraması dahil) 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 olmalıdır: SDK'larınızın ve kitaplıklarınızın en yeni sürüme güncellendiğinden emin olun.

Kriptografi

Android, veri izolasyonu sağlamanın, tam dosya sistemi şifrelemesini desteklemenin ve güvenli iletişim kanalları sunmanın yanı sıra kriptografi 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 en yüksek düzeydeki önceden var olan çerçeve uygulamasını kullanmaya çalışın. Varsa Google tarafından sağlanan sağlayıcıları Google'ın belirttiği sırayla kullanın.

Bilinen bir ağ konumundan güvenli bir şekilde dosya almanız gerekiyorsa basit bir HTTPS URI'si yeterli olabilir ve kriptografi bilgisi gerektirmez. Güvenli bir tünele ihtiyacınız varsa kendi protokolünüzü yazmak yerine HttpsURLConnection veya SSLSocket kullanmayı düşünebilirsiniz. SSLSocket kullanıyorsanız ana makine adı doğrulaması yapmadığını unutmayın. SSLSocket 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 şifreleme algoritmalarını kullanın. Ayrıca şu en iyi uygulamaları izleyin:

  • Ticari amaçlarla 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, CTR veya GCM blok modlarının ne zaman kullanılacağını bilin.
  • CTR modunda IV/sayaç yeniden kullanımından kaçının. Kriptografik olarak rastgele olduklarından 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 tüm şifreleme anahtarlarını başlatmak için güvenli bir rastgele sayı üreteci olan SecureRandom'yi kullanın. Güvenli bir rastgele sayı oluşturucuyla 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.

Tekrar tekrar kullanmak için bir anahtar depolamanız gerekiyorsa kriptografik anahtarların uzun süreli depolanmasını ve alınmasını sağlayan KeyStore gibi bir mekanizma kullanın.

İşlemler arası iletişim

Bazı uygulamalar, ağ soketleri ve paylaşılan dosyalar gibi geleneksel Linux tekniklerini kullanarak IPC'yi uygulamaya çalışır. Ancak bunun yerine Service ve BroadcastReceiver ile Intent, Binder veya Messenger gibi IPC için 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ı ayarlamanıza olanak tanır.

Güvenlik öğelerinin çoğu IPC mekanizmalarında paylaşılır. IPC mekanizmanızın diğer uygulamalar tarafından kullanılması amaçlanmıyorsa bileşenin manifest öğesinde (ör. <service> öğesi) android:exported özelliğini false olarak ayarlayın. Bu, aynı UID içinde birden fazla işlemden oluşan uygulamalar için veya geliştirme sürecinin sonlarında işlevleri IPC olarak kullanmak istemediğinize karar verirseniz ancak kodu yeniden yazmak istemiyorsanız kullanışlıdır.

IPC'niz diğer uygulamalar tarafından erişilebiliyorsa <permission> öğesini kullanarak bir güvenlik politikası uygulayabilirsiniz. Uygulamalarınız arasında ve aynı anahtarla imzalanmış uygulamalar arasında IPC varsa android:protectionLevel içinde signature-level iznini kullanın.

Niyetler

Etkinlikler ve yayın alıcılar için niyetler, Android'de eşzamansız IPC için tercih edilen mekanizmadır. Uygulama gereksinimlerinize bağlı olarak sendBroadcast, sendOrderedBroadcast veya belirli bir uygulama bileşenine yönelik açık bir amaç kullanabilirsiniz. Güvenlik nedeniyle açık niyetler tercih edilir.

Sıralı yayınların alıcı tarafından tüketilebileceğini ve bu nedenle tüm uygulamalara teslim edilmeyebileceğini unutmayın. Belirli bir alıcıya gönderilmesi gereken bir intent gönderiyorsanız alıcıyı adıyla belirten belirgin intent kullanmanız gerekir.

Bir amaç gönderenler, yöntem çağrısıyla boş olmayan bir izin belirterek alıcının izni olduğunu doğrulayabilir. Yalnızca bu izne sahip uygulamalar amaçlı işlemi alır. Yayın amaçlı bir intent'teki veriler hassas olabilir. Kötü amaçlı uygulamaların uygun izinler olmadan bu mesajları almak için kaydolamayacağından emin olmak üzere izin uygulamanız önerilir. Bu gibi durumlarda, yayın oluşturmak yerine alıcıyı doğrudan çağırmayı da düşünebilirsiniz.

Hizmetler

Service, genellikle diğer uygulamaların kullanması için işlevsellik sağlamak amacıyla kullanılır. Her hizmet sınıfının, manifest dosyasında karşılık gelen bir <service> bildirimi olmalıdır.

Hizmetler varsayılan olarak dışa aktarılmaz ve başka bir uygulama tarafından çağrılamaz. Ancak hizmet bildirimine herhangi bir amaç filtresi eklerseniz bu filtre varsayılan olarak dışa aktarılır. android:exported özelliğinin istediğiniz şekilde davrandığından emin olmak için bu özelliği açıkça belirtmeniz en iyisidir. Hizmetler, android:permission özelliği kullanılarak da korunabilir. Bunu yaptığınızda, diğer uygulamaların hizmeti başlatabilmesi, durdurabilmesi veya hizmete bağlanabilmesi için kendi manifest dosyalarında karşılık gelen bir <uses-permission> öğesi bildirmesi gerekir.

Bir hizmet, kendisine yapılan bağımsız IPC çağrılarını izinlerle koruyabilir. Bu işlem, arama uygulaması yürütülmeden önce checkCallingPermission() aranarak yapılır. Bildirim dosyasında bildirimli izinleri kullanmanızı öneririz. Bu izinler, gözden kaçmaya daha az eğilimlidir.

Binder ve Messenger arayüzleri

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

Uygulama arayüzlerinizi, arayüze özgü izin kontrolleri gerektirmeyecek şekilde tasarlamanızı öneririz. Binder ve Messenger nesneleri uygulama manifestinde bildirilmediğinden bildirim temelli izinleri doğrudan bunlara uygulayamazsınız. Genellikle, uygulandıkları Service veya Activity için uygulama manifestinde beyan edilen izinleri devralırlar. Kimlik doğrulama ve/veya erişim kontrolleri gerektiren bir arayüz oluşturuyorsanız bu kontrolleri Binder veya Messenger arayüzüne açıkça kod olarak eklemeniz gerekir.

Erişim denetimleri gerektiren bir arayüz sağlıyorsanız arayanın gerekli izne sahip olup olmadığını doğrulamak için checkCallingPermission() kullanın. Bu, özellikle arayan adına bir hizmete erişmeden önce önemlidir. Çünkü uygulamanızın kimliği diğer arayüzlere iletilir. Service tarafından sağlanan bir arayüzü çağırıyorsanız verilen hizmete erişim izniniz yoksa bindService() çağırma işlemi başarısız olabilir. Uygulamanızla etkileşime girmesine izin vermeniz gereken ancak gerekli izinlere sahip olmayan harici bir işlem varsa clearCallingIdentity() yöntemini kullanabilirsiniz. Bu yöntem, harici arayan yerine uygulamanızın kendisi arıyormuş gibi uygulamanızın arayüzüne çağrı yapar. Arayan izinlerini daha sonra restoreCallingIdentity() yöntemiyle geri yükleyebilirsiniz.

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

Yayın alıcılar

Bir BroadcastReceiver, Intent tarafından başlatılan eşzamansız istekleri işler.

Alıcılar varsayılan olarak dışa aktarılır ve diğer uygulamalar tarafından çağrılabilir. BroadcastReceiver, diğer uygulamalar tarafından kullanılmak üzere tasarlanmışsa uygulama manifestindeki <receiver> öğesini kullanarak alıcılara güvenlik izinleri uygulamak isteyebilirsiniz. Bu, uygun izinlere sahip olmayan uygulamaların BroadcastReceiver'ya niyet göndermesini engeller.

Dinamik olarak yüklenen kodla güvenlik

Uygulama APK'nızın dışından kod yüklemenizi kesinlikle önermiyoruz. Bu durum, kod yerleştirme veya kod kurcalama nedeniyle uygulamanın güvenliğinin ihlal edilme olasılığını önemli ölçüde artırır. Ayrıca sürüm yönetimi ve uygulama testiyle ilgili karmaşıklıklar da ekler. Uygulamanın davranışını doğrulamayı imkansız hale getirebileceğinden bazı ortamlarda yasaklanabilir.

Uygulamanız dinamik olarak kod yüklüyorsa dikkat etmeniz gereken en önemli nokta, dinamik olarak yüklenen kodun uygulama APK'sı ile aynı güvenlik izinleriyle çalışmasıdır. Kullanıcı, kimliğinize göre uygulamanızı yüklemeye karar 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, ağdan şifrelenmemiş protokoller üzerinden indirilen veya harici depolama gibi herkesin yazabileceği konumlardan yüklenenler gibi güvenli olmayan konumlardan kod yüklemeye çalışır. Bu konumlar, ağdaki bir kullanıcının, aktarım halindeki içeriği veya kullanıcının cihazındaki başka bir uygulamayı değiştirerek cihazdaki içeriği değiştirmesine olanak tanıyabilir. Diğer yandan, doğrudan APK'nıza dahil edilen modüller başka uygulamalar tarafından değiştirilemez. Bu, kodun yerel bir kitaplık veya DexClassLoader kullanılarak yüklenen bir sınıf olması durumunda da geçerlidir.

Sanal makinede güvenlik

Dalvik, Android'in çalışma zamanı sanal makinesidir. Dalvik, özellikle Android için geliştirilmiştir 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ı konusunda endişelenmenize gerek yoktur. Uygulamanız güvenli bir sanal alan ortamında çalıştığı için sistemdeki diğer işlemler kodunuza veya özel verilerinize erişemez.

Sanal makine güvenliği hakkında daha fazla bilgi edinmek istiyorsanız konuyla ilgili mevcut bazı literatürlere göz atın. En popüler kaynaklardan ikisi:

Bu belgede, Android'e özgü olan veya diğer sanal makine ortamlarından farklı olan alanlara odaklanılmıştır. Diğer ortamlarda VM programlama konusunda deneyimli geliştiriciler için Android uygulamaları yazmayla ilgili iki temel sorun farklı olabilir:

  • JVM veya .NET çalışma zamanı gibi bazı sanal makineler, kodu temel işletim sistemi özelliklerinden izole ederek güvenlik sınırı görevi görür. Android'de Dalvik VM bir güvenlik sınırı değildir. Uygulama korumalı alanı işletim sistemi düzeyinde uygulanır. Bu nedenle Dalvik, aynı uygulamadaki yerel kodla herhangi bir güvenlik kısıtlaması olmadan birlikte çalışabilir.
  • Mobil cihazlardaki depolama alanı sınırlı olduğundan geliştiriciler genellikle modüler uygulamalar oluşturmak ve dinamik sınıf yükleme kullanmak ister. Bu işlemi yaparken hem uygulama mantığınızı aldığınız kaynağı hem de bunu yerel olarak depoladığınız yeri göz önünde bulundurun. Güvenli olmayan ağ kaynakları veya harici depolama gibi doğrulanmamış kaynaklardan dinamik sınıf yükleme yöntemini kullanmayın. Bu kod, kötü amaçlı davranışlar içerecek şekilde değiştirilmiş olabilir.

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şık, daha az taşınabilir 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. Yerel kod kullanıyorsanız Linux geliştirme güvenliğiyle ilgili en iyi uygulamaları bilmek özellikle faydalıdır. Linux güvenlik uygulamaları bu belgenin kapsamı dışındadır ancak en popüler kaynaklardan biri Secure Programming HOWTO - Creating Secure Software'dır.

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 olan geliştiriciler için bu durumu düşünmenin iyi bir yolu, her uygulamaya çok sınırlı izinlere sahip benzersiz bir kullanıcı tanımlayıcısı (UID) verildiğini bilmektir. Bu konu, Android Güvenliğine Genel Bakış bölümünde daha ayrıntılı olarak ele alınmaktadır. Yerel kod kullanıyor olsanız bile uygulama izinleri hakkında bilgi sahibi olmanız gerekir.