Müşteri tarafı kodlaması: Kötü amaçlı kullanım nasıl önlenir?

60

Son birkaç yılda, müşteri tarafı (tarayıcı) uygulamalarına yönelik eğilim gerçekten artmıştır.

En son projem için zamanla denemeye, taşınmaya ve müşteri tarafında bir uygulama yazmaya karar verdim.

Bu uygulamanın bir kısmı, kullanıcılara işlem e-postaları göndermeyi içerir (örneğin, kaydolma, parola sıfırlama e-postalarını vb. Doğrula). E-postaları göndermek için üçüncü taraf bir API kullanıyorum.

Normalde uygulamamın bir sunucuda çalışmasını sağlardım. Üçüncü taraf API’yi sunucumdaki koddan arardım.

Bir istemci tarafı uygulama çalıştırmak, bunun şimdi kullanıcının tarayıcısında yapılması gerektiği anlamına gelir. Üçüncü taraf API, bunu başarmak için gerekli JavaScript dosyalarını sağlar.

Görebildiğim ilk göze çarpan sorun, bir API anahtarı kullanmam gerektiği. Bu normalde sunucumda güvenli bir şekilde saklanır, ancak şimdi büyük olasılıkla bu anahtarı istemci tarayıcısına vermem gerekecek.

Bu sorunu çözebileceğimi farz edersek, sonraki sorun, teknik açıdan meraklı bir kullanıcının, JavaScript geliştiricileri aracını bir tarayıcıya yüklemesini ve uygulamada belirlediğim kurallara uymak yerine, istedikleri gibi e-posta API'sini kullanmasını engelleyen şeydir. .

Sanırım genel sorum şu - bir müşteri tarafı uygulamanın kötü amaçlı kullanımını nasıl önleyebiliriz?

— Gaz_Edge
kaynak

24

Bu uygulamanın kendi sunucunuzla iletişim kurmamasının herhangi bir nedeni ve ardından sunucunuz bu istekleri kullanmanız gereken harici hizmete iletir mi? (Bu tür birçok hizmet yine de bu şekilde kullanılmasını yasaklardı)

— thorsten müller

11

API anahtarlarının nihayetinde anlamsız olmasının nedeni budur. Sunucu, komutları gönderen uygulamaya güvenmeye çalışmamalıdır; sadece kullanıcıya güvenmelidir.

— Kevin Panko

42

Aklı başında hiç kimsenin "müşteri tarafı uygulamasını" "hiçbir zaman bir sunucu ile iletişim kurmasına hiçbir koşul altında" olarak tanımlamadığını görmedim - bu, makul bir argümandan ziyade bir adam gibi görünüyor. Açıkça sırayla ölçüde yanıt ve ölçeklenebilirlik artıracak sen eylemlerin büyük çoğunluğu sorunsuz yerel yapılabilir sunucu tarafında işlemek zorunda ama bazı şeyler vardır ..

— Voo

4

"Yalnızca Tarayıcı Uygulamaları" na doğru nerelerde baskı görüyorsunuz? Ne tarif ettiğin gibi bir şey görmedim, müşteri kodunda sırları delice kötü bir fikirde tuttum, tanıdığım en canım sıkıcı adamlar bile bunu asla yapmaz.

— Wheeyls,

2

İstemci tarafında güvenli kaynakları korumaya yönelik herhangi bir girişim mahkumdur, çünkü değişmez güvenlik yasalarının bir çoğunu ihlal eder. # 2/3 - Yazılımınız rakip bilgisayarınızda çalışıyorsa, tanım gereği sizin bilgisayarınız değildir ve zaten kaybettiniz. # 7 bir kaynağı şifrelemeyle korumaya çalışmak istemciye şifre çözme anahtarını sağlamak zorunda olduğunuz için mahkumdur. # 10 hiçbir teknoloji yukarıdakileri düzeltemez. blogs.technet.com/b/rhalbheer/archive/2011/06/16/…

— Dan Neely,

200

Siz yapamazsınız ve insanlar bunu ne kadar çok anlarsa ve o kadar derin anlarsa, dünya için o kadar iyi olur.

Kullanıcının kontrolü altındaki bir cihazda çalışan kod kontrol edilemez. Akıllı telefonlar hapse atılabilir. Set üstü kutular kırılabilir. Sıradan tarayıcılar, JavaScript koduna erişimi engellemeye bile çalışmıyor. Çalmaya veya kötüye kullanmaya değecek bir şeye sahipseniz, sunucu tarafında beslediğiniz her şeyi doğrulamazsanız , kararlı bir saldırgan bunu yapabilir.

