it-swarm-tr.com

Mobil erişim için API güvenliğini sağlama

B2B hizmeti olarak diğer şirketler (müşterilerimiz) tarafından kullanılan Nice REST/JSON API'sini oluşturdum. Müşterilerimizin her birinin bir kullanıcı adı/şifre çifti vardır ve ayrıca HTTPS yapıyoruz ve hizmet taleplerinin kaynak IP'sini doğrulıyoruz. Hizmet kullanımı maliyetlidir ve müşteri hizmet kullanımı için aylık olarak faturalandırılır.

Şimdi, bazı müşteriler kullanıcılarına (B2C - son kullanıcılar) dağıttıkları mobil uygulamalar geliştirmektedir. Hizmetimizin bu son kullanıcılarının hepsi sunuculara sahip değildir ve hizmeti doğrudan akıllı telefondan kullanmak isterler (teknik olarak JSON/REST olmak büyük bir sorun değildir).

Sorun şu ki, hizmeti sahtekarlığa karşı nasıl koruyacağımdan emin değilim. Bir üçüncü taraf geliştiricinin müşterinin mobil uygulamasından birini sökmesini ve kullanıcı adını/şifresini/hangi güvenlik bilgilerini kopyalamasını ve bunu uygulamasında kullanmasını ne engelleyecektir? Bu, hizmeti tüketmesine ve kullanımı yasal müşterilerimizden birine talep etmesine izin verecektir!

Son kullanıcılar bazı sunuculara kimlik doğrulaması yapmadığı sürece bu soruna mükemmel bir kripto çözümü olmadığından eminim. Ancak durum her zaman böyle değildir.

Son çare olarak sanırım Android/IPhone için gizlenmiş bir kütüphane dağıtabilirim, ki bu en azından güvenlik yanılsamasını verecekti ...

DÜZENLE (açıklama) :)

Senaryoyu basitleştirmeye çalışayım.

  1. Ben bir JSON REST API hizmet hack edilemez bir web sunucum var.
  2. Mobil istemciler API'ma doğrudan erişiyor. IP'leri doğrulanamıyor. Standart bir işletim sistemi (Android/IOS) çalıştırıyorlar.
  3. İlgili başka sunucu yok.
  4. Telefonların IMEI'sine erişemiyorum (özel olarak kabul edilir) veya bu bana yardımcı olmaz çünkü son kullanıcıları bilmiyorum.
  5. API'mıza erişen farklı şirketler tarafından geliştirilen bu tür yasal mobil uygulamalar vardır.
  6. Mevcut güvenlik (kullanıcı adı/şifre) haydut şirket tarafından kolayca hacklenebilir. Bahsedilen haydut şirket yasal bir mobil uygulamayı demonte eder ve kullanıcı adını/şifreyi yasadışı uygulamalarına kopyalar. Bu uygulamayı ve kârı dağıtırlar (API kullanımı, kimlik bilgilerini çaldığı şirkete uygulanır).

Bu durdurulabilir mi?

16
Tal Weiss

Sorunuz "Bu durdurulabilir mi?", Ancak sistemle ilgili önemli bir şeyin gerçekten değiştirilemeyeceği/değiştirilemeyeceği hissine kapılıyorum.

Eğer doğru anlıyorsam, soruyorsun

Aynı kullanıcı adını ve şifreyi paylaşan birçok müşterim var. Yanlış kullanımı durdurabilir miyim?

Bunun cevabı hayır. Sorunu göz ardı edip edemeyeceğinize veya doğru çözümleri uygulayıp uygulayamayacağınıza karar vermelisiniz.

Bunu gerçekten doğru bir şekilde yapmak istiyorsanız, OAuth gibi bir şey uygulamaya bakın, böylece son kullanıcılar için ayrı kimlik doğrulama jetonlarını düzgün bir şekilde dağıtabilir, faturalandırma, erişimi iptal etme vb. İçin müşterilerinize bağlayabilirsiniz.

-

Yapmanız gereken en az şey, müşterilerinizin (şirketlerin) daha iyi bir kimlik doğrulama düzeni kullanmayı seçmelerine izin vermektir. Örneğin, son kullanıcıları için ayrı erişim belirteçleri istemek (ve iptal etmek) için bir API oluşturursunuz.

  • Şirket A sunucularından bir jeton ister (bu uygulama tarafından "bana bir jeton ver" diyerek başlatılır)
  • Jeton N'ye dönersiniz, hangi şirkete bağlı olduğunu kaydedersiniz
  • Şirket A-s uygulaması hizmetinize bağlanırsa, kullanıcı adını/parolayı değil jetonu N gönderir
  • Şirket A, hizmetinize "iptal N kartını iptal et" diyebilir ve bu belirtecin diğer istekleri hizmetiniz tarafından sunulmayacaktır. Ancak, bir simge iptal edilirse, tüm istemci uygulamalarını kullanılamaz hale getirmez.

