Net metin iletişimleri

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

Genel Bakış

Android uygulamasında şifresiz metin ağ iletişimlerine izin vermek, ağ trafiğini izleyen herkesin aktarılan verileri görebileceği ve değiştirebileceği anlamına gelir. Gönderilen veriler şifre, kredi kartı numarası veya diğer kişisel bilgiler gibi hassas bilgiler içeriyorsa bu bir güvenlik açığıdır.

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

Etki

Bir Android uygulaması, ağ üzerinden açık metin olarak veri gönderdiğinde veya aldığında, ağı izleyen herkes bu verileri yakalayıp okuyabilir. Bu veriler şifre, kredi kartı numarası 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 açık metin olarak ileten bir uygulama, bu kimlik bilgilerini trafiği kesen kötü niyetli bir kullanıcıya gösterebilir. 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 aktarılması, cihaz ile uygulama uç noktaları arasında paylaşılan verileri açığa çıkarır. Söz konusu verilere saldırganlar tarafından müdahale edilebilir ve değiştirilebilir.

Çözümler

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

Belirli Riskler

Bu bölümde, standart olmayan azaltma stratejileri gerektiren veya belirli bir SDK düzeyinde azaltılan riskler toplanmıştır. Bu bölüm, eksiksiz bir liste sunmak için eklenmiştir.

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'nin kullanılmasını zorunlu kılar. Bu nedenle, açık 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ı açık metinde uygulama olasılığının düşük olduğunu ve bu kitaplıkların dikkatli bir şekilde kullanılması gerektiğini unutmayın.

Çözümler

Şifresiz metin trafiğini devre dışı bırakmak ve uygulamanız için HTTPS'yi zorunlu kılmak üzere NetworkSecurityConfig.xml özelliğini kullanın. Yalnızca gerekli olan belirli alanlar (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 gerilemelerin önlenmesine yardımcı olur.

Risk: FTP

Cihazlar arasında dosya alışverişi yapmak için FTP protokolünü kullanmak çeşitli riskler içerir. Bunlardan en önemlisi, iletişim kanalında şifreleme 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ı 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üvence altına alınabilir. Bu sayede iki uç nokta arasında veri alışverişinin şifrelenmesini sağlayarak kötü amaçlı kullanıcıların iletişimleri dinlemesini ve hassas verileri almasını önleyebilirsiniz.

İstemci-sunucu mimarileri genellikle geliştiriciye ait API'lere dayanır. Uygulamanız bir dizi API uç noktasına bağlıysa HTTPS iletişimlerini korumak için aşağıdaki güvenlikle ilgili en iyi uygulamaları uygulayarak kapsamlı güvenlikten yararlanı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ığından genellikle önerilmez. Kimlik bilgileri yanlış şekilde depolanırsa Base64'te kodu çözülebilir.
  • Yetkilendirme: Kullanıcılar, en az ayrıcalık ilkesine uygun olarak yalnızca amaçlanan kaynaklara erişecek şekilde 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 uyarak en yeni ve dikkatli bir şekilde seçilmiş şifre paketlerinin kullanılmasını sağlayın. Ö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 protokolleri uygulamak veya bilinen protokolleri manuel olarak uygulamaya çalışmak tehlikeli olabilir.

Özel protokoller, geliştiricilerin amaçlanan ihtiyaçlara uyum sağlayan benzersiz bir çözüm tasarlamasına olanak tanısa da geliştirme sürecindeki herhangi bir hata güvenlik açıklarına neden olabilir. Örneğin, oturum işleme mekanizmalarının geliştirilmesinde yapılan hatalar, saldırganların iletişimleri dinlemesine ve hassas bilgileri anında almasına neden olabilir.

Diğer yandan, işletim sistemi veya iyi korunan üçüncü taraf kitaplıklar kullanmadan HTTPS gibi bilinen protokolleri uygulamak, gerektiğinde uyguladığınız protokolü güncellemeyi imkansız olmasa bile zorlaştırabilecek kodlama hataları ortaya çıkma olasılığını artırır. Ayrıca bu, özel protokoller kullanmakla aynı türde güvenlik açıklarına yol açabilir.

Çözümler

Bilinen iletişim protokollerini uygulamak için bakımlı kitaplıkları kullanın

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

Bu sayede geliştiriciler, titizlikle test edilmiş, zaman içinde iyileştirilmiş ve yaygın güvenlik açıklarını düzeltmek için sürekli güvenlik güncellemeleri alan çözümleri kullanmanın güvenliğinden yararlanabilir.

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, aktarım sırasında verileri şifreler. Bu tür bir dosya alışverişi 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şturulmalı ve depolanmalıdır. Bu amaçla Android Anahtar Deposu kullanılması önerilir.
  • Desteklenen şifrelerin güvenlikle ilgili en iyi uygulamaları takip ettiğinden emin olun.

Kaynaklar