Bir önceki yazımızda OWASP’ın güvenlik standartları katmanlarını ve bunların hangi mobil uygulamalar için uygulanması gerektiğini incelemiştik. Eğer o yazıyı henüz okumadıysanız buraya tıklayarak okuyabilirsiniz. Zira bu bölümde anlatacaklarımız o yazının devamı niteliğindedir.
Bu bölümde ilk dört kategorideki güvenlik standartlarını inceleyeceğiz:
- V1: Architecture, Design and Threat Modeling Requirement
- V2: Data Storage and Privacy Requirements
- V3: Cryptography Requirements
- V4: Authentication and Session Management Requirements
— Ek Bilgi Başlangıcı—
Bu yazımızda bolca hassas veri diyeceğiz. O yüzden önce hassas veri nedir onu bir inceleyelim. Hassas veriler genellikle üç ana kategoride incelenir:
- Personally Identifiable Informations (PII)
PII, bir kişinin cep telefonu numarasından, konum bilgisine, T.C. Kimlik numarasından sosyal medya hesap bilgilerine kadar bir kişinin teşhis edilebilmesini sağlayan hassas verilerdir.
- Protected Health Informations (PHI)
PHI, bir kişinin tüm gizli sağlık verileridir. Bunlar bir hastanedeki tahlillerden telefonunuzdaki sağlık uygulamasındaki kalp atış ritimlerinizin bilgisine kadar uzanabilir.
- Payment Card Data (PCI-DSS)
PCI-DSS, aynı zamanda bir güvenlik standartı olup, insanların ödeme için kullandığı yöntemlerin (kredi kartı vb.) bilgileridir. Bu bir banka kartının bilgisinden kredi kartına ve hatta paypal kartın bilgisine kadar geniş bir yelpazeyi kapsayabilir.
— Ek Bilgi Sonu —
V1: Architecture, Design and Threat Modeling Requirement
Güvenlik, bir yazılım geliştirdikten sonra ona bir sızma testi veya güvenlik testi uygulamak değildir. Güvenliğin daha analiz aşamasında mimariye, dizayna ve yazılım geliştirme sürecinin tamamına implemente edilmesi gerekir. Zaten bunun için koca bir kavram vardır. Secure Software Development Life Cycle (SSDLC). Yani Güvenli Yazılım Geliştirme Yaşam Döngüsü. Bunun ortaya çıkmasındaki en temel motivasyon çoğu güvenlik mimarisinin projenin en başında kurgulanma ihtiyacı olmasıdır.
Eğer güvenlik mobil uygulama geliştirme süreçlerinin en başında kurgulanmaz ise mimarideki ciddi hatalar çok büyük zafiyetlere ve yine çok büyük maliyetlere sebep olabilir. Sırf güvenlik hiç implemente edilmedi diye staging’e çıkmış bir projenin sil baştan yapılmak zorunda kaldığına tanık oldum. Acı tecrübelerle bu süreci deneyimlemeye gerek yok.
Günümüzde birçok mobil uygulama remote servislerin birer client’ı gibi davranır. Mobil uygulama ne kadar güvenli olursa olsun, remote servislerde aynı standartlarda güvenlik sağlamıyorsa yapılanlar sadece belirli bir aşamaya kadar koruma sağlayacaktır.
Bu kategorideki tüm standartlar bir mobil uygulamanın architecture (mimari) ve design (dizayn-tasarım) aşamasındaki ihtiyaçlarını giderecektir. O yüzden bu kategorideki standartları test listesine almak anlamsız olacaktır. Onun yerine bir kontrol listesi hazırlamak daha mantıklı olacaktır. Standartları incelemeye başlayalım.
MSTG-ARCH-1: All app components are identified and known to be needed.
Bu güvenlik standardı hem MASVS-L1 hem MASVS-L2 için geçerlidir.
Mobil uygulamanın tüm componentleri (bileşenleri) tanımlanır ve bunların neler olduğu, neden ihtiyacımız olduğu gibi bilgiler bilinir hale getirilir. Mobil uygulamada varlığı unutulmuş veya neden var olduğu bilinmeyen bir bileşeni olmaması gerekir. Birçok hacking vakası unutulan bileşenlerden veya gerçekten ihtiyaç olmayan bileşenlerden kaynaklanabiliyor. Amacımız tüm bileşenleri tanımlamak ve onlar hakkında tüm bilgilere sahip olmaktır.
MSTG-ARCH-2: Security controls are never enforced only on the client side, but on the respective remote endpoints.
Bu güvenlik standardı hem MASVS-L1 hem MASVS-L2 için geçerlidir.
Birçok mobil uygulamanın remote servislerin birer client’ı gibi davrandığından bahsetmiştik. Bu aşamada güvenlik kontrollerini sadece mobil uygulamaya değil, bağlantıda olacağı tüm endpointlere uygulamak gerekiyor. Mobil uygulamalar üzerine hangi güvenlik çalışmasını yaparsanız yapın, birlikte çalıştıkları endpointler kadar güvenli olacaklardır.
MSTG-ARCH-3: A high-level architecture for the mobile app and all connected remote services has been defined and security has been addressed in that architecture.
Bu güvenlik standardı hem MASVS-L1 hem MASVS-L2 için geçerlidir.
Mobil uygulama mimarileri genellikle 3 katman üzerinde oluşturulur:
- Presentation Layer
- Business Layer
- Data Access Layer
Mobil uygulamanın yazılım mimarisi oluşturulurken tüm bu katmanlardaki güvenlik adımları en baştan tasarlanmalıdır. Yine mobil uygulama ve birlikte çalışacakları tüm servislerin güvenlik gereksinimleri tek tek ele alınmış olmalı, bunlarla ilgili güvenlik kontrol listesi oluşturulmalıdır.
MSTG-ARCH-4: Data considered sensitive in the context of the mobile app is clearly identified.
Bu güvenlik standardı hem MASVS-L1 hem MASVS-L2 için geçerlidir.
Güvenliğin en temel amaçlarından biri hassas verileri korumaktır. Mobil uygulama geliştirme aşamasında tüm adımlardaki hassas veriler tek tek tanımlanmalı, bu hassas veriler ile ilgili bir diyagram oluşturularak her bir verinin hassasiyet derecesi belirlenmelidir.
Ayrıca her hassas verinin mobil uygulamanın hangi bileşenleri tarafından ve hangi endpointler tarafından erişilebilir olacağı tanımlanarak bu diyagrama eklenmelidir.
MSTG-ARCH-5: All app components are defined in terms of the business functions and/or security functions they provide.
Bu güvenlik standardı MASVS-L2 için geçerlidir.
Uygulamanın tüm bileşenleri, işin gerekliliklerine göre sağladığı fonksiyonları ve bunlarla ilişkili olacak tüm güvenlik fonksiyonlarının tanımlanması gerekir. Aslında her adımda ortak bir amaç var. Tanımlanmamış ve bilinmeyen hiçbir nokta bırakmayarak saldırı yüzey alanına hakim olmak ve ona göre güvenlik tasarımını yapmak.
MSTG-ARCH-6: A threat model for the mobile app and the associated remote services has been produced that identifies potential threats and countermeasures.
Bu güvenlik standardı MASVS-L2 için geçerlidir.
Bir önceki yazılımızda MASVS-L2 için bir threat model (tehdit modeli) oluşturulması gerektiğinden bahsetmiştik. Yukarıdaki adımlar tamamlandıktan sonra artık rahatlıkla bir tehdit modeli çıkarabiliriz. Tehdit modelini hem mobil uygulama ve onun bileşenleri için hem de ilişkili olduğu tüm endpointler için çıkarmak gerekiyor.
Bu tehdit modeli sadece tehditleri değil, onlara karşı önlemleri de içermelidir.
Not: Tehdit modeli oluşturma ile ilgili ayrı bir doküman yayınlayacağım.
MSTG-ARCH-7: All security controls have a centralized implementation.
Bu güvenlik standardı MASVS-L2 için geçerlidir.
Merkezileştirme. Bu kelimenin sihri hem yönetim kolaylığı sağlamasında hem de güvenlik önlemlerinin tüm bileşenlere uygulanmasını sağlamasında. Tüm güvenlik kontrollerimizi bir liste haline getirdikten sonra bunları merkezi bir şekilde hem yönetebilir hem denetleyebilir hale gelmemiz gerekiyor.
Bu aşama third party (üçüncü party) library (kütüphane), extension (uzantı) ve plugin (eklenti) gibi ek teknolojilerin de takibini içeriyor. Development süreçlerinde genellikle en uyumlu versiyonlar tercih edilir. En güvenli olanlar değil. Bu nedenle özellikle third party paketlerin çok iyi takip edilmesi gerekir.
MSTG-ARCH-8: There is an explicit policy for how cryptographic keys (if any) are managed, and the lifecycle of cryptographic keys is enforced. Ideally, follow a key management standard such as NIST SP 800–57.
Bu güvenlik standardı MASVS-L2 için geçerlidir.
Mobil uygulamada kriptografik bir key kullanılacaksa o keylerin bir yönetimi olması gerekiyor. Yazılım sektöründe her şeyin bir yaşam döngüsü vardır. Kriptografik keylerin de bir yaşam döngüsü vardır. Bunların yönetimi ile ilgili genel kabul görmüş bir standart da var. Keylerin yönetimi için NIST’in SP 800–57 standartını direkt olarak uygulamanız çok faydalı olacaktır. İncelemek isteyenler için:
MSTG-ARCH-9: A mechanism for enforcing updates of the mobile app exists.
Bu güvenlik standardı MASVS-L2 için geçerlidir.
Birçok hacking vakası güncellenmeyen uygulamalar yüzünden oluyor. Mobil uygulamalar için yıl içerisinde birçok güvenlik iyileştirmesi paketi yayınlanabilir. Bu nedenle özellikle güvenlik iyileştirmeleri içeren paketlerin güncellemeye zorlaması için bir mekanizma kurulması gerekir.
Bu konuya biraz da kendi yorumumu katmak istiyorum. Sadece client tarafında mobil uygulamanın güncellemesini sağlamak yetmez. Aynı zamanda development sürecinde kullanılan tüm bileşenlerin ve tüm sistemlerin de güvenlik güncellemeleri için bir mekanizma kurulması gerekiyor.
MSTG-ARCH-10: Security is addressed within all parts of the software development lifecycle.
Bu güvenlik standardı MASVS-L2 için geçerlidir.
Yazılım geliştirme süreçleri günümüzde Software Development Life Cycle (SDLC) ile anılır ve düzenlenir. Ancak gerçek anlamda güvenli yazılım geliştirme yapmak istiyorsanız kullanmanız gereken metodoloji Secure Software Development Life Cycle (SSDLC)’dır. Yani güvenliğin yazılım geliştirme sürecinin tüm adımlarına implemente edilmesi gerekmektedir.
MSTG-ARCH-11: A responsible disclosure policy is in place and effectively applied.
Bu güvenlik standardı MASVS-L2 için geçerlidir.
Günümüzde dünyanın en büyük şirketleri dahi veri sızıntıları ile karşı karşıya kalıyor. Yani ben buradaki adımların hepsini yaptım artık bana hiçbir şey olmaz demek doğru değildir. O yüzden olası bir veri sızıntısı (veri ifşası) durumu için doğru bir politika ve prosedür oluşturup bunun en şeffaf şekilde uygulandığından emin olunması gerekir.
MSTG-ARCH-12: The app should comply with privacy laws and regulations.
Bu güvenlik standardı hem MASVS-L1 hem MASVS-L2 için geçerlidir.
Regülasyonlar ve kanunlar günümüzde bilgi güvenliği süreçlerinin ayrılmaz bir parçasıdır. Bulunan sektöre ve ülkeye göre bu regülasyon ve kanunlar değişiklik gösterse de değişiklik göstermeyecek tek bir konu var. O da bu regülasyon ve kanunlara uyumlu olma zorunluluğudur. Mobil uygulamamız bulunduğumuz sektörün ve ülkelerin yasa ve regülasyonlarına mutlaka uyumlu olmalıdır.
V2: Data Storage and Privacy Requirements
Mobil uygulamalar üzerinde çalıştığı cihazların genellikle kişisel amaçlı yoğun kullanımı nedeniyle birçok kişisel verinin olduğu noktalara dokunması gerekebilir. Bu nedenle kişisel verilerin korunması, mobil uygulamalar söz konusu olunca ayrı bir önem kazanmaya başlıyor.
Doğru mimari kurgulanmaz ise mobil uygulamamız yüzünden birçok kişisel veri açığa çıkabilir. Bunu sadece saldırı sonucu olacakmış gibi düşünmeyin. Aynı zamanda istem dışı olarak da veri sızıntıları olabilir. Örneğin mobil uygulamamız erişmemesi gereken keyboard cache’lerine (klavye ön belleği) ulaşıyor olabilir.
Bir diğer husus da mobil cihazların diğer cihazlara göre çalınması veya kaybolması durumlarının daha kolay olması. Çalınan mobil cihazlara fiziki erişimi olan saldırganlar doğru yapılandırılmamış uygulamaları kullanarak içindeki verilere kolaylıkla erişebiliyor.
Bu bölümde ise cihaz çalınsa da bizim uygulamamız üzerinden bir problem yaşanmayacak önlemlerden bahsedeceğiz. Belki de en önemli bölümlerden birisi de burası diyebilirim. Hadi başlayalım.
MSTG-STORAGE-1: System credential storage facilities need to be used to store sensitive data, such as PII, user credentials or cryptographic keys.
Bu güvenlik standardı hem MASVS-L1 hem MASVS-L2 için geçerlidir.
Mobil cihazlar genellikle üzerinde bir işletim sistemi yüklü halde gelirler. Bu bir iOS, Android veya yeni yeni piyasada yer edinmeye başlayan HarmonyOS de olabilir. İşletim sistemleri kullanıcıların isteklerini yerine getirebilmek adına birçok veriye erişmek durumundadır. Aynı şekilde mobil uygulamalar da birçok veriye erişmelidir. Her işletim sisteminin kendisine ait bir credential storage metodologisi vardır.
PII denilen kişisel verilerin korunması için o işletim sistemine ait credential storage metodolojisinin kullanıcı parolaları ve kriptografik key’ler gibi hassas ve önemli veriler için uygulanması gerekir. Mobil cihazlarda sırf bu hassas verileri tutmak için bir credential storage facilities bulunmaktadır ve verilerin burada tutulması gerekir.
MSTG-STORAGE-2: No sensitive data should be stored outside of the app container or system credential storage facilities.
Bu güvenlik standardı hem MASVS-L1 hem MASVS-L2 için geçerlidir.
Mobil cihaz üzerinde sadece bizim uygulamamız çalışmıyor. Aynı zamanda yüzlerce uygulama, binlerce servis çalışıyor. Bu yüzden tüm hassas verilerimizi app içinde tutmamız gerekiyor. Mobil uygulamaların kendilerine ait bir “app container”ı olur. Ve tüm hassas verilerin ya bu app container içerisinde ya da “system credential storage facilities” içerisinde tutulması gerekir.
Bu yapılmadığı takdirde diğer uygulamaların bizim uygulamamızın erişip store ettiği kişisel verilere erişmesi an meselesidir. Hele bir de o cihazda facebook yüklüyse :)
MSTG-STORAGE-3: No sensitive data is written to application logs.
Bu güvenlik standardı hem MASVS-L1 hem MASVS-L2 için geçerlidir.
Mobil uygulamalarda application logs çok çeşitli amaçlar için kullanılabilir. Application logs aynı zamanda kolaylık sağladığı için sık sık kullanılabilir. Ancak burada dikkat edilmesi gereken çok önemli bir husus var. O da herhangi bir kritik veriyi, bilgiyi veya ipucu dahi olabilecek bir şeyi application loglarına yazmamamız gerekiyor.
Yazdığımız tüm logların tıpkı daha önce yaptığımız hassas veri sınıflandırması envanter çalışması gibi incelenmesi, sınıflandırılması ve değerlendirilmesi gerekir.
MSTG-STORAGE-4: No sensitive data is shared with third parties unless it is a necessary part of the architecture.
Bu güvenlik standardı hem MASVS-L1 hem MASVS-L2 için geçerlidir.
Günümüzde bir mobil uygulamanın her şeyi kendi başına yapması ütopik bir durum olacaktır. Artık neredeyse her şey servis olarak sunuluyor ve bir çok mobil uygulama yapımcısı bu servisleri kullanıyor.
Üçüncü parti olarak kullandığımız servislerle zaman zaman veri paylaşmamız da gerekebilir. Eğer mimarinin değişmez ve vazgeçilmez parçası değilse hiçbir hassas veriyi üçüncü partilerle paylaşmamalıyız. Ancak mimarinin önemli bir parçası olan ve mutlaka hassas veri paylaşımında bulunmamız gereken üçüncü parti bir servis var ise mutlaka ve mutlaka o veriyi nasıl güvenli olarak paylaşacağımızı da kurgulamamız gerekecektir.
MSTG-STORAGE-5: The keyboard cache is disabled on text inputs that process sensitive data.
Bu güvenlik standardı hem MASVS-L1 hem MASVS-L2 için geçerlidir.
Mobil cihazlar içlerinde bulunan sanal klavyelerin cache’ini tutar. Bunun amacı en doğru kişiselleştirmeyi sunabilmektir. Örneğin size otomatik tamamlama özelliği sunmak veya otomatik doldurma özelliği sunmak gibi. İşletim sisteminin bunu tutuyor olması bizim mobil uygulamamızın da tutması gerektiği anlamına gelmez.
Yine buna özel bir çözüm veya geliştirme sunmuyorsak default olarak uygulamamızda keyboard cache özelliğinin kapalı olması gerekir. Eğer bu özelliği kullanmanız gerekiyorsa ona özel güvenlik önlemleri alınması gerektiğini de unutmayın.
MSTG-STORAGE-6: No sensitive data is exposed via IPC mechanisms.
Bu güvenlik standardı hem MASVS-L1 hem MASVS-L2 için geçerlidir.
Android IPC (inter-process communication) mechanism adı verilen bir teknoloji sunuyor. Bu teknolojinin amacı android’in farkı tiplerdeki komponentlerinin birbirleri ile iletişim kurmasını sağlamaktır. Özellikle bu mekanizma yüzünden herhangi bir hassas verinin sızıp sızmadığından emin olmamız gerekiyor. Bu konu hakkında daha detaylı bilgi isterseniz Google’ın şu dokümanını inceleyebilirsiniz:
MSTG-STORAGE-7: No sensitive data, such as passwords or pins, is exposed through the user interface.
Bu güvenlik standardı hem MASVS-L1 hem MASVS-L2 için geçerlidir.
Mobil uygulamaların kullanıcı ile etkileşime geçtiği alanı user interface’dir (kullanıcı arayüzü). Burası direkt olarak elle tutulabilen, gözle görülebilen alandır. Mobil cihazlarımızı hayatımızın her alanında kullanıyoruz. Belki cihazımızı kullanırken etrafımızda birçok insan olabilir. Veya cihazımızı bir televizyon veya monitöre yansıtıp o şekilde kullanıyor olabiliriz. Parola, pin veya bunlara benzer hiçbir hassas veriyi kullanıcı ara yüzünde direkt olarak sergilememiz, maskeleme yaparak göstermemiz gerekir.
MSTG-STORAGE-8: No sensitive data is included in backups generated by the mobile operating system.
Bu güvenlik standardı MASVS-L2 için geçerlidir.
Mobil cihazlar taşınabilir oldukları kadar hızlı zarar görebilir, kaybolabilir veya çalınabilir cihazlardır. Bu durumlar için kullancıların sürekli olarak cihaz yedekleri işletim sistemi tarafından oluşturulur.
Mobil uygulamaların genelde konfigürasyonlarının yer aldığı manifest tarzı bir dosyaları olur. (İşletim sistemine göre değişiklik göstermektedir) Bu dosyalarda verilerle ilgili tercihlerimizi de belirtebiliriz. Özellikle işletim sistemlerinin alacağı backuplarda uygulamamıza ait ve onun eriştiği kullanıcılara ait hassas verilerin bu backuplara dahil edilmemesi gerektiğini belirtmemiz gerekir.
Sonuç olarak işletim sistemi tarafından alınan yedeklere hiçbir şekilde hassas verilerin dahil olmaması gerekir.
MSTG-STORAGE-9: The app removes sensitive data from views when moved to the background.
Bu güvenlik standardı MASVS-L2 için geçerlidir.
Günümüzde birçok cihaz multitasking çalışabilme kabiliyetine sahiptir. Yani arka planda birden fazla görevi yerine getirebilirler. Bu da kullanıcıların uygulamaları arkaplanda çalışır durumda bırakması olanağını sağlar.
Örneğin bir parola yöneticisi uygulamamız olduğunu düşünelim. Bu uygulama içinde birçok kayıtlı parola olsun. Kullanıcı bu parolalardan birini görüntülemek istediğinde göz işaretine bastığını varsayalım. gördükten sonra o view açık bir şekilde uygulamayı arkaplana attığında tüm hassas verilerin tekrar görüntülenemez hale gelmesini sağlamamız gerekiyor. Hatta sadece view (görünüm) olarak koruma önlemi almamız yetmez, arkaplanda çalışan uygulamamızın hiçbir hassas veriyi paylaşmadığından emin olmalıyız.
MSTG-STORAGE-10: The app does not hold sensitive data in memory longer than necessary, and memory is cleared explicitly after use.
Bu güvenlik standardı MASVS-L2 için geçerlidir.
Mobil uygulamalarda birçok variable (değişken) olur. Bunlar kullanım sırasında yaratıldığı anda RAM’de depolanmaya başlar. Yine mobil uygulamalar çalışmaya başlayınca RAM’de kendine belirli bir alan ayırarak burada birçok veri depolar ve onları kullanımlarına göre çağırır. Buraya kadar bir sorun yok.
Eğer RAM’de hassas veriler tutmamız gereken durumlar oluyorsa o verilerin kullanımı biter bitmez memory’den temizlenmeleri gerekir. Bu temizliğin doğru şekilde yapılmaması hassas verilerin sızmasına neden olabilir.
MSTG-STORAGE-11: The app enforces a minimum device-access-security policy, such as requiring the user to set a device passcode.
Bu güvenlik standardı MASVS-L2 için geçerlidir.
Mobil cihazların işletim sistemlerinde belirli policy’ler (politikalar) vardır. Örneğin device-access-security policy. Bu politikanın içerisinde bir pin veya parola belirleneceği zaman kullanıcının uyması gereken minimum gereksinimler de yer almaktadır. (Örneğin parolanız en az 8 karakterden oluşmalı ve bir küçük harf, bir büyük harf, bir sayı ile bir özel karakter içermelidir.)
Eğer uygulamanız kullancıdan bir parola belirlemek gibi hassas veri yaratan bir işlem yapmasını istiyorsa kesinlikle bu device-access-security-policy’ye uygun bir structure (yapı) kurmalısınız. Ve hatta kullanıcılara bunu enforce etmelisiniz.
MSTG-STORAGE-12: The app educates the user about the types of personally identifiable information processed, as well as security best practices the user should follow in using the app.
Bu güvenlik standardı MASVS-L2 için geçerlidir.
Güvenliği en zayıf halkası her zaman insan olmuştur. Ne kadar güvenli bir sistem kurarsanız kurun o sistem doğru kullanılmazsa o güvenlik önlemleri bir işe yaramayabilir. Bu nedenle uygulamanın güvenli bir şekilde nasıl kullanılacağı açık ve net bir şekilde tanımlanmalı ve bunlar kullanıcıya yine açık ve net bir şekilde anlatılmalıdır. Yeri geldiğinde kullanıcının bu önerileri takip edip etmediği de geri bildirimlerle kontrol edilmelidir.
Uygulamamızın işlenen tüm kişisel veriler hakkında kullanıcıya bilgi vermesi gerektiğini de unutmayalım.
MSTG-STORAGE-13: No sensitive data should be stored locally on the mobile device. Instead, data should be retrieved from a remote endpoint when needed and only be kept in memory.
Bu güvenlik standardı MASVS-L2 için geçerlidir.
Uygulamanızın yüklendiği cihaz bir başkasını sahip olduğu cihazdır. Aynı zamanda bu cihaz başka bir firmanın sahip olduğu bir işletim sistemi ile çalışıyor. Bu nedenle hiçbir sensitive data (hassas veri) local storage’da tutulmamalıdır. Bunun yerine uzak bir sunucudan sadece ihtiyaç olduğunda doğru authn ve authz süreçleri çalıştırılarak çağırılmalı ve sadece RAM’de tutulmalıdır. Yine birkaç madde önce bahsettiğimiz gibi RAM’de tutulan hassas verilerin uygun şekilde uygun zamanda temizlenmesi de gerekir.
MSTG-STORAGE-14: If sensitive data is still required to be stored locally, it should be encrypted using a key derived from hardware backed storage which requires authentication.
Bu güvenlik standardı MASVS-L2 için geçerlidir.
Bu madde aslında bir önceki maddenin devamı niteliğinde. Bazen bazı hassas veriler cihazın local storage’ında tutulmak zorunda kalabilir. Örneğin yetkilendirme için özel bir token oluşturup bunu belirli bir süre local storage’da tutmak zorunda kalabilirsiniz. Böyle bir durumda yani local storage’da hassas veri tutmak zorunda kaldığımızda mutlaka o veriyi authentication gerektiren bir şekilde encrypt (şifreleyip) edip o şekilde tutmamız gerektiğini unutmayalım.
Hatta o hassas veriye ihtiyaç kalmadığında local storage’dan mutlaka temizlenmelidir.
MSTG-STORAGE-15: The app’s local storage should be wiped after an excessive number of failed authentication attempts.
Bu güvenlik standardı MASVS-L2 için geçerlidir.
Mobil uygulamamıza ayrılan local storage’da çeşitli hassas veriler tuttuğumuz senaryoda ekstra güvenlik önlemleri de almamız gerekir. Oluşturduğumuz authentication sisteminde yine bizim belirleyeceğimiz bir süre içerisinde yine bizim belirlediğimiz bir sayıda yanlış giriş denemesi olursa app local storage’ını wipe etmemiz gerekir.
Yani birisi parolayı tahmin etmeye veya kırmaya çalışıyorsa app local storage’ını temizleyerek hassas verilere ulaşılma ihtimalini ortadan kaldırmalıyız.
V3: Cryptography Requirements
İnsanoğlu binlerce yıldır şifreleme metotları kullanarak verileri şifreliyor. İlk gerçek şifreleme örneklerine rastladığımız Spar… :) Konumuz bu değildi pardon. Şifrelemenin tarihçesini merak edenler için:
İnsanlar gerçekten de çok uzun zamandır şifrelemenin yani kriptolojinin nimetlerinden faydalanarak verileri gizlemeye ve onların bütünlüğünü korumaya çalışıyor. Değindiğimiz tüm konularda ortak bir şey var. O da CIA’in korunması. Yani Confidentiality (Gizlilik), Integrity (Bütünlük) ve Availability (Erişilebilirlik)
Peki bunu nasıl yapacağız? Elbette Cryptography ile. Hemen başlayalım.
Not: Bu bölümdeki tüm standartların tüm mobil uygulamalar için uygun olduğunu göreceksiniz.
MSTG-CRYPTO-1: The app does not rely on symmetric cryptography with hardcoded keys as a sole method of encryption.
Bu güvenlik standardı hem MASVS-L1 hem MASVS-L2 için geçerlidir.
Hardcoded yani uygulamanın kodlarına gömüşmüş bir key ile simetrik şifreleme yaparak bunu sabit olarak kullanmak. İşte güvenmemeniz gereken konu bu. Uygulamanın (mümkünse) hardcoded hiçbir key kullanmaması ve tek bir key’e bağımlı kalmaması gerekir.
Günümüzde işlemci güçlerinin inanılmaz artışı ile artık şifreleme metotlarının (eski ve yetersiz olanları) yetersiz kalabildiğini görüyoruz. Bu nedenle uygulamanızın hardcoded key ile simetrik şifreleme yaparak verileri korumasına güvenmemelisiniz.
MSTG-CRYPTO-2: The app uses proven implementations of cryptographic primitives.
Bu güvenlik standardı hem MASVS-L1 hem MASVS-L2 için geçerlidir.
Geçmişte geçerli olan bir şifreleme metodu artık günümüzde geçerli olmayabilir. Veya çok uzunca bir süre geçerli de olabilir. Bunun için her daim kriptografik anlamda kendini kanıtlamış, bilimsel çalışmaları, testleri vs. yapılmış ve çeşitli otoriteler tarafından kabul edilmiş şifreleme metotlarının uygulamamıza implemente edilmesi gerekir.
“Ahmet söylemişti bak bu şifreleme metodu güzel.” diyerek şifreleme metodu seçilmemelidir.
MSTG-CRYPTO-3: The app uses cryptographic primitives that are appropriate for the particular use-case, configured with parameters that adhere to industry best practices.
Bu güvenlik standardı hem MASVS-L1 hem MASVS-L2 için geçerlidir.
Şifreleme söz konusu olduğunda günümüz teknolojisinin hale çözemeyeceği şifrelemeler bile mevcuttur. Ancak sırf çok güvenli olsun diye çok zor çözümlenen metotlar kullanmak uygulamamızın aşırı yavaş çalışmasına ve hatta çalışamamasına da sebep olabilir.
Tam tersi durumu düşünelim. Uygulamamız hızlı çalışsın ve performans sorunu yaşamayalım diye seçtiğimiz mütevazı şifreleme metotları da verilerimizin deşifre olmasına neden olabilir.
Her işte olduğu gibi burada da analiz ile business’ın (işin) ihtiyaçlarını bilmek çok önemlidir. OWASP’ın standartını birebir Türkçeye çevirdiğimizde karşımıza şu cümle çıkıyor:
Uygulama, sektörün en iyi uygulamalarına uyan parametrelerle yapılandırılmış, belirli bir kullanım senaryosu için uygun olan şifreleme ilkelerini kullanır.
Uygulamanın yaptığı işe, çalışma şekline, ihtiyaçlarına ve kullanım senaryosuna en uygun şifreleme metodolojilerinin kullanılması gerekir.
MSTG-CRYPTO-4: The app does not use cryptographic protocols or algorithms that are widely considered deprecated for security purposes.
Bu güvenlik standardı hem MASVS-L1 hem MASVS-L2 için geçerlidir.
Diğer güvenlik standartlarını düşündüğümüzde bu bölüm sürekli olarak kendi içinde tekrar düşüyor gibi gözükebilir. Aslında ben de aynı şeyi hissediyorum. Burada yer alan 6 maddeyi belki 2 maddede yazmak mümkün. Ancak bunların bir de testinin ve checklistinin olacağını unutmamak gerekiyor. O yüzden bu kadar üstüne düşerek ve uzatarak bunları oluşturduklarını düşünüyorum.
Zaman geçtikçe bazı şifreleme protokolleri ve algoritmaları ömürlerini tamamlarlar. Artık kullanımdan kaldırılmaya başlanıp destekleri de sonlandırılır. Bu madde uyarınca uygulamanızda bu tarz bir protokol veya şifreleme kullanmamanız gerekir.
MSTG-CRYPTO-5: The app doesn’t re-use the same cryptographic key for multiple purposes.
Bu güvenlik standardı hem MASVS-L1 hem MASVS-L2 için geçerlidir.
Kolaylık olsun diye yapılan birçok şey güvenlik zafiyetlerine sebep olabilir. Örneğin kendinize zor ama ezberlediğiniz bir parola belirlediniz. Sonra gidip tüm hesaplarınızda bu parolayı kullanırsanız bir problem var demektir. Çünkü kullandığınızı site, servis veya sistemlerden biri veri sızıntısı ile karşılaşabilir ve parolanızı kaptırabilirler. Bu durumda diğer tüm hesaplarınız da tehlike altına olacaktır. B yüzden tüm servis ve sistemlerde benzersiz ve birbirinden tamamen farklı parolalar kullanmak gerekir.
Aynısını uygulamamıza uyarlayalım. Oluşturduğunuz bir kriptografik anahtarı (cryptographic key) tekrar tekrar farklı yerlerde ve farklı amaçlarda kullanırsanız az önce bahsettiğimiz tehlikeye benzer bir tehlike ile karşı karşıya kalırsınız. Her kriptografik anahtar sadece tek bir amaç için kullanılmalı ve tekrar kullanımından kaçınılmalıdır.
MSTG-CRYPTO-6: All random values are generated using a sufficiently secure random number generator.
Bu güvenlik standardı hem MASVS-L1 hem MASVS-L2 için geçerlidir.
Uygulamamızda bol bol sayı yaratmamız çok olasıdır. Bunlar User ID olabilir. Download için file name olabilir. Türetebileceğimiz binlerce ihtimal mevcut. Yaratacağımız değerleri ardışık yaratmak elbette çok daha düzenli gelebilir. Ancak bu bir sonraki hamlenin ne olacağının tahmin edilebilir hale gelmesine neden olur.
Eğer bir değer yaratmanız gerekiyorsa bunu random yaratmanız ve güvenliğinden, stabilitesinden emin olduğunuz bir random generator algoritması ile yapmanız gerekir. Bu sayede uygulamanızda kötü niyetli bir şeyler denemek isteyenlere karşı önleminizi almış ve tahmin edilmesi daha zor bir hale gelmiş olursunuz.
V4: Authentication and Session Management Requirements
Günümüzde artık kullanıcısı olmayan bir mobil uygulama pek kalmadı diyebiliriz. Kullanıcı olması demek o kullanıcının yaratılması (registration) ve kullanıcıların giriş yapması (login) anlamına gelir. V4'te kullanıcıların authentication (yetkilendirme) ve session management (oturum yönetimi) konuları üzerinde duracağız.
Doğru mimari birçok hacking vakasının önüne geçer. O yüzden her bölümün çok önemli olduğunu bir kez daha hatırlayalım. Güvenlik en zayıf halkamız kadar bizi korur.
MSTG-AUTH-1: If the app provides users access to a remote service, some form of authentication, such as username/password authentication, is performed at the remote endpoint.
Bu güvenlik standardı hem MASVS-L1 hem MASVS-L2 için geçerlidir.
Mobil uygulamalar sadece kendi üzerinde kullanıcı erişimi sağlamayabilir. Aynı zamanda remote bir endpointe de erişim sağlamak durumunda olabilirler. Böyle durumlarda eğer kullanıcıların remote bir endpointe erişmesi ve orada işlemler yapması gerekiyorsa sadece mobil uygulama için değil aynı zamanda o remote endpoint için de username/password veya benzeri bir authentication sistemi kurulması gerekir. Çünkü remote endpointlere sadece mobil uygulamanın değil başkalarının da erişebileceğini unutmayalım.
MSTG-AUTH-2: If stateful session management is used, the remote endpoint uses randomly generated session identifiers to authenticate client requests without sending the user’s credentials.
Bu güvenlik standardı hem MASVS-L1 hem MASVS-L2 için geçerlidir.
— Ek Bilgi Başlangıcı —
Eğer stateful session management ve stateful authentication konusunda bilgi sahibi değilseniz aşağıdaki kaynakları incelemenizi öneririm:
— Ek Bilgi Sonu —
Eğer stateful session management kullanıyorsanız remote endpointlerin kullanıcı requestlerini (isteklerini) kullanıcı credentiallarını (parola vb.) göndererek authenticate etmesindense rastgele generate edilen session identifiers aracılığıyla yapması gerekir. Bu sayede kullanıcının hassas verilerini taşıyarak riske atmak zorunda kalmayız.
MSTG-AUTH-3: If stateless token-based authentication is used, the server provides a token that has been signed using a secure algorithm.
Bu güvenlik standardı hem MASVS-L1 hem MASVS-L2 için geçerlidir.
Uygulamanızda stateless token-based authentication kullanmaya karar verirseniz, sunucunuzun güvenli bir algoritma tarafından imzalanmış bir token vermesini sağlamalısınız. Bu sayede hangi tokenlara güvenilip hangilerine güvenilmeyeceğini seçme imkânınız olur.
MSTG-AUTH-4: The remote endpoint terminates the existing session when the user logs out.
Bu güvenlik standardı hem MASVS-L1 hem MASVS-L2 için geçerlidir.
Token based olsun olmasın çok önemli bir konuyla karşı karşıyayız. Genellikle mobil uygulamalarda oAuth2 gibi token-based authentication metotları kullanılır. Hatta oAuth2 sektör standartı haline bile gelmiştir diyebiliriz. Bu tokenların bir ömrü olur. Bazen 1 saat bazen 1 hafta bazen 1 ay gibi. Eğer kullanıcı belirli bir süre inaktif olursa o sürenin sonunda token revoke edilir. Eğer kullanıcı son dakikalarda aktif olursa (revoke edilmeden önce) refresh token gibi teknolojiler sayesinde tekrar yeni bir token oluşturulup verilir ve süremiz yenilenir.
Burada önemli olan kullanıcı inaktif ise onu sadece logout etmek değil aynı zamanda token’ı da revoke etmek gerekir. Aynı senaryoyu kullanıcının kendisinin logout olduğu zaman için de düşünebiliriz. Kullanıcı logout olduğunda remote endpointin bir şekilde kullandığı yapıya göre var olan session’ı kapatması gerekir. Aksi takdirde logout olduğunu zanneden ama session’ı devam eden kullanıcılarla karşılaşırız.
MSTG-AUTH-5: A password policy exists and is enforced at the remote endpoint.
Bu güvenlik standardı hem MASVS-L1 hem MASVS-L2 için geçerlidir.
Güvenliğin en önemli parçalarından birisi de politika ve prosedürlerdür. Remote endpointlerin ve uygulamamızın tamamı için bir güvenli parola politikası oluşturulmalı ve bu politika her yerde uygulanarak kullanıma zorlanmalıdır. Bu standart gayet açık olduğu için başka bir açıklama yapmamıza gerek olmadığını düşünüyorum.
MSTG-AUTH-6: The remote endpoint implements a mechanism to protect against the submission of credentials an excessive number of times.
Bu güvenlik standardı hem MASVS-L1 hem MASVS-L2 için geçerlidir.
Saldırganların en çok ulaşmayı arzuladığı şeylerden biri kullanıcı parolaları veya credentiallardır. Bu yüzden genellikle brute force gibi saldırı çeşitleri ile sürekli parolaları elde etmeye veya tahmin etmeye çalışırlar. Bunun için önlem alınması çok önemlidir.
Remote endpointde belirlenen süre içerisinde belirlenen sayıdan fazla parola veya credential denemesi olduğunda ne yapılacağına karar verilmeli ve bu koruma mekanizması işletilmelidir. Burada kullanıcı hesabının geçici olarak askıya alınması, denemelerin yapıldığı IP adresinin belirli bir süre bloklanması, captcha çıkarılması, js challenge uygulanması veya rate limit uygulanması gibi bir çok metot kullanılabilir. Önemli olan bu metotlara uygulamanın ihtiyacına göre karar vermektir.
MSTG-AUTH-7: Sessions are invalidated at the remote endpoint after a predefined period of inactivity and access tokens expire.
Bu güvenlik standardı hem MASVS-L1 hem MASVS-L2 için geçerlidir.
Az önce MSTG-AUTH-4 maddesinde buna değindik aslında. Kullanıcıların kullanım alışkanlıkları ve aktif olduğu süreler analiz edilmeli. Daha sonra bu sürelere ve alışkanlıklara uygun bir şekilde “X süre boyunca aktif olunmaz ise token expire olmalı” kurgusu işletilmelidir. Bu sayede kötü niyetli kişilerin hesapları kazara da olsa ele geçirmesinin önüne geçmiş oluruz.
Bu aşamada en çok gelen soru token’ın süresi ile ilgili. Token süresi ne olmalı? Bu, işin ve sektörün dinamiğine göre çok değişecektir. Örneğin bir finans uygulamasında bu süre çok kısa iken mail uygulamasında çok uzun süre olabilir. O yüzden en doğru karar az önce bahsettiğimiz analiz ve incelemeler sonucunda ortaya çıkacaktır.
Güvenlik odaklı çalışan biri olarak o sürenin mümkün olan en kısa süre olmasını dilerim. :)
MSTG-AUTH-8: Biometric authentication, if any, is not event-bound (i.e. using an API that simply returns “true” or “false”). Instead, it is based on unlocking the keychain/keystore.
Bu güvenlik standardı MASVS-L2 için geçerlidir.
Biyometrik kimlik doğrulaması günümüzde birçok cihazda kullanılıyor. Örneğin bu yazıyı yazdığım Macbook’da klavyenin hemen sağ üst köşesinde bir parmak izi okuyucu var. Birçok işlemi onunla yapabiliyorum. Ancak şu ayrımın iyi yapılması gerekir. Biyometrik doğrulamalar event-bound olmamalıdır. Onun yerine sadece keychai/keystore gibi verilere erişmesi için kullanılmalıdır.
MSTG-AUTH-9: A second factor of authentication exists at the remote endpoint and the 2FA requirement is consistently enforced.
Bu güvenlik standardı MASVS-L2 için geçerlidir.
Parola politikanız ne kadar iyi olursa olsun kullanıcıların aynı parolayı birden fazla yerde kullanıp onları kaptırmalarına engel olamazsınız. Bu aşamada bizi kurtaracak olan mümkün olan her yerde 2FA (iki aşamalı doğrulama) özelliğini zorunlu olarak kullandırmamız olacaktır. Bu sayede saldırganlar parolaları ele geçirse dahi bir engelle daha karşılaşacaklardır.
MSTG-AUTH-10: Sensitive transactions require step-up authentication.
Bu güvenlik standardı MASVS-L2 için geçerlidir.
— Ek Bilgi Başlangıcı—
Step-up Authentication hakkında daha fazla bilgi almak isterseniz:
— Ek Bilgi Sonu —
Mobil uygulamamız oldukça hassas transactionlara sahip olabilir. Ancak bu transactionlar her an her dakika yapılmıyor da olabilir. O yüzden hem kullanıcı deneyimini daha kaliteli hale getirmek için hem de güvenliğin daha iyi sağlanabilmesi için hassas olan tüm transactionlarda step-up authentication metodolojisinin kullanılması gerekir. Daha detaylı bilgi almak isterseniz yukarıdaki ek bilgiyi inceleyebilirsiniz.
MSTG-AUTH-11: The app informs the user of all sensitive activities with their account. Users are able to view a list of devices, view contextual information (IP address, location, etc.), and to block specific devices.
Bu güvenlik standardı MASVS-L2 için geçerlidir.
Mobil uygulama güvenli olduğu kadar kullanıcılarada güvenlik ayarları yapabilme olanağı tanımalıdır. Mesela uygulamaya giriş yaptığım device’ların bir listesini görebilmeliyim. Aynı zamanda yine erişim sağladığım son IP adreslerinin, konumların veya benzeri bilgileri görebilmeli ve hatta gerekirse seçtiğim spesifik cihazlardan logout olma seçeneğine sahip olmalıyım. Ve yine gerekirse “tüm oturumları kapat” gibi seçenekler de olmalı. Ana fikri kaptınız değil mi?
MSTG-AUTH-12: Authorization models should be defined and enforced at the remote endpoint.
Bu güvenlik standardı hem MASVS-L1 hem MASVS-L2 için geçerlidir.
Authentication (Kimlik Doğrulama) ve Authorization (Yetkilendirme) birbirlerine çok yakın ancak bir o kadar da farklı kavramlardır. Authorization hakkında daha detaylı bilgi isterseniz aşağıdaki yazımı inceleyebilirsiniz.
— Ek Bilgi Başlangıcı —
— Ek Bilgi Sonu —
Authorization (Yetkilendirme) işlemlerinin bir modeli olmalıdır. Ve bu modelin bir diagrama dökülerek her adımının tek tek incelenmesi ve doğru model olduğunun kesinleştirilmesi gerekir. Ayrıca bu modelin uygulama dışında tüm remote endpointler için de uygulandığından emin olunmalıdır.
Yazımızın bu bölümünde V1: Architecture, Design and Threat Modeling Requirement, V2: Data Storage and Privacy Requirements, V3: Cryptography Requirements, V4: Authentication and Session Management Requirements konularını detaylı olarak inceledik.
Bir sonraki bölümde V5: Network Communication Requirements, V6: Platform Interaction Requirements, V7: Code Quality and Build Setting Requirements, V8: Resilience Requirements konularını detaylı olarak inceleyeceğiz.
Sorularınız ve düzeltme önerileriniz için iletişim: serhanw@pm.me
Kaynak:
