JavaScript'i kesmek ne kadar kolaydır (bir tarayıcıda)?

Benim sorum JavaScript güvenliği ile ilgili.

Omurga veya AngularJS gibi bir JavaScript çerçevesi kullandığınız ve güvenli uç noktalara ihtiyacınız olduğu bir kimlik doğrulama sistemi hayal edin . Bu bir problem değildir, çünkü sunucu her zaman son kelimeye sahiptir ve istediğinizi yapmaya yetkili olup olmadığınızı kontrol edecektir.

Peki ya sunucuyu dahil etmeden biraz güvenceye ihtiyacınız varsa? Mümkün mü?

Örneğin, müşteri tarafında bir yönlendirme sisteminizin olduğunu ve oturum açan kullanıcılar için korunacak bir somut yolun olmasını istediğinizi varsayalım. Böylece, sunucuya ping uygulayarak korumalı rotaları ziyaret etmenize izin verilip verilmediğini sorabilirsiniz. Sorun şu ki, sunucuya ping yaparken, yanıtı değişkende saklarsınız, bu yüzden bir dahaki sefere özel bir rotaya gittiğinizde, önceden giriş yapmışsanız (sunucuya ping atmadan) ve Tepki üzerine gider ya da gitmez.

Bir kullanıcının bu değişkeni değiştirmesi ve erişmesi ne kadar kolaydır?

Güvenlik (ve JavaScript) bilgim mükemmel değil. Ancak bir değişken global kapsamda değilse ve sadece alıcıları olan, ancak ayarlayıcıları olmayan bir modül modelinin özel kısmındaysa, bu durumu bile kesebilir misiniz?

Lütfen bunu okumadan önce Joachim'in cevabını okuyun . Müşteri tarafında güvenlik açığının ardındaki genel nedenleri kapsar. Şimdi, bir öneri için, bu problemi nasıl çözebileceğiniz ...

Her talepte sunucu ile manuel olarak kimlik doğrulaması yapmak zorunda kalmadan istemci-sunucu iletişimi için güvenli bir şema:

Sunucunun son söz sahibi olmasına hala izin veriyorsunuz ve sunucunun hala müşterinin söylediği her şeyi doğrulaması gerekiyor, ancak şeffaf olarak gerçekleşiyor.

Ortadaki adam saldırılarını (MITMA) önlemek için HTTPS protokolünü kullanın .

• Müşteri ilk kez sunucuyla el sıkışır ve sunucu müşteri için ortak bir anahtar oluşturur ve bir asimetrik şifreleme düzeni kullanarak özel bir tane tutar. İstemci, sunucunun "genel" anahtarını, hiçbir yerde kaydetmediğiniz güvenli bir parola ile şifrelenmiş yerel depoda saklar.

• İstemci şimdi çevrimdışı. Müşteri güvenilir işlemler yapmak istiyor. İstemci şifresini girer ve sunucunun ortak anahtarını alır.

• Şimdi istemci eylemleri gerçekleştirir bu verilerin kendi bilgiye dayalı ve istemci sunucunun genel anahtar ile gerçekleştiren her eylem şifreler o müşteri için .

• Müşteri çevrimiçi olduğunda, müşteri kimliğini gönderir ve müşterinin yaptığı tüm eylemler, sunucunun ortak anahtarıyla şifrelenmiş sunucuya gönderilir.

• Sunucu eylemlerin şifresini çözer ve doğru biçimde ise istemciden kaynaklandığına güvenir.

Not:

• Müşterinin şifresini hiçbir yerde saklayamazsınız, aksi takdirde bir saldırgan anahtarı alabilir ve eylemleri kendi olarak imzalayabilir. Bu programın güvenliği yalnızca sunucunun istemci için oluşturduğu anahtarın bütünlüğüne dayanır. İstemcinin, o anahtar için sorulduğunda sunucunun kimliğini doğrulaması gerekir.

