Görsel: Pixabay · Pixabay Lisansı
Temel varsayım
Mobil uygulama kullanıcının elindedir. Paketi açılabilir, trafiği izlenebilir, davranışı değiştirilebilir.
Bu yüzden güvenliğin tek güvenilir yeri sunucudur. İstemcide yapılan her kontrol, yalnızca kullanıcı deneyimi içindir.
Hata bir: gizli anahtarı uygulamaya gömmek
API anahtarları, veritabanı bilgileri ve üçüncü taraf gizli anahtarları uygulama paketine konulmamalıdır. Paket kolayca açılır ve içindeki metinler okunur.
Gizli anahtar gerektiren işlemler sunucuya taşınmalıdır. Uygulama, kendi sunucunuza konuşur; gizli anahtar orada kalır.
Hata iki: yetkiyi arayüzde kontrol etmek
Bir düğmeyi gizlemek o işlemi engellemez. Uygulamanın istek gönderdiği uç nokta hâlâ açıksa, istek doğrudan gönderilebilir.
Her uç nokta, çağıranın o işlemi yapmaya yetkili olup olmadığını kendi başına kontrol etmelidir. Bu kontrol atlandığında başkasının verisine erişim mümkün hale gelir.
Bu tuzağı kendi kod tabanlarımızda da denetledik; bir uç noktanın yetki kontrolünü çağıran katmana bırakması, sessiz ve ciddi bir açıktır.
Hata üç: hassas veriyi cihazda açık saklamak
Oturum belirteçleri ve kişisel veriler düz metin olarak cihaz depolamasına yazılmamalıdır.
Platformların sağladığı güvenli saklama mekanizmaları kullanılmalıdır. Bu mekanizmalar cihaz kilidine bağlı çalışır ve yedeklere açık metin sızdırmaz.
Hata dört: sertifika ve bağlantı gevşekliği
Tüm trafik şifreli bağlantı üzerinden akmalıdır. Geliştirme sırasında sertifika doğrulamasını kapatan ayarlar, üretim paketine sızarsa araya girme saldırılarına kapı açar.
Sürüm paketinde hata ayıklama ayarlarının kapalı olduğunu her yayından önce doğrulayın.
Hata beş: aşırı log
Hata ayıklama günlükleri üretimde kapatılmalıdır. Kullanıcı bilgisi, belirteç veya istek gövdesi log'a yazılırsa cihaz günlüklerinden okunabilir.
Kırılma raporlarına da kişisel veri göndermemeye dikkat edilmelidir.
Kontrol listesi
Pakette gizli anahtar var mı? Her uç nokta kendi yetkisini kontrol ediyor mu? Belirteçler güvenli depoda mı?
Sertifika doğrulaması açık mı? Üretimde log kapalı mı? Bu beş soru, en sık görülen açıkların büyük bölümünü kapatır.
Oturum yönetimi
Oturum belirteçlerinin ömrü sınırlı olmalı ve yenileme mekanizması bulunmalıdır. Süresiz belirteç, cihaz kaybedildiğinde kalıcı erişim demektir.
Kullanıcı çıkış yaptığında belirteç sunucu tarafında da geçersiz kılınmalıdır. Yalnız cihazdan silmek yeterli değildir.
Hassas işlemler öncesinde yeniden kimlik doğrulama istemek, çalınan cihaz senaryosunda önemli bir koruma sağlar.
Güncelleme zorlama mekanizması
Kritik bir güvenlik açığı kapatıldığında, eski sürümü kullanan kullanıcıları güncellemeye zorlayabilmeniz gerekir.
Bunun için uygulama açılışta sunucudan asgari sürüm bilgisini kontrol etmelidir. Sürüm eskiyse kullanıcıya güncelleme ekranı gösterilir.
Bu mekanizma ilk sürümde kurulmalıdır; sonradan eklenirse zaten eski sürümdeki kullanıcılara ulaşamazsınız.
Zorlamayı yalnız gerçekten gerekli olduğunda kullanın; her küçük güncellemede zorlama, kullanıcıyı uygulamadan uzaklaştırır.
Sık sorulanlar
Uygulamayı tersine mühendislikten tamamen koruyabilir miyim?
Hayır. Karartma ve bütünlük kontrolleri işi zorlaştırır ama imkansız kılmaz. Bu yüzden güvenlik kararları istemciye değil sunucuya dayandırılmalıdır.
Sızma testi ne zaman yapılmalı?
İlk yayından önce ve ardından yılda en az bir kez. Ödeme, kişisel veri veya kurumsal veri işleyen uygulamalarda bu döngü daha sık olmalıdır.
Uygulamada saklanan veriler şifrelenmeli mi?
Hassas veriler için evet ve bunun için platformların sağladığı güvenli saklama mekanizmaları kullanılmalıdır. Bu mekanizmalar cihaz kilidine bağlı çalışır ve yedeklere açık metin sızdırmaz.