Şaşırtma çok az yardımcı olur; uzaktan herhangi bir finansal olay söz konusu olduğunda çekeceğiniz rakip türü, sınıflandırılmış reklamlar gibi bir montaj dili okur. Şifreleme size yardımcı olamaz, çünkü anahtarı koruyacak olan cihaz çatladığını varsaymanız gereken aynı cihazdır. Benzer nedenlerden dolayı işe yaramayan pek çok başka görünüşte açıkça karşı önlemler var.

Ne yazık ki, bu çok uygunsuz bir gerçek. Dünya, bir şekilde uzaktan güvenin temel kırılmasından kurtulabileceklerini düşünen küçük ve büyük zaman operatörleri ile doludur, çünkü kodumuzun kabul ettiğimiz şekilde çalışacağını varsayabilirsek çok güzel olurdu. Ve evet, her şeyi daha da kolaylaştıracak, komik bile değil. Ancak dilek bunu yapmaz ve umutsuzluğa karşı koyabileceğiniz akıllı bir çerez olduğunuzu umarak, sadece sizi ve müşterilerinizi yakar. Bu nedenle, İnternet'in düşman bölgesi olduğu görüşüne gir, tahminlerine katma maliyeti ekle, ve iyi olacaksın.

Tabii ki derinlemesine savunma diye bir şey var. JavaScript’inizi şaşırtmak belirli bir saldırganı engellemez, ancak daha az tespit edilmiş bazı saldırganları engelleyebilir. Eğer varlıklarınızı korumak için yeterince değerliyse, ancak herhangi bir maliyette değilse, bu önlemlerden herhangi biri sisteminize işletme değeri ekleyebilir; sadece mükemmel olamaz. Yaptığınız değişimin tam olarak farkında olduğunuz sürece, bu makul bir strateji olabilir.

— Kilian Foth
kaynak

6

Ancak bunu perspektife koymak: Bu, bir İşletim Sistemi ya da işlem kıyafeti olsun, HER Yazılım için geçerlidir. Sonunda orada çok iyi bazı kod engelleyiciler var ve yazılımınızı hacklemek için acil bir finansal teşvik yoksa, çıtayı yeterince yüksek tutabilirsiniz!

— Falco,

5

Bu günlerde, şirketler işlemden önce onlardan gelen içeriği hackleyen insanlara karşı (örneğin, reklam engelleyiciler aracılığıyla) yasal işlem yapma tehdidinde bulundular. Bu sadece teknik eylemin ne kadar imkansız olduğunu göstermeye gider .

— Kilian Foth

62

İlk iki cümleyi ayrıntılı bir şekilde açıklayabilirsem, incelikli insanların sık sık kaçırdığı şey, istemci tarafı tarayıcı uygulamalarının ağır kaldırma yükünü boşaltmasıdır. Sunucunuz, e-posta göndermek veya verilere erişmek gibi güvenilir işlemlerden hala sorumludur. Müşterinin bu verilerden bir grafik oluşturmasını sağlamak, güvenlik modelini değiştirmeden size CPU zamanından (ve paradan) tasarruf sağlar.

— ssube

11