• Aslında istemciye değil , güvenlik için sunucuya güveniyorsunuz . Her eylem istemcisi gerçekleştirir gerekir sunucuda doğrulamak.

• Web çalışanlarında harici scriptler çalıştırmak mümkündür . Unutmayın her JSONP sahip isteği artık çok daha büyük bir güvenlik sorunudur. Her ne pahasına olursa olsun anahtarı korumalısınız. Kaybettikten sonra bir saldırgan kullanıcıyı taklit edebilir.

• Bu, 'sunucuya ping işlemi yapmama' talebini karşılar. Saldırgan, anahtarı bilmediği taktirde sahte bir HTTP isteğini taklit edemez.

• Joachim'in cevabı hala doğru . Aslında hala, sunucudaki tüm kimlik doğrulamasını yapıyorsunuz . Buraya kaydettiğiniz tek şey, sunucuyla her seferinde parola doğrulama ihtiyacıdır. Şimdi yalnızca güncellemek istediğinizde sunucuyu dahil etmeniz veya güncelleştirilmiş verileri çekmeniz gerekir. Burada yaptığımız tek şey, müşteri tarafında güvenilir bir anahtarın kaydedilmesi ve müşterinin tekrar doğrulaması.

• Bu, tek sayfa uygulamalar için (örneğin, AngularJS ile) oldukça yaygın bir şemadır.

• RSA gibi programlarda ne anlama geldiğinden sunucunun genel anahtarını "public" olarak adlandırıyorum , ancak aslında programdaki hassas bilgilerdir ve korunmaları gerekir.

• Şifreyi hiçbir yerde hafızada tutmam. Çevrimdışı kod çalıştırmaya başladığında, kullanıcının 'çevrimdışı' şifresini göndermesini sağlardım.

• Kendi şifrelemenizi kullanmayın - kimlik doğrulaması için Stanford'ınki gibi bilinen bir kitaplık kullanın.

• Bu tavsiyeyi olduğu gibi alın . İş dünyasında kritik öneme sahip bir uygulamada bu tür bir kimlik doğrulaması yapmadan önce bir güvenlik uzmanına danışın . Bu hem acı verici hem de yanlış anlaşılması kolay olan ciddi bir konudur .

Diğer hiçbir komut dosyasının sayfaya erişememesi çok önemlidir . Bu, yalnızca web çalışanlarıyla dış komut dosyalarına izin verdiğiniz anlamına gelir. Kullanıcı girdiğinde parolanızı etkileyebilecek diğer harici komut dosyalarına güvenemezsiniz.

Bir kullan promptve yok değil tamamen emin değil erteleme onun yürütme yaparsanız bir satır içi Şifre alanını (olduğunu, olması gerektiği olaylar bu bilgilere erişimi ama sadece senkronizasyon kodu var bir noktaya canlı değil). Ve aslında şifreyi bir değişkende saklamayın - yine, bu yalnızca kullanıcının bilgisayarının tehlikeye girmediğinden emin olmanız durumunda işe yarar (her şey bir sunucuya karşı doğrulama için de geçerlidir).

Müşteriye hala güvenmediğimizi tekrar eklemek isterim . Sen olamaz yalnız müşteri güven ve ben Joachim cevabı çivi bunu düşünüyorum. Çalışmaya başlamadan önce sadece sunucuya ping atmamak zorunda kaldık.

İlgili materyal:

• Sertifikalar vs kullanıcı adı + şifre .
• Neden müşteri tarafında güvenlik sağlayamıyoruz?
• Kendi şifreni yuvarlama.
• JS'yi kripto işlemleri için güvenli hale getirme hakkında ilgili tartışma

Çok basit: müşteriye yalnızca yapmasını istediğiniz şeyi yapmaya çalışan herhangi bir güvenlik mekanizması, bir saldırgan istemci üzerinde kontrol sahibi olduğunda tehlikeye girebilir.

Sen olabilir istemci üzerinde güvenlik kontrolleri var, ama sadece etkili için (istemci zaten cevap "hayır" olacağını biliyorsa sunucuya pahalı bir ring seferi yapmaktan kaçınmaya) bir "cache" olarak görev yapar.

Bilgileri bir kullanıcı grubundan saklamak istiyorsanız, bu kullanıcıların istemcisinin asla bu bilgilere ulaşmadığından emin olun . Bu "gizli verileri" talimatlarla birlikte "gönderirseniz, ancak lütfen görüntülemeyin", bu isteği denetleyen kodu devre dışı bırakmak önemsiz hale gelir.

Gördüğünüz gibi, bu cevap herhangi bir JavaScript / Tarayıcı özelliğinden bahsetmiyor. Çünkü bu konsept aynı, müşteriniz ne olursa olsun aynı. Gerçekten önemli bir müşteri (sunucu / sunucu uygulaması), eski bir web uygulaması veya geniş bir müşteri tarafı JavaScript'i içeren tek sayfalık bir uygulama olması önemli değil.

Verileriniz sunucudan ayrıldıktan sonra, bir saldırganın ona tam erişimi olduğunu varsaymalısınız.

Oyun dünyasında bir söz var: " Müşteri düşmanın elinde.". Sunucu gibi güvenli bir alanın dışında çalışan herhangi bir kod savunmasızdır. En temel senaryoda, ilk etapta çalıştırılmaya karşı savunmasızdır. Müşterinin," güvenlik kodunuzu "çalıştırma kararı ve kullanıcı sadece "vazgeç" dir. Yerel kodla, en azından otomatik olarak bir gizleme zorunluluğuna ve bir saldırganın manipüle etmek için iyi bir programcı olması gerektiğine bağlı olarak ek bir koruma katmanına sahip olsanız da JS normal olarak düzensiz ve düz metin olarak gelir. Saldırıya ihtiyacınız olan tek şey bir proxy sunucusu ve bir metin editörü gibi ilkel araçlardır Saldırganın programlamaya ilişkin belirli bir eğitim düzeyine ihtiyacı olacaktır, ancak herhangi bir metin düzenleyiciyi kullanarak bir komut dosyasını değiştirmek için yürütülebilir bir kod enjekte etmekten çok daha kolaydır.

Bu, JavaScript kırma meselesi değildir. Uygulamanıza saldırmak isteseydim, trafiği yakalamama, değiştirmeme ve tekrar oynatmamı sağlayacak özel bir proxy kullanırdım. Önerilen güvenlik planınız buna karşı herhangi bir korumaya sahip görünmüyor.

Özellikle Açısal hakkında konuşma:

Bir rota istemcisi tarafını korumak sadece mevcut değil. Bu rotaya bir düğme 'gizleseniz' bile, kullanıcı her zaman yazabilir, Angular şikayet eder, ancak müşteri bunu kodlayabilir.

Bir noktada, kontrol cihazınız sunucunuzdan görünümü oluşturmak için gereken verileri istemesi gerekecektir, kullanıcı bu verilere erişme yetkisine sahip değilse, bu verileri sunucu tarafında koruduğunuz için alamazlar. , ve Angular uygulamanızın 401'i uygun şekilde işlemesi gerekir.

Ham verileri korumaya çalışıyorsanız, müşteri tarafında olamazsınız, yalnızca belirli bir kullanıcının yalnızca ortak verileri belirli bir şekilde görüntüleyebilmesini istiyorsanız, göndermek yerine sunucuda 'görünümler' verilerini oluşturun istemciye ham veriler ve yeniden düzenlemesini sağlamak (zaten zaten performans nedenleriyle bunu yapmalısınız).

Yan not: Angular'ın istediği, görüntüleme şablonlarında yerleşik olan hiçbir şeyin hassas olmaması gerekir. Eğer çılgınca bir sebepten dolayı, sunucu tarafında görüntü oluşturma işlemini yaptığınız gibi, sunucu tarafında bu görünüm şablonlarını korumanız gerekir.