Bir şirket bunu yapmak istemiyorsa, kullanıcı adını/şifresini kullanarak bağlantı kurmaya devam edebilir, ancak sonuçta ortaya çıkan tüm kullanımdan tamamen sorumlu olacaktır.

Mesele şu ki, hizmeti kullanmanın başka bir yolu yoksa, müşterilerinizi kimlik bilgilerini (mobil uygulama senaryosunda yapılması imkansız bir şey) sızdırmaktan gerçekten sorumlu tutamazsınız.

7
Joel L

Bu yüzden umarım bu doğru olur. Geçerli bir API anahtarı kullanarak bir istemcinin kimliğini doğrulamak için güvenli bir yol mu istiyorsunuz? API anahtarını güvenli bir şekilde saklamanın, uygulamayı değil, şirketi geliştiren şirketten büyük ölçüde sorumlu olduğunu düşünüyorum.

Günlük hackerlardan korumak için anahtarı şifrelemeniz ve gizlemeniz gerekecek, ancak kararlı bir hacker'ı önleyebileceğinizi sanmıyorum. İkili hata ayıklama zor yapmak için biraz hackery yapabilir, bu da uygulamanızın internette yüzen şansını azaltabilir. Ancak bu mutlak bir güvenlik değildir ve şirketiniz şirket içi uygulamaları geliştirmedikçe bu tür önlemleri nasıl uygulayabilirsiniz?

Yani senaryonuza bir cevap olarak, hayır, kullanıcı deneyimine zarar vermeden etkili bir şekilde durduğunu düşünmüyorum. API'nızı kullanarak şirketleri eğitebilirsiniz - onlar için küçük bir el kitabı bir araya getirin ve onların = onların api anahtarını güvende tutmanın açık olduğundan emin olun .

Sonunda, bazı azaltma özelliklerini de uygulayabilirsiniz. Örneğin:

  1. Şirketlerin kendi zor sınırlarını tanımlamalarına izin verin. A şirketinin geçen ay N uygulama indirmeleri olduğunu bildiğini ve bu nedenle API'nize erişimlerini günlük veya saatte X isteğiyle sınırlamak istediklerini söyleyin.
  2. Dönem başına şirket başına taleplerdeki ani artışları izleyin.
  3. Olası hileli faaliyetler sırasında oluşacak prosedürlerin bir adımını tanımlayın.
  4. Yeniden anahtarla, yeniden anahtarla ve yeniden anahtarla.

Başarısızlık hedefi (en iyisi olur) hasarı en aza indirmektir.

İyi şanslar.

6
Kurt

Müşterilerinizin kullanıcı adlarını/şifrelerini tüm kullanıcılarına dağıtabilecekleri bir mobil uygulamaya yerleştirmeleri konusunda şüpheci davranabilirsiniz. Doğru bir şekilde tanımladığınız gibi, bazı saldırganların bu mobil uygulamayı sökmesi, mobil uygulamadan kullanıcı adını/şifreyi çıkarması ve kendi uygulamasında kullanması kolay olacaktır. Ne yazık ki, müşteriniz bunu yapıp yapmayacağınıza karar veren kişidir, ancak maliyet size uygulanır. Yani, bu bir dışsallıktır ve maliyetleri, riskleri ve teşvikleri daha uyumlu hale getirmek için bir yol bulmanız gerekir. Aşağıda bunun nasıl yapılacağı hakkında bazı önerilerim var.

Genel olarak, bunun iki mantıklı çözümünü görüyorum:

  • Risk transferi. Her müşteri için, o müşteriden kaç istek kabul edeceğinize bir sınır getirin. Müşterilere, kullanıcı adlarını/parolalarını güvende tutma sorumluluğunun olduğunu, bu kullanıcı adını/parolayı kullanarak gelen tüm isteklerin limitleri dahilinde sayılacağını ve çok fazla istek gelmesi durumunda hesaplarının devre dışı bırakılabileceğini söyleyin. Kullanıcı adlarını/şifrelerini bir mobil uygulamaya yerleştirirlerse, haksız birinin kullanıcı adını/şifreyi çalabileceğini ve birçok istekte bulunmak için kullanabileceğini ve hesaplarının devre dışı bırakılmasına ve mobil uygulamalarının çalışmayı durdurmasına neden olabileceğini söyleyin . Risk almak isteyip istemediklerine karar vermelerine izin verin.

  • Sözleşme gereklilikleri. Müşterilerinize, kullanıcı adlarını/şifrelerini başkalarıyla paylaşmalarının yasak olduğunu söyleyin ve başkaları tarafından indirilebilen uygulamalara kullanıcı adlarını/şifrelerini yerleştirmelerine izin verilmez. Bu politikanın herhangi bir ihlalini tespit ederseniz hesaplarının devre dışı bırakılabileceğini ve bunun sunucularınıza yüklediği maliyetler için faturalandırılabileceğini söyleyin.

    Müşterileriniz bir mobil uygulama oluşturmak istiyorsa, müşterilerinize mobil uygulamaya kendi kullanıcı adlarını/şifrelerini gömmek yerine, bu tür istekleri kendi sunucularına proxy vermeleri gerektiğini söyleyin. Başka bir deyişle, istemcinin istemcinin kullanıcı adını/şifresini bilen bir sunucu kurması gerekir, ancak bu kullanıcı adı/şifre mobil uygulamaya gömülmemelidir. İstemcinin mobil uygulaması istemcinin sunucusunda kimlik doğrulaması yapmalı, sunucuya bir istek göndermeli ve ardından sunucu isteği size iletmeli ve yanıtı mobil uygulamaya geri göndermelidir. Sunucuları, son kullanıcının kimliğini doğrulamalıdır (ör. Mobil uygulamanın her son kullanıcısının, sunucularında kendi kullanıcı adı/şifresi ile bir hesap oluşturmasını zorunlu kılmalıdır). Sunucuları, kullanıcı başına bant genişliği sınırları koymalı ve bu sınırları aşan son kullanıcıların hesabını devre dışı bırakmalıdır.

Ayrıca, istemcilerin şu iki seçenek arasında seçim yapmasına da izin verebilirsiniz: ör., Sınırlı bant genişliği hesabı (risk aktarımı ile) veya sınırsız bant genişliği hesabı (kullanıcı adı/parolayı başkalarına erişebilen uygulamalara yerleştirmeme şartıyla) arasında ).

Umarım bu mantıklı gelir. Bu biraz kafa karıştırıcı olabilir, çünkü üç taraf vardır - siz, müşteriniz ve müşterinizin son kullanıcısı - her birinin kendi ilgi alanları ve kaygılar. Umarım her üçünü de yeterince ayırt etmişimdir.

3
D.W.

Verilerinizi SSL ile iletimde güvenli hale getirmek zaten ortadaki adam saldırısını kapsamaktadır. Kaynak kodda sabit kodlanmış şifreler zaten güvenli bir uygulama değildir. Kullanıcıların IP adreslerini veya IMEI'yi önemsememelisiniz. Takip hakkında konuşmayalım ve ilk etapta işleri düzeltmeye çalışalım.

Dediğin gibi REST kullanıyorsun. Umarım birkaç şey size yardımcı olur.

  1. Sunucu tarafında kullanıcıların kimliğini doğrulayın. Sahte olmamak için sıkı oturum yönetimini sürdürün. Bunun için OWASP'a göz atın.
  2. API'nız için bir tüy testi yapın. ReST çok az güvenlik açığıyla bilinir. Lütfen bunları internette keşfedin ve ReST'deki bilinen hataların çoğunu öğrenin. API'nız için bu sorunları yamalayın.
  3. SSL öğeniz, verilerinizi ortada koruyor olması iyidir.

Kaynak kodunuz için endişelenmeyin. Yine de sökük olabilir ama sorun değil. Başlıca işlevleriniz sunucuda çalışacak ve yanıtları istemcilere iletecektir. Tüm iyi şeyleri sunucu tarafında tutun.

1
mojo

Mobil cephede karşılaşacağınızı düşündüğüm sorunlardan biri IP adresi doğrulaması. Tipik olarak telco tarafından atanan mobil IP adresleri netleştirilir. Ağa bağlanan IP, sunucu tarafında benimsenen IP doğrulama mekanizmasını kullanılmaz hale getirecektir.

Çözümü Android ve Iphone'lar) üzerine uygulamak için; yaklaşımın şöyle olması gerektiğini düşünüyorum:

  1. SSL modunda istemci sunucusu kimlik doğrulamasının istemci sertifikası doğrulamasına da genişletilmesini sağlayın. Yani istemci ve sunucunun güvenli SSL oturumu oluşturmak için sertifika kullanmasına izin verin.
  2. İstemci sertifikasını (mobil) içeren PFX/P12'yi PIN ve IMEI ve IMSI numaralarının birleşimini gerektirecek şekilde sunun, böylece bir saldırganın sertifikayı reddetmesi zorlaşacaktır) aynı oturum.
  3. Sunucuda, aynı istemci sertifikası kullanılarak başlatılan iki veya daha fazla eşzamanlı oturumu algılayan bazı AI'ların uygulanmasını sağlayın.

