2012-11-10 35 views
22

Son zamanlarda, parse.com'un ne kadar kullanışlı ve kolay olduğunu keşfettim. Gerçekten gelişmeyi hızlandırır ve web/mobil uygulamanızdan gelen tüm verileri saklamak için hazır bir veritabanı sunar.ayrıntılar güvenliği

Ama ne kadar güvenli? Anladığım kadarıyla, uygulamanıza özel anahtarınızı kodda gömmeniz ve böylece verilere erişim izni vermeniz gerekir.

Peki ya birisi uygulamanızdan anahtarı kurtarabiliyorsa? Kendim denedim. Standart bir APK'dan özel anahtarı bulmam 5 dakika sürdü ve ayrıca, herkesin görebileceği javascript source kodunuzda kodlanmış özel anahtar ile bir web uygulaması oluşturma olanağı da var.

Bulduğum verilerin güvenliğini sağlamanın tek yolu, ACL'lerdir (https://www.parse.com/docs/data), ancak bu hala herkesin yazılabilir verilerle kurcalanabileceği anlamına gelir.

Beni aydınlatabilecek biri var mı lütfen?

+0

Bu da beni ilgilendirir. Birkaç bağlantı buldum (https://parse.com/questions/prohibit-user-from-changing-their-own-game-score ve https://parse.com/questions/javascript-sdk-security). Parse'nin ACL sisteminin muhtemelen benim özel uygulamanızın ihtiyaçları için yeterince güvenli olduğunu düşünüyorum, ancak diğer kullanımlar için bence, kilitlemeyi denemek için daha fazla güvenlik uygulaması öğrenmem gerekiyor. – Ryan

cevap

18

Herhangi bir arka uç sunucusunda olduğu gibi, potansiyel olarak kötü niyetli istemcilere karşı da korunmanız gerekir. Ayrıştırma, size yardımcı olacak çeşitli güvenlik düzeylerine sahiptir.

İlk adım, söylediğin gibi ACLs. Yetkisiz istemcilerin yeni sınıflar oluşturmasını veya varolan sınıflara satır veya sütun eklemesini engellemek için Veri Tarayıcı'da permissions'u da değiştirebilirsiniz.

Bu güvenlik düzeyi sizi tatmin etmezse, veri erişiminizi Cloud Functions aracılığıyla proxy edebilirsiniz. Bu, müşterileriniz ile arka uç veri mağazanız arasında bir erişim kontrolü katmanı sağlamak için sanal bir uygulama sunucusu oluşturmak gibidir.

+1

Bu kesinlikle 'ol' gelenekselinden farklı bir model, '' herhangi bir şey yapmanıza izin veren sunucu tarafı kodunuzda gizleyebileceğiniz gizli bir anahtar ''. Bklimt'in burada kapsadığı genel düşünce, "Sevgili kullanıcı kullanıcısı, giriş yapana kadar hiçbir şey yapamazsınız ve Parse'ye giriş yaptıktan sonra, faaliyetlerinizin (ACL'ler ve izinler) politikasına göre faaliyetlerinizi kısıtlayacaktır. hesabınız." – Seth

+0

Bu yüzden Cloud İşlevini seviyorum! Tüm istekleri filtreleyebilir ve çok daha fazlasını yapabilirsiniz. –

3

Sadece kullanıcı verilerinin küçük bir görünümünü bir web uygulamasına maruz bırakmak için ihtiyaç duyduğum durumda aşağıdaki yaklaşımı kullandım.

a. Güvenli nesne alanlarının bir alt kümesini içeren ikincil bir nesne oluşturun.

b. ACL'leri kullanarak, güvenli nesneyi yalnızca uygun bir oturumdan erişilebilir duruma getirin

c. İkincil nesneyi genel olarak okuyun

d. İkincil nesneyi birincil ile güncellemelerle senkronize tutmak için bir tetikleyici yazın.

Çoğu zaman bulut işlevlerini de kullanıyorum, ancak bu teknik biraz esnekliğe ihtiyaç duyduğunuzda ve ikincil nesne birden fazla güvenli nesnenin görünümüyse, bulut işlevlerinden daha basit olabildiğinde kullanışlıdır.

0

Yaptığım şey şuydu.

  1. Tüm sınıflar için genel okuma/yazma kısıtlaması. Sınıf verilerine erişmenin tek yolu bulut koduyla olacaktır.
  2. Kullanıcının oturum açmış bir kullanıcı olduğunu request.user parametresini kullanarak ve kullanıcı oturumunun boş olup olmadığını ve nesne kimliğinin yasal olup olmadığını doğrulayın.
  3. Kullanıcı doğrulandığında, verilerin ana anahtar kullanılarak alınmasına izin verirdim.
0

Yalnızca Global Düzey Güvenlik seçenekleriniz üzerinde sıkı bir denetim yapın (istemci sınıfı oluşturma, vb ...), Sınıf Düzeyinde Güvenlik seçenekleri (örneğin, _Installation girişlerini silme istemcileri devre dışı bırakabilirsiniz. Ayrıca, tüm sınıflar için kullanıcı alanı oluşturmayı devre dışı bırakabilirsiniz.) Ve hepsinden önemlisi, ACL'lere dikkat edin.

Genellikle ACL'lerin her zaman doğru olduğundan emin olmak için önceden tetikleme tetikleyicileri kullanıyorum. Bu nedenle, örneğin, UUser nesneleri kurtarma e-postasının bulunduğu yerdir. Diğer kullanıcıların birbirlerinin kurtarma e-postalarını görmesini istemiyoruz. Bu nedenle, _User sınıfındaki tüm nesneler sadece kullanıcı için okuma ve yazma ayarlarına sahip olmalıdır (public read false ve public write false ile). Bu şekilde yalnızca kullanıcının kendisi kendi satırlarıyla kurcalayabilir. Diğer kullanıcılar bu satırın veritabanınızda olduğunu bile fark etmeyecek.

Bazı durumlarda bunu daha da sınırlamanın bir yolu, bulut işlevlerini kullanmaktır. Bir kullanıcının başka bir kullanıcıya mesaj gönderebileceğini varsayalım. Bunu, iletinin içeriği ve iletiyi gönderen kullanıcıya ve iletiyi alacak olan kullanıcıya işaretçilerle yeni bir sınıf İletisi olarak uygulayabilirsiniz.

İletiyi gönderen kullanıcının onu iptal edebilmesi gerektiğinden ve iletiyi alan kullanıcının bu mesajı alabilmesi gerektiğinden, her ikisinin de bu satırı okuyabilmesi gerekir (bu nedenle ACL'nin okuma izinleri olması gerekir) her ikisi için de). Ancak, her ikisinden de mesajın içeriğini karıştırmak istemiyoruz.

İki seçeneğiniz var: Ya kullanıcıların bu satırda yapmaya çalıştıkları değişikliklerin geçerli olup olmadığını denetleyen bir beforeSave tetikleyicisi oluşturuyorsunuz veya iletinin ACL'sini hiç kimsenin yazma izni olmaması için ayarlıyorsunuz. ve kullanıcıyı doğrulayan ve sonra ana anahtarı kullanarak iletiyi değiştiren bulut işlevleri oluşturursunuz.

Nokta, uygulamanızın her parçası için bu hususları dikkate almanız gerekmektedir. Bildiğim kadarıyla, bunun bir yolu yok.