Yazı dizimizin birinci bölümünde temel konseptin ne olduğundan ve mobil uygulama güvenliği katmanlarından bahsettik. İkinci bölümde V1-V4 Standart aralığını inceledik. Şimdi ise üçüncü bölümde V5-V8 Standart aralığını inceleyeceğiz.
Bu bölümde son dört kategorideki güvenlik standartlarını inceleyeceğiz:
- V5: Network Communication Requirements
- V6: Platform Interaction Requirements
- V7: Code Quality and Build Setting Requirements
- V8: Resilience Requirements
V5: Network Communication Requirements
Yazımızın ilk bölümünde birçok mobil uygulamanın remote endpointlerin bir client’ı gibi çalıştığından bahsetmiştik. Eğer remote bir endpoint varsa, onunla bir “iletişim” var demektir. Ve bu iletişim “Network Communication” olarak ele alınır. Bu bölümde remote endpointler ile uygulamamız arasındaki iletişimin güvenliğine odaklanacağız. Hemen başlayalım.
MSTG-NETWORK-1: Data is encrypted on the network using TLS. The secure channel is used consistently throughout the app.
Bu güvenlik standardı hem MASVS-L1 hem MASVS-L2 için geçerlidir.
Bu konuyu açıklamadan önce SSL ve TLS’in ne olduğundan bahsetmeliyiz.
— Ek Bilgi Başlangıcı —
SSL ve TLS
SSL (Secure Socket Layer), sunucu ile istemci arasında şifrelenmiş bir bağlantı oluşturmak amaçlı kullanılan bir güvenlik standandartıdır.
SSL sertifikaları, public ve private olmak üzere iki adet anahtar içerir. Bu anahtarlar sunucu ve istemci arasında güvenli bağlantı oluşturmada kullanılacaktır. Ayrıca sertifikalar web sitesinin sahibine ait bilgileri de barındırır.
Sertifika sahibi olmak için web sunucusunun bir “Sertifika İmzalama İsteği (CSR)” oluşturması gereklidir. Bu CSR oluşturma süreci sunucuda public ve private anahtarların oluşturulmasını sağlayacaktır. Güvenilir bir sertifika sağlayıcısına gönderilen CSR dosyası, sunucuya ait public anahtarı barındırmaktadır. Sertifika otoritesi tarafından bu CSR dosyasına ait sertifikayı oluşturur ve bu sertifika web sunucusuna yüklenir.
SSL Katmanları:
Dört katmandan oluşur.
- SSL Record Protocol- SSL Change Cipher Spec Protocol- SSL Alert Protocol- SSL Handshake Protocol
SSL’ in iki önemli konsepti, SSL session ve SSL Connection’dır. SSL Bağlantısı: Peer-to-peer ilişkili, geçici ve bir oturumla ilişkili iletişimdir.
SSL Oturumu: İstemci ve Sunucu arasındaki birleşimdir. Oturumlar Handshake Protokolü ile oluşturulur. Oturumlar, birden fazla bağlantı arasında paylaşılabilen kriptografik güvenlik parametrelerinin tanımlanmasını sağlar. Oturumlar maliyetli olan her bağlantıda kullanılacak olan güvenlik parametreleri anlaşma işleminden kaçınmak için oluşturulmuştur.
TLS (Transport Layer Security), iki iletişim uygulaması arasında veri gizliliği ve veri bütünlüğü sağlayan 1999 yılında geliştirilen bir güvenlik protokolüdür.
TLS, web sitelerinin güvenli iletişiminin sağlanması amacıyla istemci ve alıcı arasında verilerin şifrelenmesini sağlayan, Netscape‘in SSL güvenlik protokolünden evrimleşmiştir.
SSL ve TLS HTTPS’in güvenlik temelini oluşturan protokollerdir.
SSL/TLS ve HTTP/HTTPS hakkında daha detaylı bilgi isterseniz şu yazıma göz atabilirsiniz:
TLS’in Özellikleri:
- Web Browser ile server arasında güvenli haberleşmeyi sağlar.
- Asymmetric cryptography algoritmasını kullanarak key üzerinden verileri şifreler.
- Veri şifrelemesinde HTTPS, SMTP, POP3, FTP gibi IP protokollerinin birçoğu tarafından desteklemektedir.
- Günlük yaşamımızda biz farkında olmadan ağ üzerinden VPN bağlantıları, VoIP, anlık mesajlaşma vb. gibi işlemlerin web tarayıcılarında veya uygulamalarda güvenli bir şekilde yapılmasını sağlar.
TLS Katmanları:
İki katmandan oluşur.
- TLS Record Protocol
- TLS Handshake Protocol
Handshake Protokolü ile sunucu ve kullanıcıların kimlik doğrulamaları yapılır. Handshake, veri iletişimi yapılmadan önce şifreleme algoritmaları ile şifreleme anahtarlarına izin verirken; Record Protocol bağlantının güvenli olmasını sağlar.
— Ek Bilgi Sonu —
TLS’i anladıktan sonra devam edebiliriz. TLS’in buradaki amacı uygulamamız ile remote server arasındaki iletişimi şifreleyerek güvenli hale getirmesidir. TLS’in günümüz itibariyle (Aralık 2020) minimum 1.2 versiyonunun kullanılması ve tüm iletişime doğru şekilde entegre edilmesi gerekir.
MSTG-NETWORK-2: The TLS settings are in line with current best practices, or as close as possible if the mobile operating system does not support the recommended standards.
Bu güvenlik standardı hem MASVS-L1 hem MASVS-L2 için geçerlidir.
TLS kullanımı her senaryoda beklenen şekilde mümkün olmayabiliyor. Bu nedenle TLS kullanırken güncel güvenlik önerilerine uyulması gerekir. Ancak bu önerilerin tamamına uyulamıyorsa bile ona en yakın senaryo uygulanmaya çalışılmalıdır.
MSTG-NETWORK-3: The app verifies the X.509 certificate of the remote endpoint when the secure channel is established. Only certificates signed by a trusted CA are accepted.
Bu güvenlik standardı hem MASVS-L1 hem MASVS-L2 için geçerlidir.
İş Encryption ve TLS’e gelince birçok uygulama çeşidi mevcuttur. Ancak burada sektör standartlarını uygulamak daha faydalı olacaktır. Sektör standartı da bize şunu söyler:
“Uygulama, güvenli kanal kurulduğunda remote endpointin X.509 sertifikasını doğrular. Yalnızca güvenilir bir CA tarafından imzalanan sertifikalar kabul edilir.”
Güvenilir bir CA tarafından imzalanmayan hiçbir sertifikanın kabul edilmemsi gerekir.
MSTG-NETWORK-4: The app either uses its own certificate store, or pins the endpoint certificate or public key, and subsequently does not establish connections with endpoints that offer a different certificate or key, even if signed by a trusted CA.
Bu güvenlik standardı MASVS-L2 için geçerlidir.
Sertifika kullanmak ve hatta güvenilir bir CA tarafından imzalanmış bir sertifika kullanmak dahi güvenlik için tamamen yeterli olmuyor. Çünkü kullanım ve implementasyon şekli de çok önemlidir.
Mobil uygulamanın kendi sertifika deposunu (certificate store) kullanması gerekir. Eğer bunu yapamıyorsa remote endpoint’in sertifikasını/public key’ini uygulamaya pinlemek gerekir. Bu sadece bize ait olmayan ve bir CA tarafından onaylanmış bir sertihika ile bile tehlikeye düşmeyiz.
Ancak Sertifika pinleme olaylarının da bypass edilebileceğini unutmamalıyız.
MSTG-NETWORK-5: The app doesn’t rely on a single insecure communication channel (email or SMS) for critical operations, such as enrollments and account recovery.
Bu güvenlik standardı MASVS-L2 için geçerlidir.
Bir mobil uygulamanın en kritik işlem kabiliyeti kişisel verileri alma ve işleme şeklidir. Kişisel veya hassas verilerin sızmasını engellemek için üye olma, cihaz ekleme veya hesap kurtarma, parola sıfırlama gibi işlemlerde mobil uygulamanın güvenli olmayan tek bir iletişim kanalına (e-posta, sms vb.) güvenmemesi gerekir. Bu tarz tüm hassas işlemler için özel bir akış tasarlanmalı ve birden fazla adıma bölünerek işletilmelidir.
MSTG-NETWORK-6: The app only depends on up-to-date connectivity and security libraries.
Bu güvenlik standardı MASVS-L2 için geçerlidir.
Yazılım geliştirme süreçlerinde birçok framework ve üçüncü parti kütüphaneler (library) kullanılır. Bunların kullanılması elbette doğaldır. Kimse sırf güvenli olsun diye oturup kendi framework’ünüzü geliştirmenizi beklemiyor. Ancak sizden beklenen bir şey var elbette :)
Kullanılacak tüm connectivity ve security kütüphanelerinin en güncel sürümlerinde kullanıldığından emin olmalısınız. Çünkü güncellenmemiş bir kütüphane yüzünden başınız ağrıyabilir.
V6: Platform Interaction Requirements
Şu ana kadar hep mobil uygulamamızın ve onun iletişimde olacağı remote endpointlerin güvenliğine odaklandık. Artık uygulamamızın üzerinde çalıştığı platformların güvenliğine odaklanma zamanımız geldi. Burada mobil uygulamamızın çalışacağı Android veya iOS platformunun güvenliğine odaklanacağız. Ancak remote endpointler için de ayrı güvenlik çalışmaları yapılması gerektiğini unutmayalım. Yazımızın konusu bu olmadığı için o konuya burada değinmeyeceğiz.
Bu gruptaki kontroller, uygulamanın platform API’lerini ve standart bileşenleri güvenli bir şekilde kullanmasını sağlar. Ek olarak, kontroller uygulamalar arasındaki iletişimi de (IPC) kapsar.
MSTG-PLATFORM-1: The app only requests the minimum set of permissions necessary.
Bu güvenlik standardı hem MASVS-L1 hem MASVS-L2 için geçerlidir.
Yazı dizimiz boyunca yapılması en kolay konulardan birisi de bu maddedir. Uygulamamız zaman zaman işletim sisteminden çeşitli izinlere ihtiyaç duyabilir. Kamerayai mikrofona veya depolama alanına erişim gibi. Mobil uygulamamızın sadece ihtiyaç duyduğu izinleri almasını ve kullanmasını sağlarsak, uygulamamız kökenli bir problem yaşandığında erişilebilecek yüzeyi minimum da tutmuş oluruz.
Asla ihtiyacınız olmayacak bir izni istemeyin. Ayrıca izinleri de sadece belirli koşullarda belirli sürelerde kullanmaya gayret gösterin.
MSTG-PLATFORM-2: All inputs from external sources and the user are validated and if necessary sanitized. This includes data received via the UI, IPC mechanisms such as intents, custom URLs, and network sources.
Bu güvenlik standardı hem MASVS-L1 hem MASVS-L2 için geçerlidir.
Günümüzde input (girdi) almayan bir uygulama pek kalmadı. Eğer uygulamanızda girdi alan yerler varsa yapılacak çok işiniz var demektir. Uygulamaların veri bütünlüğünü (integrity) korumak çok önemlidir.
İngilizce’de iki farklı ancak birbirine bir o kadar da yakın terim var. Bunlar Accuracy ve precision. Türkçe’ye çevirdiğimizde bunları kesinlik, hassasiyet ve doğruluk olarak düşünebiliriz. Integrity söz konusu olduğunda hem accuracy’nin hem precision’ın korunması gerekir.
Peki temelde bunlar nasıl korunur? Kısaca başlıklarına değinelim ileride bol bol bunları inceleyeceğiz:
- Input filtering/validation
Tüm girdi noktalarında alınan verinin mutlaka doğru şekilde filtreden geçirilmesi ve doğrulanması gerekir.
- Output validation
Alınan input ve istekler sonucunda oluşturulacak output’ların da mutlaka bir kontrolden ve doğrulamadan geçirilmesi gerekir.
- Error Handling
Error handling bir hata yönetimi konusudur ve çok derindir. Yazılımların düşünüldüğü şeyleri yapmadığı veya yapamadığı durumdaki tüm davranışlarını içermektedir. Ve mutlaka doğru bir error handling yapılması gerekir.
- Hash totals/check digits
Burada amaç hem validation hem verification yapmaktır. Yani verinin doğru veri olduğundan ve bütünlüğünden emin olmaktır.
- Completeness check
Burası integrity’den biraz daha farklı bir alan. Tamlığı kontrol etmek diyebileceğimiz bu maddede temel amaç tüm development sürecinin ve adımlarının eksiksiz şekilde yapılıp yapılmadığını kontrol etmektir.
Bu işlemler doğru şekilde implemente edildiğinde bu aşamayı da gerçekleştirmiş oluruz.
Not: Bu maddede yazılanlar aşağıdaki yazımdan alıntılanmıştır:
MSTG-PLATFORM-3: The app does not export sensitive functionality via custom URL schemes, unless these mechanisms are properly protected.
Bu güvenlik standardı hem MASVS-L1 hem MASVS-L2 için geçerlidir.
Hassas işlemler yapan fonksiyonları custom URL schemes (şema) ile export etmek yaptığımız tüm güvenlik önlemlerinin boşa gitmesine sebep olabilir. Tabi o mekanizma özel bir şekilde korunmuyorsa. Hassas işlemler yapan fonksiyonları ayrıca korumak bu maddenin temel amacıdır.
MSTG-PLATFORM-4: The app does not export sensitive functionality through IPC facilities, unless these mechanisms are properly protected.
Bu güvenlik standardı hem MASVS-L1 hem MASVS-L2 için geçerlidir.
Daha önce IPC mekanizmasından yazımızın ikinci bölümünde MSTG-STORAGE-6 maddesinde bahsetmiştik. Detaylı bilgi için ilgili yazının ilgili bölümüne bakabilirsiniz. Yine bir önceki maddemizdeki gibi hassas fonksiyonları koruma amacımız var.
MSTG-PLATFORM-5: JavaScript is disabled in WebViews unless explicitly required.
Bu güvenlik standardı hem MASVS-L1 hem MASVS-L2 için geçerlidir.
Mobil uygulamanızda WebViews class kullanma ihtiyacınız olabilir. Bu durum ortaya çıktığında özellikle çok gerekmedikçe JavaScript’i disable etmeniz faydalı olacaktır. Eğer WebViews class üzerinde JavaScript kullanmak zorunda kalırsanız aşağıdaki adımları takip etmeniz önerilir (örnek senaryo-Android):
- setJavaScriptEnabled metodunu bulun.
- Remote endpointlerle yapılacak iletişimin TLS ile mutlaka HTTPS üzerinden yapılmasını sağlayın.
- JavaScript ve HTML’i, local olarak, uygulama veri dizininden veya yalnızca güvenilir web sunucularından yükleyin.
- Kullanıcıların inputlara (girdi) göre farklı kaynaklar yükleyerek hangi kaynakların yükleneceğini tanımlamasına müsaade etmeyin.
MSTG-PLATFORM-6: WebViews are configured to allow only the minimum set of protocol handlers required (ideally, only https is supported). Potentially dangerous handlers, such as file, tel and app-id, are disabled.
Bu güvenlik standardı hem MASVS-L1 hem MASVS-L2 için geçerlidir.
Temelde, güvenli WebView kullanımı için yalnızca güvenilir içeriği gerekir. Kullanıcı tarafından sağlanan içeriği görüntülemeniz gerekiyorsa, yalnızca düz metni kabul edip onu sterilize etmek gerekir. Mümkünse JavaScript’i WebViews için kullanmamanızı söylemiştik. Ancak yine de etkinleştirmek durumunda kaldıysanız aşağıdaki adımları takip etmelisiniz:
- WebViews’ü mümkün olan en düşük protokol kümesi ile tanımlayın. Bunun en iyi senaryosu sadece HTTPS kullanmaktır.
- Tel veya app-id üzerinden kullanmak tehlikeli olabileceği gibi bunları mutlaka disable etmelisiniz.
MSTG-PLATFORM-7: If native methods of the app are exposed to a WebView, verify that the WebView only renders JavaScript contained within the app package.
Bu güvenlik standardı hem MASVS-L1 hem MASVS-L2 için geçerlidir.
Bazen mobil uygulamanın native metotları bir WebView’e maruz (expose) kalabilir. Bu gibi durumlarda WebView’ün yalnızca app package içerisinde bulunan JavaScript’i render ettiğinden emin olmalısınız. Aksi takdirde saldırganlar kendi JavaScript kodlarını enjekte edebilirler ki bu durum isteyeceğimiz son şey olur.
MSTG-PLATFORM-8: Object deserialization, if any, is implemented using safe serialization APIs.
Bu güvenlik standardı hem MASVS-L1 hem MASVS-L2 için geçerlidir.
Bu maddeyi incelemeden önce kısaca serialization ve deserialization nedir ona bakalım. Serialization var olan bir nesnenin saklanabilecek veya taşınabilecek (transfer) forma dönüştürülmesidir. Bu işlemin tam tersi olan Deserialization ise bir akış’ın (stream) nesne modeline dönüştürülmesidir. Bu konu hakkında daha fazla bilgi isteyenler aşağıdaki linki inceleyebilir:
Toparlayacak olursak eğer bir deserialization işlemi yapmanız gerekiyorsa bunu safe serialization API’larını kullanarak yapmalısınız.
MSTG-PLATFORM-9: The app protects itself against screen overlay attacks. (Android only)
Bu güvenlik standardı MASVS-L2 ve sadece Android OS için geçerlidir.
Öncelikle biraz Android tarafındaki overlay attack nedir ondan bahsedelim. Overlay attack, normalde kurban adına bir şekilde eylemler gerçekleştirebilen kötü niyetli bir uygulama/kullanıcıdan oluşur. Bu genellikle bir uygulama görünümünü taklit ederek kullanıcıdan birçok izin almak üzere tasarlanmış bir saldırı türüdür.
Overlay attack konusunda detaylı bilgi almak isteyenler için:
Android tarafında dağıtım yaptığınız uygulamanın bu ataktan etkilenmemesi için güvenlik önlemleriniz almış olmanız gerekiyor.
MSTG-PLATFORM-10: A WebView’s cache, storage, and loaded resources (JavaScript, etc.) should be cleared before the WebView is destroyed.
Bu güvenlik standardı MASVS-L2 için geçerlidir.
Dikkat ettiyseniz bu grup içerisinde bol bol WebView’den bahsettik. Buradan WebView konfigürasyonlarının çok önemli olduğunu çıkarabilirsiniz. WebView kullanımı sonrasında onu yok etmeden önce WebView’in önbelleğini (cache), depolama alanını (storage) ve yüklenen kaynakları (loaded resources) temizlememiz gerekir.
MSTG-PLATFORM-11: Verify that the app prevents usage of custom third-party keyboards whenever sensitive data is entered (iOS only).
Bu güvenlik standardı MASVS-L2 ve sadece iOS için geçerlidir.
Günümüzde mobil cihazların işletim sistemi ile birlikte gelen klavyelerin kullanımı kadar üçüncü parti klavyelerin de kullanımı çok yaygındır. Bununla birlikte yasal bir klavye uygulaması gibi görünen ve kullanıcıların verilerini çalmak için tasarlanmış zararlı yazılımlar da mevcuttur. Bu olmasa dahi üçüncü parti klavyelerin bir zafiyetinden faydalanılarak yine verilerin çalınması söz konusu olabilir.
Bunun için uygulanacak çözüm çok basittir. Hassas veri girişi sırasında uygulamanın üçüncü parti klavyelerin kullanımı engellemesi için bir mekanizma kurulması ve bunun kontrolünün yapılması yeterli olacaktır.
V7: Code Quality and Build Setting Requirements
Yazılım geliştirme süreçleri çok yorucu zamanlara sahiplik yapabilir. Dizayn ve mimari ne kadar doğru ve güvenli kurgulanırsa kurgulansın eğer geliştirme aşamasındaki kodlama esnasında belirlenen prensipler uygulanmazsa güvenlik söz konusu olmayacaktır. Bu bölümde özellikle geliştirme aşamasında uygulanması hedeflenen güvenlik standartları ele alınmıştır.
MSTG-CODE-1: The app is signed and provisioned with a valid certificate, of which the private key is properly protected.
Bu güvenlik standardı hem MASVS-L1 hem MASVS-L2 için geçerlidir.
Mobil uygulamanın valid (geçerli) ve günümüz güvenlik standartlarını karşılayan bir sertifika ile imzalanması gerekir. Bu imzalama sürecinde bir public bir de private key olacaktır. Private key adından da anlaşılacağı üzere özel kalmalı ve çok iyi korunmalıdır.
MSTG-CODE-2: The app has been built in release mode, with settings appropriate for a release build (e.g. non-debuggable).
Bu güvenlik standardı hem MASVS-L1 hem MASVS-L2 için geçerlidir.
Mobil uygulamalarda zafiyet bulmak için yapılan en popüler yöntemler statik analiz, dinamik analiz ve tersine mühendisliktir. Tersine mühendislik içerisinde de uygulamayı reverse ederken debug moda almak çok popülerdir. Bu yüzden uygulamanın doğru konfigürasyonlarla release modda built edilmesi ve non-debuggable hale getirilmesi gerekir.
MSTG-CODE-3: Debugging symbols have been removed from native binaries.
Bu güvenlik standardı hem MASVS-L1 hem MASVS-L2 için geçerlidir.
Native binary dosyaları yine tersine mühendislik ve statik/dinamik analiz çalışmalarında en çok incelenen dosyalardır. Bu nedenle bu dosyalar içerisinde nerelere bakılması gerektiğine dair ipucu bırakmamak en sağlıklısı olacaktır. Bu nedenle native binary dosyalarından mutlaka debugging sembollerinin silinmiş olması gerekir.
MSTG-CODE-4: Debugging code and developer assistance code (e.g. test code, backdoors, hidden settings) have been removed. The app does not log verbose errors or debugging messages.
Bu güvenlik standardı hem MASVS-L1 hem MASVS-L2 için geçerlidir.
Geliştirmeler esnasında geliştiriciler bazen kendilerine assistance kodları bırakabilirler. Bunlar bir test kodu, gizli ayar veya bir arka kapı bile olabilir. Yine release öncesi bu kodların unutulması ciddi güvenlik sorunlarına neden olacaktır.
Bunun dışında uygulamanın ayrıntılı hataları ve debug mesajlarının loglara kaydedilmesi veya unutulması uygulamamız ile ilgili çok önemli bilgileri açığa çıkarabilir. Bu nedenle bunların bırakılmaması tavsiye edilmektedir.
MSTG-CODE-5: All third party components used by the mobile app, such as libraries and frameworks, are identified, and checked for known vulnerabilities.
Bu güvenlik standardı hem MASVS-L1 hem MASVS-L2 için geçerlidir.
Daha önce yazılımlar oluşturulurken çok fazla sayıda diyebileceğimiz kütüphane ve framework kullanıldığından bahsetmiştik. Bunları kullanırken özellikle üçüncü parti bileşenlerin tamamının tanımlanması, sınıflandırılması ve tümünün bilinen güvenlik zafiyetlerine dair düzenli olarak kontrol edilmesi gerekir. Aksi takdirde üçüncü parti bir kütüphane yüzünden veri sızıntısı olması gibi durumlarla karşılaşabilirsiniz.
MSTG-CODE-6: The app catches and handles possible exceptions.
Bu güvenlik standardı hem MASVS-L1 hem MASVS-L2 için geçerlidir.
İstisna işleme (exception handling), bir uygulamanın farklı hata durumlarına (ağın kesilmesi veya veritabanı bağlantısının başarısız olması gibi) çeşitli şekillerde yanıt vermesine olanak tanıyan bir programlama konseptidir. İstisnaları ve hataları doğru şekilde ele almak, kodunuzu güvenilir hale getirmek için çok önemlidir.
Hata işleme, izinsiz giriş tespiti açısından da önemlidir. Uygulamanıza yönelik belirli saldırılar, devam eden saldırıların tespit edilmesine yardımcı olabilecek hataları tetikleyebilir.
Bu nedenle uygulamanın mutlaka doğru bir hata/istisna işleme sistemi olmalıdır.
MSTG-CODE-7: Error handling logic in security controls denies access by default.
Bu güvenlik standardı hem MASVS-L1 hem MASVS-L2 için geçerlidir.
Fail-open security check. Bu kavram error handling konusunda çok karşılaşılan bir güvenlik sorunudur. Tüm güvenlik mekanizmaları, özel olarak izin verilene kadar erişimi reddetmelidir, reddedilene kadar kesinlikle erişim vermemelidir. Bu yapılmadığında ortaya fail-open security check sorunu çıkar.
Kilit cümlemiz şu: Tüm güvenlik mekanizmaları, özel olarak izin verilene kadar erişimi reddetmelidir, reddedilene kadar kesinlikle erişim vermemelidir.
MSTG-CODE-8: In unmanaged code, memory is allocated, freed and used securely.
Bu güvenlik standardı hem MASVS-L1 hem MASVS-L2 için geçerlidir.
Programlama da en önemli noktalardan birisi de hafıza yönetimidir. Doğru hafıza yönetimi kurgulanmaz ise iki zafiyete yol açabiliriz. Buffer overflow ve heap overflow. Genellikle bu iki zafiyetin de sömürü metodu aynıdır. O nedenle birlikte anlatılırlar. Bu zafiyetler hakkında detaylı bilgi isterseniz aşağıdaki linki ziyaret edebilirsiniz.
Not: Heap overflow genellikle buffer overflow zafiyetinin içinde bir kategori olarak sunulur.
MSTG-CODE-9: Free security features offered by the toolchain, such as byte-code minification, stack protection, PIE support and automatic reference counting, are activated.
Bu güvenlik standardı hem MASVS-L1 hem MASVS-L2 için geçerlidir.
Toolchain tarafından sunulan birçok ücretsiz güvenlik önlemi/özelliği vardır. Bu özelliklere örnek vermemiz gerekirse byte-code minification, stack protection, PIE support ve automatic reference counting’i örnek verebiliriz. Bunların ihtiyaca göre mutlaka kullanıldığından emin olunması gerekir.
V8: Resilience Requirements
Bu bölüm, hassas verileri veya fonksiyonları işleyen veya bunlara erişim sağlayan uygulamalar için önerilen derinlemesine savunma önlemlerini kapsar. Bu kontrollerden herhangi birinin olmaması bir güvenlik açığına neden olmaz. Bunun yerine, uygulamanın tersine mühendislik ve belirli istemci tarafı saldırılarına karşı direncini artırması amaçlanır.
Bu bölümdeki kontroller, uygulamaya yetkisiz müdahale edilmesinden ve/veya kodun tersine mühendislikten geçirilmesinden kaynaklanan risklerin değerlendirilmesine dayalı olarak gerektiği şekilde uygulanmalıdır.
Bu konuya geçmeden önce ekstra okuma yapmak isteyenlere kaynaklarımızı önerelim:
Android:
iOS:
Birazdan bahsedeceğimiz güvenlik standartlarının bir işe yarayabilmesi için minimum MASVS-L1'in tamamının hali hazırda uygulanmış olması gerekir.
Yani sadece bu bölümde yer alan standartların tek başlarına uygulanması bir anlam ifade etmeyecektir.
Impede Dynamic Analysis and Tampering
MSTG-RESILIENCE-1: The app detects, and responds to, the presence of a rooted or jailbroken device either by alerting the user or terminating the app.
Bu güvenlik standardı MASVS-R için geçerlidir.
Bu bölümdeki önlemlerin verilmesine neden olan birçok saldırı çeşidinde yapılan ilk adım uygulamanın ele geçirilmesidir. Bunun için de genellikle root’lanmış android cihazlar veya jailbreak’li iOS cihazlar kullanılır. Buna karşı önlem olarak uygulama, kullanıcıyı uyararak veya uygulamayı sonlandırarak root’lanmış veya jailbreak’li bir cihazın varlığını algılamalı ve o cihazda çalışmamalıdır.
MSTG-RESILIENCE-2: The app prevents debugging and/or detects, and responds to, a debugger being attached. All available debugging protocols must be covered.
Bu güvenlik standardı MASVS-R için geçerlidir.
Bir önceki bölümde uygulamayı analiz ederek zafiyet bulmaya çalışma aşamalarında sıkça debugging yapıldığından bahsetmiştik. Buna engel olmamız durumunda uygulamamız daha güvenli hale gelecektir. Bunun için de mevcut tüm debugging protokolleri için uygulamanın debugging’i engellemesi ve hatta bir debugger’ın attach edilmesini de algılayıp işlemi durdurması gerekir.
MSTG-RESILIENCE-3: The app detects, and responds to, tampering with executable files and critical data within its own sandbox.
Bu güvenlik standardı MASVS-R için geçerlidir.
Uygulama, orijinal çalıştırılabilir dosyalarında (örneğin yeniden paketlenerek) kurcalamayı, kendi sanal alanı içindeki kritik verilerin çalışma zamanı değişikliklerini ve/veya yan yüklemeyi (sideloaded) algılamalı ve buna göre kendini korumaya almalıdır.
MSTG-RESILIENCE-4: The app detects, and responds to, the presence of widely used reverse engineering tools and frameworks on the device.
Bu güvenlik standardı MASVS-R için geçerlidir.
Birçok kez vurguladığımız gibi tersine mühendislik için kullanılan ve herkes tarafından bilinen çok sayıda uygulama vardır. Bu uygulamaların bir kısmı da mobil cihazlara yüklenerek kullanılmak durumundadır. Mobil cihazlara yüklenmeden kullanılan da birçok tool mevcuttur.
Cihaza yüklenen toollar için mobil uygulamanın yüklü tersine mühendislik toollarını algılaması ve bu algılamaya göre hareket etmesi gerekir. Buradaki amaç uygulamaya tersine mühendislik uygulanmasını olabildiğince zorlaştırmaktır.
MSTG-RESILIENCE-5: The app detects, and responds to, being run in an emulator.
Bu güvenlik standardı MASVS-R için geçerlidir.
iOS tarafında bu sorunla çok fazla karşılaşılmasa da Android tarafında sıkça karşılaşan bir durumdur bu. Uygulamayı bir emulator vasıtasıyla çalıştırarak üzerinde çeşitli denemeler yapılır. Bunun önüne geçmek veya bu durumu zorlaştırmak için uygulamanın gerçek bir cihazda değil de emulatorde çalıştığını algılaması ve orada çalışmaması gerekir.
MSTG-RESILIENCE-6: The app detects, and responds to, tampering the code and data in its own memory space.
Bu güvenlik standardı MASVS-R için geçerlidir.
Uygulamalar çalışırken RAM’de kendine belirli bir alan ayırır demiştik. Uygulama üzerinde tampering yapmaya çalışanlar genelde memory üzerindeki bu alandaki kod ve verilere erişip onlar üzerinde işlem yapmaya çalışırlar. Bu yüzden uygulama bu alana erişip bunları kurcalamak isteyenlerin faaliyetlerini tespit etmeli ve ona göre aksiyon almalıdır. Bu aksiyonlardan birisi hafızadaki verilerin temizlenmesi olabilir.
MSTG-RESILIENCE-7: The app implements multiple mechanisms in each defense category (8.1 to 8.6). Note that resiliency scales with the amount, diversity of the originality of the mechanisms used.
Bu güvenlik standardı MASVS-R için geçerlidir.
Bu madde biraz da işin bakış açısını ve felsefesini anlatmak için oluşturulmuş. Şu ana kadar bu standartlar dizisinde 1–7'ye kadar birçok savunma mekanizması önerildi. Ancak bu mekanizmalar için uygulanacak savunma yöntem sayısı neredeyse sınırsızdır.
Yani ben bir tane önlem aldım bu da yetecek bakış açısı yanlıştır. Saldırılar çoğu zaman çok özel ve sofistike metotlar içerir. Bu yüzden savunma mekanizmalarının da çok özel ve sofistike metotlar içermesi gerekir.
MSTG-RESILIENCE-8: The detection mechanisms trigger responses of different types, including delayed and stealthy responses.
Bu güvenlik standardı MASVS-R için geçerlidir.
Uygulamanın üzerinden gelen ve giden isteklerin bir davranış deseni vardır. Bu davranış deseninin normal çalışma şartları altında ne olduğu belirlenirse, birisi bizim uygulamamız üzerinde istemediğimiz çalışmalar yaparken bu deseni bozduğunu fark edebilir ve hemen bir savunma mekanizması devreye sokabiliriz.
MSTG-RESILIENCE-9: Obfuscation is applied to programmatic defenses, which in turn impede de-obfuscation via dynamic analysis.
Bu güvenlik standardı MASVS-R için geçerlidir.
Obfuscation’ın amacı kodlarımızın içeriğinin ve mantığının saldırganlar tarafından ele geçirilmesini engellemektir. Bunun doğru şekilde uygulanması kodlarımızın dinamik analiz ile de-obfuscation yapılmasını büyük ölçüde engelleyebilir.
Device Binding
MSTG-RESILIENCE-10: The app implements a ‘device binding’ functionality using a device fingerprint derived from multiple properties unique to the device.
Bu güvenlik standardı MASVS-R için geçerlidir.
Device binding, cihazın çeşitli biyometrik özelliklerini kullanarak veya güvenli bir token kullanarak cihazın uygulama ile bağlanmasıdır. Yani cihaz güvenli cihazlar listesine eklenebilmesi için bir prosesten geçmelidir. Bu sayede uygulama bir başka cihaza kurulup aynı hesap ile login olunmak istediğinde bu aşamadan geçemez ise hesaba giriş yapılamayacaktır.
Impede Comprehension
MSTG-RESILIENCE-11: All executable files and libraries belonging to the app are either encrypted on the file level and/or important code and data segments inside the executables are encrypted or packed. Trivial static analysis does not reveal important code or data.
Bu güvenlik standardı MASVS-R için geçerlidir.
Bir saldırının ilk adımı ve en önemli parçası olan bilgi toplama, anlama ve analiz etme çalışmaları genellikle hedefi harekete geçirmeden yapılmaya çalışılır. Bunun için de dinamik analiz vb. analiz çalışmaları bu aşamadan kullanılmaz. Saldırgan hedefi ile teması minimum seviyede tutmaya çalışır.
Bu aşamada en çok kullanılan tekniklerden biri de statik analizdir. Ancak tek kullanılan teknik bu değildir. Kullanılan tüm tekniklerin bir listesi yapılarak onlara karşı önlemler almak daha mantıklı olacaktır. Ancak genel olarak yapılacaklar birçok teknik için önlem sayılabilir. Uygulamaya ait tüm yürütülebilir dosyalar ve kütüphaneler dosya düzeyinde şifrelenmeli ve/veya yürütülebilir dosyalar içindeki önemli kod ve veri bölümleri şifrelenmeli veya paketlenmelidir. Bu sayede statik analiz ile önemli kod veya veriler ortaya çıkarılamaz.
MSTG-RESILIENCE-12: If the goal of obfuscation is to protect sensitive computations, an obfuscation scheme is used that is both appropriate for the particular task and robust against manual and automated de-obfuscation methods, considering currently published research. The effectiveness of the obfuscation scheme must be verified through manual testing. Note that hardware-based isolation features are preferred over obfuscation whenever possible.
Bu güvenlik standardı MASVS-R için geçerlidir.
Eğer gizlemenin (obfuscation) amacı hassas hesaplamaları korumaksa, halihazırda yayınlanan araştırmalar dikkate alınarak hem belirli görev için uygun hem de manuel ve otomatik gizleme çözme yöntemlerine karşı sağlam olan bir gizleme şeması kullanılmalıdır. Gizleme planının etkinliği manuel testlerle doğrulanmalıdır. Ayrıca donanım tabanlı izolasyon özelliklerinin, gizlemeye tercih edildiğini unutmamalıyız.
Impede Eavesdropping
MSTG-RESILIENCE-13: As a defense in depth, next to having solid hardening of the communicating parties, application level payload encryption can be applied to further impede eavesdropping.
Bu güvenlik standardı MASVS-R için geçerlidir.
Daha önce ne olduğunu anladığımız defense in depth aslında bir felsefe, bir yaklaşım biçimi ve bir metodolojidir. Communicating kısımları için ağa dahil olup gizlice dinleme yapacaklara karşı önlemler almamız gerekir. Bunun da en güzel örneği uygulama seviyesinde payload encryption uygulamaktır.
Ve yazı dizimizin sonuna geldik. Konu yazılım güvenliği ve mimarileri olunca Türkçe kaynak bulmak zor olabiliyor. Bu nedenle ben de vakit buldukça bol bol içerik üreteceğim.
Sorularınız ve düzeltme önerileriniz için iletişim: serhanw@pm.me
Kaynak:
