Yalnızca kullanıcı adı / parola tabanlı kimlik doğrulamasını kullanırsam, yeterince güvenli olmayacaklar mı?
Hayır, çünkü yalnızca WHO'nun API sunucusuna eriştiğini tanımlıyorsunuz , WHAT onu erişiyor.
DSÖ ve API Sunucusuna Erişen Nedir?
DSÖ ile bir API sunucusuna erişen WHAT arasındaki farkları daha iyi anlamak için şu resmi kullanalım:
Amaçlanan İletişim Kanalı, yasal bir kullanıcı tarafından herhangi bir kötü niyet olmaksızın, mobil uygulamanın bozulmamış bir sürümünü kullanarak ve ortadaki adam saldırıya uğramadan doğrudan API sunucusuyla iletişim kurarak, beklediğiniz gibi kullanılan mobil uygulamayı temsil eder.
Asıl kanal, mobil uygulamanın yeniden paketlenmiş bir sürümünü kullanan kötü niyetli bir kullanıcı, mobil uygulamanın orijinal sürümünü kullanan bir bilgisayar korsanı, ortadaki adam ise nasıl olduğunu anlamak için ona saldırıyor gibi birkaç farklı senaryoyu temsil edebilir. API'nize yönelik saldırıları otomatikleştirebilmek için mobil uygulama ile API sunucusu arasındaki iletişim yapılıyor. Diğer birçok senaryo da mümkündür, ancak burada her birini sıralayamayacağız.
Şimdiye kadar zaten bir ipucu olabileceğini umut neden WHO ve NE aynı değildir, ancak eğer bir anda belli olacak.
DSÖ biz yetkilendirebilmelerini ve OpenID Bağlan ya OAuth2 akar kullanmak gibi çeşitli yollarla tespit edebilirsiniz mobil uygulamasının kullanıcısı.
OAUTH
Genel olarak OAuth, istemcilere bir kaynak sahibi adına sunucu kaynaklarına "güvenli, yetki verilmiş erişim" sağlar. Kaynak sahiplerinin, kimlik bilgilerini paylaşmadan kendi sunucu kaynaklarına üçüncü taraf erişimini yetkilendirmesi için bir süreci belirtir. Köprü Metni Aktarım Protokolü (HTTP) ile çalışmak üzere özel olarak tasarlanan OAuth, temelde erişim belirteçlerinin kaynak sahibinin onayıyla bir yetkilendirme sunucusu tarafından üçüncü taraf istemcilere verilmesine izin verir. Üçüncü taraf daha sonra erişim belirtecini kaynak sunucusu tarafından barındırılan korumalı kaynaklara erişmek için kullanır.
OpenID Connect
OpenID Connect 1.0, OAuth 2.0 protokolünün üstündeki basit bir kimlik katmanıdır. Müşterilerin, Yetkilendirme Sunucusu tarafından gerçekleştirilen kimlik doğrulamasına dayalı olarak Son Kullanıcının kimliğini doğrulamasına ve Son Kullanıcı hakkındaki temel profil bilgilerini birlikte çalışabilir ve REST benzeri bir şekilde edinmesine olanak tanır.
Kullanıcı kimlik doğrulaması, API sunucusunun WHO'nun API'yi kullandığını bilmesini sağlayabilirken, taleplerin mobil uygulamanın orijinal sürümü olan beklediğiniz NE'den kaynaklandığını garanti edemez .
Şimdi API sunucusunu NE çağırdığını belirlemenin bir yoluna ihtiyacımız var ve burada işler çoğu geliştiricinin düşündüğünden daha karmaşık hale geliyor. NE API sunucuya istekte şeydir. Gerçekten mobil uygulamanın gerçek bir örneği mi, yoksa bir bot, otomatikleştirilmiş bir komut dosyası veya Postman gibi bir araç kullanarak API sunucusuyla manuel olarak uğraşan bir saldırgan mı?
Sürpriziniz için, mobil uygulamanın yeniden paketlenmiş bir sürümünü veya oyunlaştırmaya ve uygulama tarafından sağlanan hizmetten yararlanmaya çalışan otomatik bir komut dosyası kullanan yasal kullanıcılardan biri olabileceğini keşfedebilirsiniz.
Geliştiriciler , NE'yi tanımlamak için genellikle mobil uygulamalarının koduna sabit kod yazdıkları bir API anahtarına başvurma eğilimindedir. Bazı geliştiriciler, mobil uygulamadaki çalışma zamanında fazladan yol kat ederler ve anahtarı hesaplarlar, böylece kodda statik bir sır gömülü olduğunda, eski yaklaşımın aksine bu, çalışma zamanı sırrı haline gelir.
Yukarıdaki yazı, yazdığım MOBİL UYGULAMANIZIN NEDEN API ANAHTARINA İHTİYACI VAR? Başlıklı makaleden alınmıştır. ve burada tam olarak okuyabileceğiniz , bu API anahtarları hakkında bir dizi makalenin ilk makalesidir.
Hassas Verilerin İstemci Cihazında Saklanması
Ve elbette güvenlik nedenleriyle bu kullanıcı adını / şifreyi cihaza kaydedemiyorum? Kayıt sırasında her kullanıcı için bir GUID vermeli, cihazlarına kaydetmeli ve bir API isteği sırasında her seferinde almalı mıyım?
Cihaza kaydettiğiniz her şey, şifrelenmiş olsa bile, Frida veya Xposed gibi araçlarla çalışma sırasında tersine mühendislik yapılabilir.
Frida
Kara kutu işlemlerine kendi komut dosyalarınızı enjekte edin. Herhangi bir işlevi bağlayın, kripto API'leri hakkında casusluk yapın veya özel uygulama kodunu izleyin, kaynak koda gerek yok. Düzenleyin, kaydet'e basın ve sonuçları anında görün. Tümü derleme adımları olmadan veya program yeniden başlatılmaz.
xPosed
Xposed, herhangi bir APK'ye dokunmadan sistemin ve uygulamaların davranışını değiştirebilen modüller için bir çerçevedir. Bu harika çünkü modüllerin herhangi bir değişiklik olmadan farklı sürümler ve hatta ROM'lar için çalışabileceği anlamına gelir (orijinal kod
Bir cihazda saldırganın kontrolleri o da tanımlamak için kullanabileceği herhangi sırrı ayıklamak için Ortadan Atak Bir Erkeği gerçekleştirmek için bir proxy kullanabilir NE ya WHO ben makalesinde göstermek olarak adam saldırısı ile bu API Anahtarını çalmak :
API anahtarını mobil uygulama kodunda gizlemek için JNI / NDK gibi gelişmiş teknikleri kullanabilsek de, API anahtarını çalmak için birinin MitM saldırısı gerçekleştirmesini engellemeyecektir. Aslında bir MitM saldırısı, geliştirici olmayanlar tarafından bile gerçekleştirilebileceği noktaya kadar kolaydır.
Öyleyse şimdi ne ... API sunucumu kötüye kullanımdan koruyamayacağım noktaya mahkum muyum ??? Sessizlik yok, bu yüzden ... umut hala var !!!
Olası çözümler
Birisi bana Facebook, FourSquare veya Twitter gibi ünlü android uygulamalarının mobil uygulamalarından sunucularına gelen her isteği doğrulamak için hangi yöntemi kullandığını söyleyebilir mi?
Maalesef bu uygulamalar hakkında sizi aydınlatacak kadar bilgim yok, ancak sizi başka yaklaşımlara yönlendirebilirim.
Başka hangi modeller mevcut ve hangileri en verimli ve güvenli, bunun için sadece bir süreç akışına ihtiyacım var.
Dolayısıyla, istemci tarafında çalışan ve bir API'ye erişmek için bazı sırlara ihtiyaç duyan her şey farklı şekillerde kötüye kullanılabilir ve Mobil API Güvenlik Teknikleri hakkındaki bu makale dizisi hakkında daha fazla bilgi edinebilirsiniz . Bu makaleler size API Anahtarlarının, Kullanıcı Erişim Belirteçlerinin, HMAC ve TLS Sabitlemenin API'yi korumak için nasıl kullanılabileceğini ve bunların nasıl atlanabileceğini öğretecektir.
Mobil uygulamanıza erişen NE sorununu çözmek için , yukarıda bahsettiğim ve API sunucunuza yetkisiz erişimi sadece daha zor hale getirebileceğini kabul ettiğim Mobil API Güvenlik Teknikleri ile ilgili yazı dizilerinde bahsedilen çözümlerden birini veya tamamını kullanmanız gerekir. bypass ama imkansız değil.
API sunucusunun yalnızca gerçek bir mobil uygulamadan istek aldığını bilmesini sağlayacak bir Mobil Uygulama Tasdik çözümü kullanılarak daha iyi bir çözüm kullanılabilir.
Mobil Uygulama Onayı
Bir Mobil Uygulama Onay çözümünün kullanılması, API sunucusunun istekleri NE gönderdiğini bilmesini sağlar , böylece güvenli olmayan kaynaklardan gelen diğer tüm istekleri reddederken yalnızca gerçek bir mobil uygulamadan gelen isteklere yanıt vermesine olanak tanır.
Mobil Uygulama Onay çözümünün rolü, çalışma anında mobil uygulamanızın kurcalanmadığını, köklü bir cihazda çalışmadığını, xPosed veya Frida gibi bir çerçeve tarafından kullanılmadığını, MitM'ye saldırılmadığını garanti etmektir. arka planda bir SDK çalıştırılarak elde edilir. Bulutta çalışan hizmet, uygulamaya meydan okuyacak ve yanıtlara dayanarak, mobil uygulamanın bütünlüğünü ve cihazın çalıştığını doğrulayacaktır, böylece SDK hiçbir karardan sorumlu olmayacaktır.
Mobil uygulama bütünlüğünün başarılı bir şekilde onaylanması üzerine, kısa süreli bir JWT jetonu verilir ve yalnızca buluttaki API sunucusu ve Mobil Uygulama Onay hizmetinin farkında olduğu bir sır ile imzalanır. Mobil uygulama onayında hata olması durumunda JWT jetonu, API sunucusunun bilmediği bir sır ile imzalanır.
Artık Uygulama, isteğin başlıklarındaki JWT belirtecini her API çağrısıyla birlikte göndermelidir. Bu, API sunucusunun yalnızca JWT belirtecindeki imzayı ve sona erme süresini doğrulayabildiğinde isteklere hizmet etmesine ve doğrulama başarısız olduğunda bunları reddetmesine izin verecektir.
Mobil Uygulama Onay hizmeti tarafından kullanılan sır, mobil uygulama tarafından bilinmediğinde, Uygulama tahrif edildiğinde, köklü bir cihazda çalıştırıldığında veya bir bağlantı üzerinden iletişim kurulduğunda bile çalışma zamanında tersine mühendislik yapmak mümkün değildir. Orta Saldırıda bir Adam'ın hedefi.
Mobile App Attestation hizmeti, Approov'da (burada çalışıyorum) iOS, Android, React Native ve diğerleri dahil olmak üzere çeşitli platformlar için SDK'lar sağlayan bir SAAS çözümü olarak mevcuttur. Entegrasyon ayrıca, bulut hizmeti tarafından verilen JWT belirtecini doğrulamak için API sunucu kodunda küçük bir kontrol gerektirecektir. Bu kontrol, API sunucusunun hangi isteklerin sunulacağına ve hangilerinin reddedileceğine karar verebilmesi için gereklidir.
Sonuç
Sonunda, API sunucunuzu korumak için kullanacağınız çözüm, korumaya çalıştığınız şeyin değerine ve Avrupa'daki GDPR düzenlemeleri gibi bu tür veriler için yasal gerekliliklere uygun olarak seçilmelidir.
EKSTRA MİLİ GİTMEK İSTER MİSİNİZ?
OWASP Mobil Güvenlik Projesi - En önemli 10 risk
OWASP Mobil Güvenlik Projesi, geliştiricilere ve güvenlik ekiplerine güvenli mobil uygulamalar oluşturmak ve sürdürmek için ihtiyaç duydukları kaynakları sağlamayı amaçlayan merkezi bir kaynaktır. Proje aracılığıyla amacımız, mobil güvenlik risklerini sınıflandırmak ve bunların etkisini veya istismar olasılığını azaltmak için gelişimsel kontroller sağlamaktır.
