Güvenli Mobil Uygulama Geliştirme

 

Konum tabanlı servisler, mobil sosyal ağlar, mobil bilgi arama, mobil ödeme (NFC), obje tanıma, mobil mesajlaşma ve e-posta, mobil video gibi trendler mobil uygulamaların artarak geliştirilmesini sağlayacaklar. Bu noktada, her geliştirme platformunda olması gerektiği gibi mobil uygulama platformlarında da güvenli uygulama geliştirme tekniklerine ihtiyaç var.

Mobil uygulama pazarı değişime müsait gözükmesine rağmen üretilen uygulamaların o veya bu şekilde pazardaki akıllı cihazlarda uzun süre yaşayacağı unutulmamalı. Her durumda uygulamaların mobil uygulamalara özgü riskleri belirlenmeli ve güvenli geliştirilmeye çalışılmalı.

Aşağıdaki belge, mobil uygulamalar geliştirilirken dikkat edilmesi gereken güvenlik kontrollerinden bahsetmektedir. 

 

Hassas Bilgi Tanımı

Belge içinde hassas bilgi olarak sınıflandırılan bilgiler aşağıda tanımlanmaya çalışılmıştır. Bir veri tipinin hassaslığı hakkında şüpheye düşüldüğünde proje analisti ile görüşülüp, bilgi güvenliği birimleri ile iletişime geçilmelidir.

• Aboneye ait muhtelif haberleşme bilgileri (CDR) (Abone hangi tarihte, kiminle, nereden, hangi saatte, ne kadar süreyle görüştüğü)
• Konum bilgisi
• Şifre, PIN, PUK
• OTP onay kodları
• Kimlik ve özel bilgileri (adres, kredi kartı numarası, rehber kayıtları, fatura bilgileri, TC kimlik numarası vb.)

 

Güvenlik Noktaları

Uygulama

Native mobil uygulamalar genellikle uzak servisleri kullanırlar. Uygulama sunucularında yaşayan bu uygulamaların geliştirilmelerinde web uygulama güvenlik prosedürlerine (girdi denetimi, oturum yönetimi, yetkilendirme, veri güvenliği v.b.) uyulmalıdır

Kayıt Tutma

Logcat, NSLog veya diğer client mobil uygulamalarda kayıt alınırken hassas bilgilerin yazılmaması gerekmektedir.
Debug Amaçlı Kodların veya Gereksiz Metotların Kaldırılması
Ters mühandislik ile uygulama kodları tekrar oluşturulabileceğinden test ortamlarında DEBUG amaçlı yazılmış kodların prod ortamı için uygulama içeriden çıkarılması gerekmektedir.

Veri Güvenliği
Mobil uygulamalar ve web servisleri ile HTTPS kullanarak haberleşmelidir. SSL haberleşme yapılırken native kod tarafında kesinlikle validation kuralları by-pass edilmemelidir. Örneğin Android cihazlarda özel HostnameVerifier’lar, iOS’de NSURLAuthenticationMethodServerTrust gibi yapılar kullanılmamalıdır. 
Genellikle bu bypass teknikleri test sistemlerinde self-signed SSL sertifikalara sahip uygulama sunuculara sorunsuz bağlanmak için uygulanmaktadır. Prod sistemlerinde bu bypass teknikleri kesinlikle uygulamadan kaldırılmalıdır. Aşağıda Android sistemi için güvensiz bir SSL bağlantı kod parçası gösterilmektedir.

 

AllowAllHostnameVerifier aahv = new AllowAllHostnameVerifier();
URL url = new URL("https://selfsigned.sslserver.com/");
HttpsURLConnection con = (HttpsURLConnection) url.openConnection();
con.setHostnameVerifier(aahv);
readStream(con.getInputStream());

 

 

Anti Kaba Kuvvet

Özellikle kimlik doğrulama işlemlerinde deneme-yanılma işlemlerini engellemek amacı ile anti kaba kuvvet mekanizmaları gerçekleştirilmelidir. Belirlenebilecek hatalı belirli deneme sayısından sonra native tarafta CAPTCHA gösterilmesi örnek bir kaba kuvvet önleme tekniğidir. Bu mekanizma kesinlikle Session'a bağlı olmamalı, hem IP ve hem de kullanıcı adına bağlı olmalıdır. Bir başka deyişle, kullanıcı adının sabit tutulup şifrelerin değiştirilmeye çalışılması veya kullanıcı adının değiştirilerek şifrelerin sabit tutulması gibi saldırı metotların engellenmeleri gerekmektedir.
Anti kaba kuvvet sadece kimlik doğrulama fonksiyonlarında değil, hassas olabilecek bütün işlemlerde gerçeklenebilir. Örneğin fatura ID'lerinin birer birer arttırılarak gerçek bir fatura ID'si bulunması veya arka tarafta uzun zaman alan bir işlemin defalarca çağırılabilmesi, v.b.

Uygulama Bileşenleri veya Uygulamalar Arası Güvenli İletişim
Özellikle Android uygulamalarda broadcast edilen verilerin güvenliği çok önemlidir. Intent'lerin broadcast edilmesi uygulamalar arası iletişimin bir yöntemidir. Bu şekilde sisteme gönderilen Intent’ler, doğru Intent Filter’lar yardımı ile Broadcast Receiver’ler tarafından yakalanırlar ve işlenirler.
Bu şekilde veri ve bilgilendirme iletişiminde dikkatli olunması gereklidir. Çünkü, gönderilen veriler veya bilgilendirmeler herhangi bir uygulama tarafından kayıt edilmiş Broadcast Receiver tarafından da yakalanabilirler. Uygulamalar bu durum söz konusu olduğunda, broadcast edilen Intent'ler ile hassas veriler göndermemelidirler veya permission'lar bu Intent'lerin her filter tarafından alınamayacağı şekilde implement edilmelidir.

SQL Injection, XSS
Client side veritabanını kullanan native uygulamalar sql sorgularında kesinlikle Prepared Statement kullanmalıdırlar. Ayrıca webview gibi html/javascript yüklenebilecek bileşenler kullanıldığında mutlaka bu yapılarda render edilecek verilerin uygun encode işleminden geçirildiğine emin olunmalıdır. Veriler javascript yapıları içine gidecek ise Javascript encoding, HTML içerisine gidecek ise HTML encoding, URL içine parametre olarak gidecek ise URL encoding, HTML attribute içerisinde gidecek ise HTML Attribute encoding uygulanmalıdır [6].
Referanslar:

https://www.owasp.org/index.php/IOS_Developer_Cheat_Sheet
http://www.webguvenligi.org/docs/Guvenli_Android_Gelistirme_Ipuclari.pdf
http://code.google.com/p/owasp-development-guide/
https://www.owasp.org/index.php/Top_10_2013-A4-Insecure_Direct_Object_References
https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet
https://www.owasp.org/index.php/OWASP_Java_Encoder_Project
 

Geleceği Yazanlar Ekibi olarak bu eğitim içeriğimizi oluşturan Bedirhan Urgun'a çok teşekkür ederiz.