Bloga geri dön
MASVS, iki güvenlik doğrulama düzeyi (MASVS-L1 ve MASVS-L2) ve bir dizi tersine mühendislik dayanıklılığı gereksinimini (MASVS-R) tanımlar. MASVS-L1, tüm mobil uygulamalar için önerilen genel güvenlik gereksinimlerini içerirken, MASVS-L2 son derece hassas verileri işleyen uygulamalara uygulanmalıdır. MASVS-R, istemci tarafındaki tehditleri önlemek bir tasarım hedefi ise uygulanabilecek ek koruyucu kontrolleri kapsar.
MASVS-L1'deki gereksinimleri karşılamak, en iyi güvenlik uygulamalarını izleyen ve yaygın güvenlik açıklarından etkilenmeyen güvenli bir uygulama ile sonuçlanır. Kod kalitesi, hassas verilerin işlenmesi ve mobil ortamla etkileşim açısından temel gereksinimleri karşılar.
MASVS-L2, mobil işletim sisteminin güvenlik kontrollerinin sağlam olduğunu ve son kullanıcının potansiyel bir saldırgan olarak görülmediğini varsayarak, daha karmaşık saldırılara karşı dirençli bir uygulama ile sonuçlanan SSL sabitleme gibi ek derinlemesine savunma kontrolleri ekler. Bu seviye, mobil bankacılık uygulamaları gibi oldukça hassas verileri işleyen uygulamalar için uygundur.
MASVS-R'deki yazılım koruma gereksinimlerinin tamamını veya alt kümelerini karşılamak, son kullanıcının kötü niyetli olduğu ve / veya mobil işletim sisteminin tehlikeye düştüğü durumlarda belirli istemci tarafı tehditlerini engellemeye yardımcı olur. Uygulama son teknoloji güvenliğe sahiptir ve ayrıca hassas kod veya verileri çıkarmak için kurcalama, modlama veya tersine mühendislik gibi belirli, açıkça tanımlanmış istemci tarafı saldırılarına karşı dayanıklıdır.
MASVS'nin genel amacı, mobil uygulama güvenliği (MASVS-L1) için bir temel sunmak ve aynı zamanda derinlemesine savunma önlemlerinin (MASVS-L2) ve istemci tarafı tehditlerine (MASVS-R) karşı korumaların dahil edilmesine izin vermektir.
MASVS, aşağıdakileri gerçekleştirmeyi amaçlamaktadır:
MASVS-L1
Bu gereksinimler tüm mobil uygulamalarda karşılanabilir. MASVS-L1, geliştirme maliyeti ve kullanıcı deneyimi üzerinde makul bir etkiyle izlenebilecek en iyi güvenlik uygulamalarını içerir. Daha yüksek seviyelerden birine uygun olmayan herhangi bir uygulama için MASVS-L1'deki gereksinimlerin uygulanması beklenir.
MASVS-L2
Kimlik hırsızlığı, dolandırıcılık ödemeleri veya çeşitli dolandırıcılık planları için kullanılabilen kişisel olarak tanımlanabilir bilgileri depolayan mobil uygulamalar; kredi kartı numaraları, kişisel bilgiler gibi son derece hassas bilgilere erişim sağlayan veya kullanıcının para aktarmasına izin veren finansal uygulamalar ve PCI DSS, SOX gibi denetimler kapsamında olan uygulamaların MASVS-L2 standardına uyması beklenir.
MASVS-L1 + R
Fikri Mülkiyet korumasının bir iş hedefi olduğu mobil uygulamalarda MASVS-R'de listelenen dayanıklılık kontrolleri, uygulamanın orijinal kaynak kodunu elde etmek ve kurcalama / kırılmayı engellemek için gereken çabayı artırmak için kullanılabilir. Rekabetçi çevrimiçi oyunlar gibi modlama ve hile yapmayı önlemeye yönelik temel ihtiyaç duyulan oyunlarda yine MASVS-R'de listelenen kontroller uygulamanın güvenliğini daha yüksek seviyelere çeker.
MASVS-L2 + R
Çevrimiçi bankacılık, tasarım gereği hassas verileri mobil cihazda depolaması gereken ve aynı zamanda çok çeşitli cihazları ve işletim sistemi sürümlerini desteklemesi gereken tüm mobil uygulamalar, uygulama içi satın alımları olan uygulamalarda ücretli içeriği korumak için ideal olarak sunucu tarafı ve MASVS-L2 kontrollerini kullanmalıdır. Bu gibi durumlarda dayanıklılık kontrolleri, hassas verileri çıkarmayı amaçlayan saldırganların çabalarını artırmak için kapsamlı bir savunma önlemi olarak kullanılabilir.
|
# |
Referans |
Açıklama |
L1 (Standart Güvenlik) |
L2 (Hassas veri İçeren Kritik Uygulamalar İçin Ek Güvenlik) |
|
1.1 |
MSTG-ARCH-1 |
Tüm uygulama bileşenleri tanımlanmalı ve bileşenlerin gerekli olup olmadığı, gerekli ise ne için gerekli olduğu bilinmelidir. |
|
|
|
1.2 |
MSTG-ARCH-2 |
Güvenlik denetimleri yalnızca istemci tarafında değil, ilgili uzak uç noktalarda da uygulanmalıdır. |
|
|
|
1.3 |
MSTG-ARCH-3 |
Mobil uygulama ve tüm bağlı uzak hizmetler için yüksek seviyeli bir mimari tanımlanmalı ve bu mimaride güvenlik ele alınmalıdır. |
|
|
|
1.4 |
MSTG-ARCH-4 |
Mobil uygulama bağlamında hassas olduğu düşünülen veriler belirlenmelidir. |
|
|
|
1.5 |
MSTG-ARCH-5 |
Tüm uygulama bileşenleri, sağladıkları iş işlevleri ve / veya güvenlik işlevleri açısından tanımlanır. |
|
|
|
1.6 |
MSTG-ARCH-6 |
Mobil uygulama ve ilişkili uzak servisler için potansiyel tehditleri ve karşı önlemleri tanımlayan bir tehdit modeli oluşturulmalıdır. |
|
|
|
1.7 |
MSTG-ARCH-7 |
Tüm güvenlik kontrolleri merkezi bir entegrasyon içermelidir. |
|
|
|
1.8 |
MSTG-ARCH-8 |
Kriptografik anahtarların (varsa) nasıl yönetildiğine ve şifreleme anahtarlarının yaşam döngüsünün nasıl uygulandığına dair açık bir politika belirlenmelidir. İdeal olarak NIST SP 800-57 anahtar yönetim standardı kullanılabilir. |
|
|
|
1.9 |
MSTG-ARCH-9 |
Mobil uygulamanın güncellemelerini zorunlu kılmak için bir mekanizma kullanılmalıdır. |
|
|
|
1.10 |
MSTG-ARCH-10 |
Güvenlik, yazılım geliştirme yaşam döngüsünün tüm bölümlerinde ele alınmalıdır. |
|
|
|
1.11 |
MSTG-ARCH-11 |
İfşa politikası olmalı ve etkin bir şekilde uygulanmalıdır. |
|
|
|
1.12 |
MSTG-ARCH-12 |
Uygulama, gizlilik yasalarına ve regülasyonlara uyum sağlamalıdır. |
|
|
|
# |
Referans |
Açıklama |
L1 (Standart Güvenlik) |
L2 (Hassas veri İçeren Kritik Uygulamalar İçin Ek Güvenlik) |
|
2.1 |
MSTG-STORAGE-1 |
PII (Personally Identifiable Information), kullanıcı kimlik bilgileri veya kriptografik anahtarlar gibi hassas verileri depolamak için sistem kimlik depolama olanakları kullanılmalıdır. |
|
|
|
2.2 |
MSTG-STORAGE-2 |
Hassas veriler, uygulama alanı veya sistem kimlik depolama alanları dışındaki alanlarda saklanmamalıdır. |
|
|
|
2.3 |
MSTG-STORAGE-3 |
Uygulama günlüklerine hassas veriler yazılmamalıdır. |
|
|
|
2.4 |
MSTG-STORAGE-4 |
Mimarinin gerekli bir parçası olmadığı sürece hiçbir hassas veri üçüncü taraflarla paylaşılmamalıdır. |
|
|
|
2.5 |
MSTG-STORAGE-5 |
Hassas verileri işleyen metin girişlerinde klavye önbellek özelliği devre dışı bırakılmalıdır. |
|
|
|
2.6 |
MSTG-STORAGE-6 |
IPC (Inter Process Communication) mekanizmaları aracılığıyla hiçbir hassas veri açığa çıkarılmamalıdır. |
|
|
|
2.7 |
MSTG-STORAGE-7 |
Parola veya pin gibi hassas veriler, kullanıcı arabirimi aracılığıyla açığa çıkarılmamalıdır. |
|
|
|
2.8 |
MSTG-STORAGE-8 |
Mobil işletim sistemi tarafından oluşturulan yedeklemelere hiçbir hassas veri dahil edilmemelidir. |
|
|
|
2.9 |
MSTG-STORAGE-9 |
Uygulama, arka plana taşındığında hassas verileri görünümlerden kaldırmalıdır. |
|
|
|
2.10 |
MSTG-STORAGE-10 |
Uygulama hassas verileri hafızada gerekenden daha uzun süre tutmamalı ve kullanımdan sonra hafıza temizlenmelidir. |
|
|
|
2.11 |
MSTG-STORAGE-11 |
Uygulama, kullanıcının bir cihaz şifresi ayarlamasını zorunlu kılmak gibi minimum bir cihaz erişimi güvenliği politikası uygulamalıdır. |
|
|
|
2.12 |
MSTG-STORAGE-12 |
Uygulama, kullanıcıyı işlenen kişisel olarak tanımlanabilir bilgi türlerinin yanı sıra kullanıcının uygulamayı kullanırken izlemesi gereken en iyi güvenlik uygulamaları konusunda eğitmelidir. |
|
|
|
2.13 |
MSTG-STORAGE-13 |
Mobil cihazda yerel olarak hiçbir hassas veri depolanmamalıdır. Bunun yerine, veriler gerektiğinde uzak bir uç noktadan alınmalı ve yalnızca bellekte tutulmalıdır. |
|
|
|
2.14 |
MSTG-STORAGE-14 |
Hassas verilerin yine de yerel olarak depolanması gerekiyorsa, kimlik doğrulaması gerektiren donanım destekli depolamadan türetilen bir anahtar kullanılarak şifrelenmelidir. |
|
|
|
2.15 |
MSTG-STORAGE-15 |
Çok sayıda başarısız kimlik doğrulama girişiminden sonra uygulamanın yerel depolama alanı silinmelidir. |
|
|
|
# |
Referans |
Açıklama |
L1 (Standart Güvenlik) |
L2 (Hassas veri İçeren Kritik Uygulamalar İçin Ek Güvenlik) |
|
3.1 |
MSTG-CRYPTO-1 |
Uygulama, tek şifreleme yöntemi olarak sabit kodlanmış anahtarlarla simetrik kriptografiye güvenmemelidir. |
|
|
|
3.2 |
MSTG-CRYPTO-2 |
Uygulama, kriptografik temellerin kanıtlanmış uygulamalarını kullanılmalıdır. |
|
|
|
3.3 |
MSTG-CRYPTO-3 |
Uygulama, endüstri standartlarına uyan parametrelerle yapılandırılmalı, belirli bir kullanım senaryosu için uygun olan şifreleme ilkelerini kullanmalıdır. |
|
|
|
3.4 |
MSTG-CRYPTO-4 |
Uygulama, güvenlik nedeniyle yaygın olarak kullanımdan kaldırılan kriptografik protokolleri veya algoritmaları kullanmamalıdır. |
|
|
|
3.5 |
MSTG-CRYPTO-5 |
Uygulama, aynı şifreleme anahtarını birden çok amaç için yeniden kullanmamalıdır. |
|
|
|
3.6 |
MSTG-CRYPTO-6 |
Tüm rasgele değerler, yeterince güvenli bir rasgele sayı üreteci kullanılarak üretilmelidir. |
|
|
|
# |
Referans |
Açıklama |
L1 (Standart Güvenlik) |
L2 (Hassas veri İçeren Kritik Uygulamalar İçin Ek Güvenlik) |
|
4.1 |
MSTG-AUTH-1 |
Uygulama, kullanıcıların uzak bir hizmete erişmesini sağlıyorsa, uzak uç noktada kullanıcı adı / parola kimlik doğrulaması gibi bir tür kimlik doğrulama işlemi gerçekleştirilmelidir. |
|
|
|
4.2 |
MSTG-AUTH-2 |
Stateful (Durumsal) oturum yönetimi kullanılıyorsa, uzak uç nokta, kullanıcının kimlik bilgilerini göndermeden istemci isteklerinin kimliğini doğrulamak için rastgele oluşturulmuş oturum tanımlayıcılarını kullanılmalıdır. |
|
|
|
4.3 |
MSTG-AUTH-3 |
Stateless (Durumsuz) token tabanlı kimlik doğrulama kullanılırsa, sunucu, güvenli bir algoritma kullanılarak imzalanmış bir token sağlamalıdır. |
|
|
|
4.4 |
MSTG-AUTH-4 |
Uzak uç nokta, kullanıcı oturumu kapattığında mevcut oturumu sonlandırmalıdır. |
|
|
|
4.5 |
MSTG-AUTH-5 |
Uzak uç noktada bir parola politikası olmalı ve bu politikaya uygun parolalar oluşturulması sağlanmalıdır. |
|
|
|
4.6 |
MSTG-AUTH-6 |
Uzak uç nokta, kimlik bilgilerinin aşırı sayıda gönderilmesine (kaba kuvvet saldırıları) karşı koruma sağlamak için bir mekanizma uygulamalıdır. |
|
|
|
4.7 |
MSTG-AUTH-7 |
Önceden tanımlanmış bir hareketsizlik durumu (inaktivite) ve erişim tokenlarının süresi dolduktan sonra uzak uç noktadaki oturumlar geçerliliğini yitirmelidir. |
|
|
|
4.8 |
MSTG-AUTH-8 |
Eğer biyometrik kimlik doğrulama varsa, olaya bağlı olmamalıdır (yani, yalnızca "true" veya "false" döndüren bir API). Bunun yerine, anahtar zinciri / anahtar deposunun kilidini açmaya dayanmalıdır. |
|
|
|
4.9 |
MSTG-AUTH-9 |
Uzak uç noktada ikinci bir kimlik doğrulama faktörü olmalı ve 2FA gereksinimi sürekli olarak uygulanmalıdır. |
|
|
|
4.10 |
MSTG-AUTH-10 |
Hassas işlemler, adım adım kimlik doğrulaması gerektirmelidir. |
|
|
|
4.11 |
MSTG-AUTH-11 |
Uygulama, kullanıcıyı hesabıyla ilgili tüm hassas etkinlikler konusunda bilgilendirmelidir. Kullanıcılar, cihazların bir listesini ve bağlamsal bilgileri (IP adresi, konum, vb.) görüntüleyebilmeli ve belirli cihazları engelleyebilmelidir. |
|
|
|
4.12 |
MSTG-AUTH-12 |
Yetkilendirme modelleri uzak uç noktada tanımlanmalı ve uygulanmalıdır. |
|
|
|
# |
Referans |
Açıklama |
L1 (Standart Güvenlik) |
L2 (Hassas veri İçeren Kritik Uygulamalar İçin Ek Güvenlik) |
|
5.1 |
MSTG-NETWORK-1 |
Veriler ağda TLS kullanılarak şifrelenmelidir. Güvenli kanal, uygulama genelinde tutarlı bir şekilde uygulanmalıdır. |
|
|
|
5.2 |
MSTG-NETWORK-2 |
TLS ayarları, mevcut en iyi uygulamalarla uyumlu olmalıdır veya mobil işletim sistemi önerilen standartları desteklemiyorsa mümkün olduğunca en iyi standartlara yakın olmalıdır. |
|
|
|
5.3 |
MSTG-NETWORK-3 |
Uygulama, güvenli kanal kurulduğunda uzak uç noktanın X.509 sertifikasını doğrulamalıdır. Yalnızca güvenilir bir CA tarafından imzalanan sertifikalar kabul edilmelidir. |
|
|
|
5.4 |
MSTG-NETWORK-4 |
Uygulama, kendi sertifika deposunu kullanmalı, uç nokta sertifikasını veya public key bilgisini sabitlemelidir ve güvenilir bir CA tarafından imzalanmış olsa bile farklı bir sertifika veya anahtar sunan uç noktalarla bağlantı kurulmamalıdır. (SSL Pinning) |
|
|
|
5.5 |
MSTG-NETWORK-5 |
Uygulama, kayıtlar ve hesap kurtarma gibi kritik işlemler için tek bir güvenli olmayan iletişim kanalına (e-posta veya SMS) güvenmemelidir. |
|
|
|
5.6 |
MSTG-NETWORK-6 |
Uygulama yalnızca güncel bağlantı ve güvenlik kütüphanelerine bağlı olmalıdır. |
|
|
|
# |
Referans |
Açıklama |
L1 (Standart Güvenlik) |
L2 (Hassas veri İçeren Kritik Uygulamalar İçin Ek Güvenlik) |
|
6.1 |
MSTG-PLATFORM-1 |
Uygulama yalnızca gerekli olan, minimum izinlere erişim istemelidir. |
|
|
|
6.2 |
MSTG-PLATFORM-2 |
Harici kaynaklardan ve kullanıcıdan gelen tüm girdiler doğrulanmalı ve gerekirse sterilize edilmelidir. Bu, kullanıcı arayüzü, intentler gibi IPC mekanizmaları, özel URL'ler ve ağ kaynakları aracılığıyla alınan verileri de içermelidir. |
|
|
|
6.3 |
MSTG-PLATFORM-3 |
Uygulama, güvenlik mekanizmaları düzgün bir şekilde korunmadığı sürece özel URL şemaları aracılığıyla hassas fonksiyonları dışa aktarmamalıdır. |
|
|
|
6.4 |
MSTG-PLATFORM-4 |
Uygulama, güvenlik mekanizmaları uygun şekilde korunmadığı sürece IPC aracılığıyla hassas fonksiyonları dışa aktarmamalıdır. |
|
|
|
6.5 |
MSTG-PLATFORM-5 |
Eğer özel ihtiyaç yoksa, WebView yapılarında JavaScript desteği devre dışı bırakılmalıdır. |
|
|
|
6.6 |
MSTG-PLATFORM-6 |
WebView yapıları, yalnızca gereken minimum protokol işleyici kümesine izin verecek şekilde yapılandırılmalıdır (ideal olarak, yalnızca https desteklenir). Dosya, telefon ve uygulama kimliği gibi potansiyel olarak tehlikeli işleyiciler devre dışı bırakılmalıdır. |
|
|
|
6.7 |
MSTG-PLATFORM-7 |
Uygulamanın native metodları bir WebView yapısına maruz kalırsa, WebView yalnızca uygulama paketinde bulunan JavaScript'i çalıştırmalıdır. |
|
|
|
6.8 |
MSTG-PLATFORM-8 |
Object desrialization işlemi varsa güvenli serialization API'leri kullanılmalıdır. |
|
|
|
6.9 |
MSTG-PLATFORM-9 |
Uygulama, screen overlay saldırılarına karşı kendini korumalıdır. (Yalnızca Android) |
|
|
|
6.10 |
MSTG-PLATFORM-10 |
WebView yok edilmeden önce WebView önbelleği, deposu ve yüklenen kaynakları (JavaScript, vb.) temizlenmelidir. |
|
|
|
6.11 |
MSTG-PLATFORM-11 |
Hassas veri girişi sırasında uygulama özel üçüncü taraf klavyelerin kullanımını engellemelidir (yalnızca iOS). |
|
|
|
# |
Referans |
Açıklama |
L1 (Standart Güvenlik) |
L2 (Hassas veri İçeren Kritik Uygulamalar İçin Ek Güvenlik) |
|
7.1 |
MSTG-CODE-1 |
Uygulama özel anahtarı uygun şekilde korunan geçerli bir sertifika ile imzalanmalıdır. |
|
|
|
7.2 |
MSTG-CODE-2 |
Uygulama, yayına uygun ayarlarla hazırlanmalıdır (örneğin, hata ayıklama modu kapalı). |
|
|
|
7.3 |
MSTG-CODE-3 |
Native binary dosyalardan hata ayıklama sembolleri kaldırılmalıdır. |
|
|
|
7.4 |
MSTG-CODE-4 |
Hata ayıklama kodu ve geliştirici yardım kodu (ör. Test kodu, arka kapılar, gizli ayarlar) kaldırılmalıdır. Uygulama ayrıntılı hataları veya hata ayıklama mesajlarını uygulama günlüğüne kaydetmemelidir. |
|
|
|
7.5 |
MSTG-CODE-5 |
Kütüphaneler ve frameworkler gibi mobil uygulama tarafından kullanılan tüm üçüncü taraf bileşenleri tanımlanmalıdır ve bilinen güvenlik açıkları açısından kontrol edilmelidir. |
|
|
|
7.6 |
MSTG-CODE-6 |
Uygulama olası istisnaları yakalamalı ve ele almalıdır. |
|
|
|
7.7 |
MSTG-CODE-7 |
Güvenlik kontrollerindeki hata işleme mantığı, varsayılan olarak erişimi reddetmelidir. |
|
|
|
7.8 |
MSTG-CODE-8 |
Yönetilmeyen kodda, bellek ayrılmalı, serbest bırakılmalı ve güvenli bir şekilde kullanılmalıdır. |
|
|
|
7.9 |
MSTG-CODE-9 |
Araç zincirinin sunduğu bayt kodu küçültme, yığın koruma, PIE (Position-independent executable) desteği ve otomatik referans sayma gibi ücretsiz güvenlik özellikleri etkinleştirilmelidir. |
|
|
|
# |
Referans |
Açıklama |
MASVS-R - Dayanıklılık (Resilience) |
|
8.1 |
MSTG-RESILIENCE-1 |
Uygulama, kullanıcıyı uyararak veya uygulamayı sonlandırarak root'lu veya jailbreak'li bir cihazın varlığını algılamalı ve duruma uygun bir şekilde yanıt vermelidir. |
|
|
8.2 |
MSTG-RESILIENCE-2 |
Uygulama, hata ayıklamayı engellemeli ve / veya bir hata ayıklayıcının bağlanmasını algılamalı ve duruma uygun bir şekilde yanıt vermelidir. Mevcut tüm hata ayıklama protokolleri kapsanmalıdır. |
|
|
8.3 |
MSTG-RESILIENCE-3 |
Uygulama, kendi sanal alanındaki yürütülebilir dosyaları ve kritik verileri değişiklik ve müdahaleleri algılamalı ve bunlara yanıt vermelidir. |
|
|
8.4 |
MSTG-RESILIENCE-4 |
Uygulama, cihazda yaygın olarak kullanılan tersine mühendislik araçlarının ve çerçevelerinin varlığını algılamalı ve bunlara yanıt vermelidir. |
|
|
8.5 |
MSTG-RESILIENCE-5 |
Uygulama, bir emülatörde çalışma durumunu algılamalı ve yanıt vermelidir. |
|
|
8.6 |
MSTG-RESILIENCE-6 |
Uygulama, kendi hafıza alanındaki kod ve verilerde değişiklik ve müdahaleleri algılamalı ve bunlara yanıt vermelidir. |
|
|
8.7 |
MSTG-RESILIENCE-7 |
Uygulama, her savunma kategorisinde (8.1 - 8.6) birden fazla mekanizma uygulamalıdır. Dayanıklılığın, kullanılan mekanizmaların orijinalliğinin miktarı ve çeşitliliği ile ölçeklendiği unutulmamalıdır. |
|
|
8.8 |
MSTG-RESILIENCE-8 |
Algılama mekanizmaları, gecikmeli ve gizli yanıtlar dahil olmak üzere farklı türlerdeki yanıtları tetiklemelidir. |
|
|
8.9 |
MSTG-RESILIENCE-9 |
Obfuscation (Gizleme), programatik savunmalara uygulanmalıdır ve bu da dinamik analiz yoluyla kod üzerinde tersine mühendisliği zorlaştırır. |
|
|
# |
Referans |
Açıklama |
MASVS-R - Dayanıklılık (Resilience) |
|
8.10 |
MSTG-RESILIENCE-10 |
Uygulama, cihaza özgü birçok özellikten türetilen bir cihaz parmak izini (fingerprint) kullanarak bir "cihaz bağlama" işlevselliği uygulamalıdır. |
|
|
# |
Referans |
Açıklama |
MASVS-R - Dayanıklılık (Resilience) |
|
8.11 |
MSTG-RESILIENCE-11 |
Uygulamaya ait tüm yürütülebilir dosyalar ve kütüphaneler ya dosya düzeyinde şifrelenmeli ve / veya yürütülebilir dosyalar içindeki önemli kod ve veri bölümleri şifrelenmeli veya paketlenmelidir. Statik analiz, önemli kodu veya verileri ortaya çıkarmamalıdır. |
|
|
8.12 |
MSTG-RESILIENCE-12 |
Obfuscation işleminin 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. Obfuscation planının etkinliği manuel testlerle doğrulanmalıdır. Mümkün olduğunda, donanım tabanlı izolasyon özelliklerinin obfuscation işlemine göre daha çok tercih edildiğini unutmayın. |
|
|
# |
Referans |
Açıklama |
MASVS-R - Dayanıklılık (Resilience) |
|
8.13 |
MSTG-RESILIENCE-13 |
Derinlemesine bir savunma olarak, iletişim kuran tarafların sağlam bir şekilde güçlendirilmesinin yanı sıra, gizli dinlemeyi daha da engellemek için uygulama düzeyinde yük şifrelemesi uygulanmalıdır. |
|
https://owasp.org/www-project-mobile-security-testing-guide/
https://github.com/OWASP/owasp-masvs
https://mobile-security.gitbook.io/masvs/
Siber güvenlik teknoloji dünyasında oldukça önemli bir güvenli sorunu, güncel ve mühim hukuki sorunlar içermekte faydalı yazınız için teşekkürler
Güvenli mobil uygulamalar geliştirmek isteyen benim gibi yazılımcılar için çok faydalı bir kaynak olmuş, yazılım geliştirme monusunda daha çok web tabanlı projeler üretsemde iphone pil değişimi üzerine geliştirmek istediğim bir uygulamada bu bilgilerden kesinlikle faydalanacağım.
elinize emeğinize sağlık. https://www.burtinet.com/
