Net metin iletişimleri

OWASP kategorisi: MASVS-NETWORK: Ağ İletişimi

Genel Bakış

Bir Android uygulamasında düz metin ağ iletişimlerine izin vermek, ağ trafiğini izleyen herkesin iletilen verileri görmesi ve değiştirmesi anlamına gelir. İletilen veriler şifreler, kredi kartı numaraları veya diğer kişisel bilgiler gibi hassas bilgiler içeriyorsa bu bir güvenlik açığıdır.

Hassas bilgiler gönderip göndermediğinizden bağımsız olarak, şifresiz metin trafiği ARP veya DNS zehirlenmesi gibi ağ saldırılarıyla da manipüle edilebileceğinden şifresiz metin kullanmak yine de bir güvenlik açığı olabilir. Bu durum, saldırganların bir uygulamanın davranışını etkilemesine olanak tanıyabilir.

Etki

Bir Android uygulaması ağ üzerinden verileri şifresiz metin olarak gönderdiğinde veya aldığında ağı izleyen herkes bu verileri yakalayıp okuyabilir. Bu veriler şifreler, kredi kartı numaraları veya kişisel mesajlar gibi hassas bilgiler içeriyorsa kimlik hırsızlığı, mali sahtekarlık ve diğer ciddi sorunlara yol açabilir.

Örneğin, şifreleri şifresiz metin olarak ileten bir uygulama, trafiği engelleyen kötü niyetli bir kişinin bu kimlik bilgilerini açığa çıkarmasına neden olabilir. Bu veriler daha sonra kullanıcının hesaplarına yetkisiz erişim elde etmek için kullanılabilir.

Risk: Şifrelenmemiş iletişim kanalları

Verilerin şifrelenmemiş iletişim kanalları üzerinden iletilmesi, cihaz ve uygulama uç noktaları arasında paylaşılan verileri açığa çıkarır. Söz konusu veriler, saldırganlar tarafından ele geçirilebilir ve değiştirilebilir.

Çözümler

Veriler, şifrelenmiş iletişim kanalları üzerinden gönderilmelidir. Şifreleme özellikleri sunmayan protokoller yerine güvenli protokoller kullanılmalıdır.

Belirli Riskler

Bu bölümde, standart dışı azaltma stratejileri gerektiren veya belirli bir SDK düzeyinde azaltılmış olan ve eksiksiz olması için buraya eklenen riskler yer almaktadır.

Risk: HTTP

Bu bölümdeki yönergeler yalnızca Android 8.1 (API düzeyi 27) veya önceki sürümleri hedefleyen uygulamalar için geçerlidir. Android 9'dan (API düzeyi 28) itibaren URLConnection, Cronet ve OkHttp gibi HTTP istemcileri HTTPS kullanımını zorunlu kılar. Bu nedenle, şifresiz metin desteği varsayılan olarak devre dışıdır. Ancak Ktor gibi diğer HTTP istemci kitaplıklarının bu kısıtlamaları şifresiz metin üzerinde zorunlu kılmayacağını ve dikkatli kullanılması gerektiğini unutmayın.

Çözümler

Şifresiz metin trafiğini devre dışı bırakmak ve uygulamanızda HTTPS'yi zorunlu kılmak için NetworkSecurityConfig.xml özelliğini kullanın. Yalnızca gerekli olan belirli alan adları (genellikle hata ayıklama amacıyla) için istisnalar geçerlidir:

Xml

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <base-config cleartextTrafficPermitted="false">
    <domain-config cleartextTrafficPermitted="true">
        <domain includeSubdomains="true">debug.domain.com</domain>
    </domain-config>
</network-security-config>

Bu seçenek, arka uç sunucular gibi harici kaynaklar tarafından sağlanan URL'lerdeki değişiklikler nedeniyle uygulamalarda yanlışlıkla gerileme yaşanmasını önlemeye yardımcı olur.

Risk: FTP

Cihazlar arasında dosya alışverişi için FTP protokolünün kullanılması çeşitli riskler taşır. Bunların en önemlisi, iletişim kanalında şifrelemenin olmamasıdır. Bunun yerine SFTP veya HTTPS gibi daha güvenli alternatifler kullanılmalıdır.

Çözümler