Mobil ortam için tartışıyor olsak da inanıyorum; IP doğrulaması dışında, riskler PC ortamında da mevcuttur. Gelecekte, PC ortamında imza tabanlı ve istemci sertifikasına dayalı uygulamayı da benimseyebilir veya istemcilerin yanlış faturalandırma sorunlarıyla karşılaşırsanız geçiş yapabilirsiniz.

1
Mohit Sethi

Sahtecilik belirsizdir ve sadece teknik bir uygulama ile ele alınamaz, ancak artan IP doğrulaması ve kilitlemesi uyguladıysanız endişelenecek bir şey yoktur. Ayrıca gerçek kimlik bilgilerinizi müşterilerinize (B2B) vermemelisiniz. Neden ve nasıl olduğunu açıklayayım.

Ne yazdığınızı anladığımdan, B2B tarafı (KENDİNİZ - KENDİNİZ) ile ilgili temel ve ortalama güvenlik kavramları ve uygulamaları zaten uygulanmıştır. Bu iyi. IP Doğrulama, SSL/TLS, Kullanıcı/Geçiş vb. Artık, müşterilerinize son kullanıcılara mobil uygulamalar sunmak için kullanılan API kimlik bilgilerinin, üçüncü taraf son kullanıcının yararlanacağı şekilde kusurlu olabileceğinden endişe ediyorsunuz. istemcinizin mobil uygulamasından bir şekilde yararlandıysa bu kimlik bilgileri.

Temel olarak bir dizi güvenlik katmanına kadar kaynar. Soru, şirketinizin bu katmanları nasıl tasarlayıp uyguladığıdır?

  1. JSON/REST API SERVER cihazınız gerçek kimlik bilgilerinizi içermelidir. Bir hizmet veriyorsanız ve bir ağ sağlayıcısına/operatöre bağlantı gerektiriyorsa, bu kimlik bilgileri de burada bulunabilir. Ne demek istediğimi biliyorsun.

  2. SİZİN JSON/REST API SUNUCUSU'na doğrudan erişim vermeyin. Bunun yerine, güvenilir ortam için Ana Bilgisayar görevi görecek bir atlama Ana Bilgisayarına ihtiyacınız vardır; JSON/REST uygulamanızın bulunduğu API sunucusu, SADECE IP Adresi doğrulama/kilitleme kullanarak bu sunucu ile kimlik doğrulaması yapmalıdır. IP veya ortak/özel anahtar çiftlerini kullanarak sunucudan sunucuya kimlik doğrulama. Ne kullanacağınız sizin takdirinize bağlıdır.

Bu sunucu aynı zamanda kendisini bir yapılandırma dosyasıyla eşleyen ve isteği JSON/REST API SUNUCUSU'na geçiren bir dizi kullanıcı adı/parola içeren bir web hizmeti olarak da hareket etmelidir. Şimdi, YOURCLIENTS, IP doğrulama/kilitleme temelinde de bu sunucuya erişebilmeli ve HTTPS kullanılarak korunmalıdır. Kavram, API SUNUCUSU ile eşleşen anahtar/sır dışında burada gerçek kullanıcı/geçiş kimlik bilgilerinin bulunamamasıdır.

  1. KENDİNİZ, kendi yanlarından son kullanıcılara kadar bir güvenlik uygulamasına sahip olabilir. Geliştiriciler için PKI ortak/özel anahtar çifti veya sıradan kullanıcılar için 2FA şeklinde olabilir. SİZİN şirketiniz değil, bu adımları uygulamalıdır.

Şimdi, örneğin, bir üçüncü taraf geliştirici (son kullanıcı), YOURCLIENT tarafından oluşturulan bir mobil uygulamadaki bir kusurdan yararlandı ve kimlik bilgilerini aldı:

  1. Faydasız. Kimlik bilgilerini kullanmak için IP'nizin doğrulanacağına ilişkin.
  2. Geçersiz. Genel/özel anahtar çifti aracılığıyla kimliğiniz doğrulanmış olmalıdır.
  3. Ayrıcalık yükseltme tekniği, güvenilir olması için gerçek sunucuyu kullanmasını gerektirecektir.
  4. Gerçek sunucuyu kullanmak, bir saldırganın motivasyonunu yavaşlatacak hazırlanmış teknikler gerektirir.
  5. Motivasyonun sona erdiği başarılı bir saldırı yoktur.

Gizleme iyidir ve bir saldırıyı yavaşlatır, ancak en az güvenlik şeklidir. Anahtarları kullanan kriptoya daha iyi güvenmelisiniz.

Unutmayın, teknik ve operasyonel bir güvenlik perspektifinden dolandırıcılıkla mücadele konusundaki sürekli çabanız dışında kesin bir güvenlik çözümü yoktur.

1
John Santos