OWASP kategorisi: MASVS-CODE: Kod Kalitesi
Genel Bakış
Android uygulamaları, belirli işlevler için C ve C++ gibi dillerde yazılmış yerel koddan yararlanabilir. Bununla birlikte, bir uygulama bu yerel kodla etkileşim kurmak için Java Yerel Arayüzü'nü (JNI) kullandığında, arabellek taşması gibi güvenlik açıklarına ve yerel kod uygulamasında olabilecek diğer sorunlara maruz kalır.
Etki
Android uygulamalarında yerel kod kullanılması, performans optimizasyonu ve kod karartma gibi çok olumlu etkilere sahip olsa da güvenlik açısından olumsuz etkileri olabilir. C/C++ gibi yerel kod dilleri, Java/Kotlin'in bellek güvenliği özelliklerine sahip değildir. Bu nedenle, arabellek taşması, boşaltıldıktan sonra kullanım hataları ve diğer bellek bozulması sorunlarına karşı hassastır. Bu da kilitlenmelere veya rastgele kodların yürütülmesine neden olur. Ayrıca, yerel kod bileşeninde bir güvenlik açığı varsa gerisi Java'da güvenli bir şekilde yazılmış olsa bile uygulamanın tamamının güvenliğini ihlal edebilir.
Çözümler
Geliştirme ve kodlama kılavuzu
- Güvenli Kodlama Yönergeleri: C/C++ projeleri için belirlenmiş güvenli kodlama standartlarına (ör. CERT, OWASP) kullanarak arabellek taşmaları, tam sayı taşmaları ve biçim dizesi saldırıları gibi güvenlik açıklarını azaltın. Kalite ve güvenlikle bilinen Abseil gibi kitaplıklara öncelik verin. Mümkün olduğunda, C/C++ ile karşılaştırılabilir bir performans sunan Rust gibi bellek açısından güvenli dilleri kullanmayı düşünün.
- Giriş Doğrulaması: Şifre saldırılarını ve diğer güvenlik açıklarını önlemek için kullanıcı girişi, ağ verileri ve dosyalar dahil olmak üzere harici kaynaklardan alınan tüm giriş verilerini titizlikle doğrulayın.
Derleme seçeneklerini güçlendirme
ELF biçimini kullanan yerel kitaplıklar, yığın koruması (Canary), salt okunur yer değiştirme (RELRO), veri yürütme önleme (NX) ve konumdan bağımsız yürütülebilir dosyalar (PIE) gibi koruyucu mekanizmalar etkinleştirilerek çeşitli güvenlik açıklarına karşı güçlendirilebilir. Android NDK derleme seçenekleri de bu korumaların tümünü varsayılan olarak sağlamaktadır.
Bu güvenlik mekanizmalarının bir ikili programda uygulanıp uygulanmadığını doğrulamak için hardening-check
veya pwntools
gibi araçları kullanabilirsiniz.
Bash
$ pwn checksec --file path/to/libnativecode.so
Arch: aarch64-64-little
RELRO: Full RELRO
Stack: Canary found
NX: NX enabled
PIE: PIE enabled
Üçüncü taraf kitaplıklarının güvenlik açığı olmadığını doğrulama
Üçüncü taraf kitaplıkları seçerken geliştirme topluluğunda sağlam bir üne sahip olanları kullanmaya öncelik verin. Google Play SDK Dizini gibi kaynaklar, saygın ve güvenilir kitaplıkları belirlemenize yardımcı olabilir. Kitaplıkları en son sürümlere güncel tuttuğunuzdan emin olun ve Exploit-DB'deki veritabanları gibi kaynakları kullanarak bunlarla ilgili bilinen güvenlik açıklarını proaktif olarak arayın. [library_name] vulnerability
veya [library_name] CVE
gibi anahtar kelimelerin kullanıldığı bir web araması, kritik güvenlik bilgilerini açığa çıkarabilir.
Kaynaklar
- CWE-111: Güvenli Olmayan JNI'nin Doğrudan Kullanımı
- Yaralanma veritabanı
- Güvenlik sağlamlaştırma özellikleri için ikili programları kontrol edin
- pwntools ile ikili güvenlik ayarlarını kontrol etme
- Linux ikili güvenlik güçlendirmesi
- ELF ikililerini Salt Yer Değiştirme (RELRO) kullanarak güçlendirme
- OWASP ikili koruma mekanizmaları
- SEI CERT Kodlama Standartları
- OWASP Geliştirici Kılavuzu
- Google Play SDK Dizini
- Android NDK
- Android Rust'a giriş
- Abseil (C++ Ortak Kitaplıkları)
- PIE, bağlayıcı tarafından zorunlu kılınmıştır