Uygulamanızda internet üzerinden veri alışverişi mekanizmalarını uygularken HTTPS gibi güvenli bir protokol kullanmanız gerekir. Android, geliştiricilerin istemci-sunucu mantığı oluşturmasına olanak tanıyan bir API grubu sunar. Bu, Taşıma Katmanı Güvenliği (TLS) kullanılarak güvenli hale getirilebilir. Böylece iki uç nokta arasındaki veri alışverişinin şifrelenmesi sağlanır ve kötü niyetli kullanıcıların iletişimi dinlemesi ve hassas verileri alması önlenir.

İstemci-sunucu mimarileri genellikle geliştiriciye ait API'leri kullanır. Uygulamanız bir dizi API uç noktasına bağlıysa HTTPS iletişimlerini korumak için aşağıdaki güvenlik en iyi uygulamalarını izleyerek derinlemesine güvenlik sağlayın:

  • Kimlik doğrulama: Kullanıcılar, OAuth 2.0 gibi güvenli mekanizmalar kullanarak kimliklerini doğrulamalıdır. Temel kimlik doğrulama, oturum yönetimi mekanizmaları sağlamadığı ve kimlik bilgileri uygun şekilde saklanmadığı takdirde Base64'ten çözülebileceği için genellikle önerilmez.
  • Yetkilendirme: Kullanıcıların, en az ayrıcalık ilkesi uyarınca yalnızca amaçlanan kaynaklara erişimi kısıtlanmalıdır. Bu, uygulamanın öğeleri için dikkatli erişim denetimi çözümleri benimsenerek uygulanabilir.
  • Güvenlikle ilgili en iyi uygulamalara uygun olarak, dikkatli bir şekilde seçilmiş ve en yeni şifreleme paketlerinin kullanıldığından emin olun. Örneğin, HTTPS iletişimleri için gerekirse geriye dönük uyumlulukla TLSv1.3 protokolünü desteklemeyi düşünebilirsiniz.

Risk: Özel İletişim Protokolleri

Özel iletişim protokollerini uygulamak veya iyi bilinen protokolleri manuel olarak uygulamaya çalışmak tehlikeli olabilir.

Özel protokoller, geliştiricilerin amaçlanan ihtiyaçlara uyum sağlayan benzersiz bir çözüm oluşturmasına olanak tanırken geliştirme sürecindeki herhangi bir hata güvenlik açığına yol açabilir. Örneğin, oturum işleme mekanizmalarının geliştirilmesindeki hatalar, saldırganların iletişimi dinlemesine ve hassas bilgileri anında almasına neden olabilir.

Öte yandan, HTTPS gibi iyi bilinen protokolleri işletim sistemi veya iyi bakılan üçüncü taraf kitaplıklarını kullanmadan uygulamak, gerektiğinde uyguladığınız protokolü güncellemenizi zorlaştırabilecek (hatta imkansız hale getirebilecek) kodlama hataları yapma olasılığını artırır. Ayrıca, bu durum özel protokoller kullanmayla aynı türde güvenlik açıklarına yol açabilir.

Çözümler

Bilinen iletişim protokollerini uygulamak için bakımı yapılan kitaplıkları kullanma

Uygulamanızda HTTPS gibi iyi bilinen protokolleri uygulamak için işletim sistemi kitaplıkları veya bakımı yapılan üçüncü taraf kitaplıkları kullanılmalıdır.

Böylece geliştiriciler, kapsamlı bir şekilde test edilmiş, zaman içinde iyileştirilmiş ve yaygın güvenlik açıklarını düzeltmek için sürekli olarak güvenlik güncellemeleri alan çözümleri tercih edebilir.

Ayrıca, iyi bilinen protokolleri tercih eden geliştiriciler çeşitli sistemler, platformlar ve IDE'ler arasında geniş uyumluluktan yararlanarak geliştirme sürecinde insan hatası olasılığını azaltır.

SFTP kullanma

Bu protokol, geçiş halindeki verileri şifreler. Bu tür bir dosya değişimi protokolü kullanılırken ek önlemler dikkate alınmalıdır:

  • SFTP, farklı kimlik doğrulama türlerini destekler. Şifre tabanlı kimlik doğrulama yerine ortak anahtar kimlik doğrulama yöntemi kullanılmalıdır. Bu tür anahtarlar güvenli bir şekilde oluşturulup saklanmalıdır. Bu amaçla Android anahtar deposu önerilir.
  • Desteklenen şifrelerin en iyi güvenlik uygulamalarına uygun olduğundan emin olun.

Kaynaklar