@ Gaz_Edge Buradaki problemin , müşteri tarafı uygulamaların doğal olarak güvensiz olmadığına dikkat etmek önemlidir . Sorun, bu istemci tarafı uygulamaları müşteriye genel olmasını istemediğiniz bilgilerle güvenmeyi gerektiren bir şekilde yazmaktır. İşlemin çoğunun sunucuda gerçekleştiği bir uygulama kadar güvenli olan istemci ağırlıklı bir uygulama yazmak tamamen mümkündür. (Bununla ilgili daha fazla bilgi için, jhocking'in cevabına bakınız )

— Ajedi32,

7

@ Ajedi32 istemci tarafı uygulamalar vardır güvensiz. İstemci tarafında yapılan herhangi bir mantık sunucu tarafında işaretli değilse güvenli bir uygulama tasarlamak mümkün değildir. Bu noktada, müşteri tarafı mantığı bir UI nezaketine veya temel kontrolleri boşaltma yoluna dönüşür, ancak her şey daima sunucuda kontrol edilmelidir! .

69

Buradaki kural şudur:

Kullanıcı müdahale ederse, başkasını etkilemeyen her şeyi müşteri tarafında yapın. Özellikle, grafiksel etkiler anlamına gelir.

Sunucu tarafında güvenli olması gereken her şeyi yapın ve yalnızca istemciden UI olayları gönderin (örneğin, istemci yalnızca işlemi gerçekleştirirken yalnızca müşterinin "Satın Al düğmesini tıklattığını" söyleyin). Özellikle, bu finansal işlemler anlamına gelir.

— jhocking
kaynak

28

Tamamen müşteri tarafı bir uygulama yapmanın uygun olmadığı durum budur .

Formları istemci tarafında (hala sunucuyu yeniden doğrulamak zorundasınız çünkü birileri isteği kandırmaya çalışabilir) mantığını ve temel doğrulamasını yapabilirsiniz; sayfa süslerini ve benzerlerini yeniden göndermekten kaçının, ancak işlemin kimliğinin doğrulanması ve yetkilendirilmesi gerekiyorsa, yine de bir sunucuda gerçekleşmesi gerekir.

— Jan Hudec
kaynak

11

Not: Formları müşteri tarafında doğrulamak harika olsa da, bunları hiçbir zaman sunucu tarafında da doğrulamayı asla unutmayın! Müşteri kodunuzu tarayıcıya gönderdiğiniz zaman, kodunuz durur! Tekrar gönderdiği her biti doğrulaman gerekiyor!

— Josef

17

Orta paragrafınız sorunun kalbidir:

Bir müşteri tarafı uygulaması çalıştırmak, bunun şimdi bir kullanıcı tarayıcısında yapılması gerektiği anlamına gelir. Üçüncü parti API, bunu başarmak için gerekli olan js dosyalarını sağlar.

Neden bir istemci tarafı uygulaması, sunucu tarafında çalışamayacağınız anlamına geliyor? İstemci tarafı programlamaya itme, sunucuların elimine edilmesi ile ilgili değildir, ancak tarayıcıların nihayet daha iyi kullanıcı arayüzleri oluşturmak için desteklediği daha yeni teknolojilerden yararlanmaktır.

.jsAldığınız dosyaya gelince , bir tarayıcı için yapıldığından emin misiniz? Bir node.js kütüphanesi olabilir mi?

— Brandon
kaynak

4

JS dosyasının bir NodeJS sunucusu için tasarlandığına dair gerçekten iyi bir öneri için +1

— Machinarius

11

Bundan geri adım atalım ve daha üst seviyelere bir göz atalım .. bakalım .. Eudora veya görünüm (bir müşteri tarafı uygulaması, bir tarayıcıya bile gerek duymadan) herhangi bir şirket için maddi kayıplara neden oldu mu? Hayır. Herkes POP / SMTP API'lerine yazabilir ve müşteri olabilir. Ancak sunucuya zarar yok. Sunucu, müşteri işlemlerini, hesaplamaları, depolamayı, sıcaklığı, disk boyutunu, ram boyutunu, monitörün DPI, GPU'sunu, müşterinin FPU'sini veya limitini sınırlamadı, ancak tam olarak neye cevap vereceğini ve daha fazlasını vermeyeceğini belirtti. Hiç bir bankaya kırmak için kullanılan Quicken veya MS-Money duydunuz mu?

Tarayıcınız (yani müşteri tarafı) uygulamanız aynı mimariyi kullanabilir.

Sunucunuzu bir API ile oluşturuyorsunuz (ki bu BTW her zaman GET POST HEAD'in türevlerine kadar kaynar).
Sunucuda, API'nin yalnızca her arama için kimliği doğrulanmış ve kimliği doğrulanmış bir müşteri ile görüşmesini sağlayın.
O zaman müşterinin kim olduğu umrumda değil.
Ve sonra bir tarayıcı, hapsedilmiş cihaz, Google glass, DOS 3.1 veya 2014'e yolculuk etmiş ve hepsini kaçıran bir teknophob büyük-büyük-büyük-büyükbabasının elinde yepyeni bir Nexus'un umrunda değilsin. Son 15 yılda hayatımızı selden alan teknoloji.
Şimdi diğer her şeyi müşteri tarafına yüklemeye başlayabilirsiniz.

SoapBoxBegin

@KilianFoth, esas olarak her zaman başlıkları okuyanlar, ancak uygulamalarına, kodlarına, işverenlerine, müşterilerine, kendi banka hesaplarına asla geleceğini düşünmeyen, saf ve pervasızlar için önemli bir farkındalık noktası yaratır. Daha da önemsiz olanları, herhangi bir sistemi yönetilmeyen / kontrolsüz maruz kalmaya maruz bırakan uygulamaların ortaya çıkmasına izin verecek işverenleridir (özellikle CTO'lar). Ancak ben her zaman "asla öğrenmiyoruz" gibi göründüğüne şaşırdım.

SoapBoxEnd

Yani özetlemek için. Sağlam ve sıkı bir sunucu tarafı API'si yapın. Müşterinin işleyebildiği her şeye dayanarak müşteriye her şeyi boşaltın.

— LMSingh
kaynak

6

Gerçekten yapamayacağını savunuyorum. Verileri müşteriye göndermek istiyorsanız, bunun kötüye kullanılmasını beklemelisiniz - ancak mümkün. API anahtarına ilişkin örneğiniz bu konuyu açıklar ve ben de müşteri tarafınıza JS dahil etmeyeceğim - çalınacak ve kötüye kullanılacak.

İşleri güvende tutmak için kesinlikle bir miktar sunucu koduna ihtiyacınız olacak. Giriş yapan kullanıcıyla ilgili verileri almak kadar basit bir şey. Bu kimlik doğrulama işlemlerinin tümü istemci tarafında yapılamaz veya yine avantaj elde edilir ve verileriniz güvende olmaz.

Her zaman JS istemci tarafı deneyimini sunucu koduna ek olarak görecektim. İstemcide doğrulama, iyi bir kullanıcı deneyimi sağlar, ancak alıcı sunucudaki POST verilerinin de doğrulanmadığını doğrularsanız, saldırmak için kendinizi açıyorsunuzdur. Müşteriden gelen her şey şüpheli olarak kabul edilmelidir.

— Matt Klinker
kaynak

4

Gerçekten çok basit. İstemci bilgisayarın ve üzerinde çalışan tüm yazılımların akıllıca zararlı bir bilgisayar korsanının kontrolü altında olduğunu varsayalım.

Bu, sunucudan istemciye gönderdiğiniz herhangi bir bilginin kötü niyetli bilgisayar korsanının bileceği anlamına gelir, bu nedenle istemcinize sunucunuza veya işinize saldırmak için kullanılabilecek hiçbir bilgi göndermemelisiniz.

Ayrıca, istemciden sunucuya gönderilen herhangi bir şeyin kötü niyetli bilgisayar korsanı tarafından üretildiği anlamına gelir; bu nedenle, sunucu kodunuzun istemcinin gönderebileceği hiçbir şeyin sunucunuza başarıyla saldıramayacağından emin olması gerekir.

Kuşkusuz, uygulama bir sorundur, ancak önemli olan zihinsel tutumdur, sunucunuzun konuştuğunu düşündüğünüz "müşterinin" bir müşteri değil, aktif bir saldırgan olduğu varsayımıdır.

(Ayrıca, kullanıcının iş yöntemlerinizi ihlal etmeye çalışacak, ancak bunun istemci tarafı programlama ile ilgisi olmadığını zeki bir conman olduğunu varsaymanız gerekir).

— gnasher729
kaynak

0

Müşteri Tarafı uygulaması, bence çoğunlukla UI ile ilgilidir. Örneğin, tüm UI sisteminiz bir kez müşteriye gönderilir ve ardından müşteri onunla ne isterse yapar.

Normalde uygulamamın bir sunucuda çalışmasını sağlardım. Üçüncü taraf API’yi sunucumdaki koddan arardım.

Bir istemci tarafı uygulama çalıştırmak, bunun şimdi kullanıcının tarayıcısında yapılması gerektiği anlamına gelir. Üçüncü taraf API, bunu başarmak için gerekli JavaScript dosyalarını sağlar.

Bir API Anahtarınız varsa, müşteri tarafında çalışmak üzere tasarlanmamıştır. API Anahtarını istemci tarafında verirseniz, herkesin erişimi vardır ve bu işlemi kendi amaçları için kullanabilir. İstemci ihtiyaç duyduğunda saklayın ve sunucu tarafında kullanın, ardından sonucu Ajax / WebSockets kullanarak gönderin.

Bankanız şöyle diyordu: "Şey, ana veritabanı istemcisi tarafının şifresini koyacağım, böylece müşteri bunu talep edebilir ve sunucularımızı artık rahatsız etmeyecektir."

— Depado
kaynak