Uzun süre çevrimdışı çalışacak bir web uygulaması geliştirmem gerekiyor. Bunun geçerli olması için hassas verileri (kişisel veriler değil, yalnızca karma olarak saklayacağınız veri türlerini) yerel depolama birimine kaydetmekten kaçınamam.

Bunun önerilen bir uygulama olmadığını kabul ediyorum, ancak çok az seçenek verildiğinde verileri güvence altına almak için aşağıdakileri yapıyorum:

• stanford javascript kripto kütüphanesi ve AES-256 kullanarak yerel depolamaya giden her şeyin şifrelenmesi
• kullanıcı şifresi şifreleme anahtarıdır ve cihazda saklanmaz
• SSL üzerinden tek bir güvenilir sunucudan tüm içeriği (çevrimiçi olduğunda) sunma
• owasp antisamy projesi kullanılarak sunucudaki yerel depolama alanına gidip gelen tüm verilerin doğrulanması
• * kullanmamak ve bunun yerine yalnızca güvenilen sunucuyla bağlantı için gereken URI'ları listelemek
• genel olarak OWASP XSS kopya sayfasında önerilen yönergeleri uygulamaya çalışırken

Şeytanın genellikle ayrıntıda olduğunu takdir ediyorum ve genel olarak yerel depolama ve javascript tabanlı güvenlik hakkında çok fazla şüphecilik olduğunu biliyorum. Herkes olup olmadığını yorumlayabilir:

• Yukarıdaki yaklaşımın temel kusurları?
• bu tür kusurlar için olası çözümler var mı?
• bir html 5 uygulaması uzun süre çevrimdışı çalışması gerektiğinde yerel depolama güvenliğini sağlamak için daha iyi bir yolu var mı?

Herhangi bir yardım için teşekkürler.

WebCrypto

İstemci tarafı (tarayıcı) javascriptindeki şifreleme ile ilgili endişeler aşağıda detaylandırılmıştır. Bu endişelerden biri hariç tümü , şu anda oldukça iyi desteklenen WebCrypto API için geçerli değildir .

Çevrimdışı bir uygulama için güvenli bir anahtar deposu tasarlamanız ve uygulamanız gerekir.

Kenara: Node.js kullanıyorsanız yerleşik kripto API'sını kullanın .

Yerel Javascript Şifrelemesi (WebCrypto öncesi)

Birincil endişenin localStoragesitenizi okuyan bilgisayara fiziksel erişimi olan birinin olduğunu ve kriptografinin bu erişimi önlemeye yardımcı olmasını istediğinizi varsayıyorum.

Birinin fiziksel erişimi varsa, başka saldırılara da açıktır ve okumaktan daha kötüdür. Bunlar aşağıdakileri içerir (ancak bunlarla sınırlı değildir): keylogger'lar, çevrimdışı komut dosyası değişikliği, yerel komut dosyası enjeksiyonu, tarayıcı önbellek zehirlenmesi ve DNS yönlendirmeleri. Bu saldırılar yalnızca kullanıcı makineyi tehlikeye girdikten sonra kullanırsa çalışır. Bununla birlikte, böyle bir senaryoda fiziksel erişim, daha büyük sorunlarınız olduğu anlamına gelir.

Bu nedenle, yerel kriptonun değerli olduğu sınırlı senaryonun, makinenin çalınması olacağını unutmayın.

İstenilen işlevselliği uygulayan kütüphaneler vardır, örneğin Stanford Javascript Crypto Library . Bununla birlikte, doğal zayıflıklar vardır (@ ircmaxell'in cevabından bağlantıda belirtildiği gibi):

1. Entropi eksikliği / rasgele sayı üretimi;
2. Güvenli bir anahtar deposu eksikliği, yani özel anahtar yerel olarak saklanıyorsa veya sunucuda saklanıyorsa (çevrimdışı erişimi engelleyen) şifre korumalı olmalıdır;
3. Güvenli silme eksikliği;
4. Zamanlama özelliklerinin olmaması.

Bu zayıflıkların her biri bir kriptografik uzlaşma kategorisine karşılık gelir. Başka bir deyişle, adıyla "kripto" sahibi olabilirsiniz, ancak uygulamada istediği titizliğin çok altında olacaktır.

Tüm söylenenler, aktüeryal değerlendirme "Javascript kripto zayıftır, kullanmayın" kadar önemsiz değildir. Bu bir onay, kesinlikle bir uyarı değildir ve yukarıdaki zayıflıkların maruz kalmasını, karşılaştığınız vektörlerin sıklığını ve maliyetini ve arıza durumunda hafifletme veya sigorta kapasitenizi tamamen anlamanızı gerektirir: Javascript kripto, zayıflıklarına rağmen, maruziyetinizi azaltabilir, ancak sadece sınırlı teknik kapasiteye sahip hırsızlara karşı. Ancak, Javascript kriptosunun bu bilgileri hedefleyen kararlı ve yetenekli bir saldırgana karşı hiçbir değeri olmadığını varsayalım. Bazıları, uygulamanın pek çok zayıflığının bilindiği durumlarda verilerin "şifreli" olarak adlandırılmasının yanıltıcı olduğunu düşünmektedir. Diğer bir deyişle, teknik riskinizi marjinal olarak azaltabilirsiniz ancak finansal riskinizi ifşadan arttırırsınız. Elbette her durum farklıdır - ve finansal risklere maruz kalmanın teknik olarak azaltılmasının analizi önemsizdir. İşte açıklayıcı bir benzetme:Bazı bankalar , doğası gereği riske rağmen zayıf parolalara ihtiyaç duyarlar , çünkü zayıf parolalardan kaynaklanan kayıplara maruz kalma, güçlü parolaları desteklemenin son kullanıcı maliyetlerinden daha azdır.

🔥 Son paragrafı okuduysanız ve "İnternette Brian adlı bir adam Javascript kripto kullanabileceğimi söylüyor" diye düşündüyseniz, Javascript kripto kullanmayın.

Soruda açıklanan kullanım durumu için, kullanıcıların yerel bölümlerini veya ana dizinlerini şifrelemesi ve güçlü bir şifre kullanması daha anlamlı görünmektedir. Bu tür bir güvenlik genellikle iyi test edilmiş, yaygın olarak güvenilir ve yaygın olarak bulunmaktadır.

Peki, buradaki temel dayanak: hayır, henüz güvenli değil.

Temel olarak, JavaScript'te kripto çalıştıramazsınız: JavaScript Kripto Zararlı .

Sorun, kripto kodunu tarayıcıya güvenilir bir şekilde alamamanızdır ve yapabilseniz bile, JS güvenli bir şekilde çalıştırmanıza izin verecek şekilde tasarlanmamıştır. Dolayısıyla, tarayıcıların bir şifreleme kapsayıcısı olana kadar (Şifrelenmiş Medya Uzantıları sağlar, ancak DRM amaçları için toplanır), güvenli bir şekilde yapmak mümkün olmayacaktır.

"Daha iyi bir yol" olarak, şu anda bir tane yok. Tek alternatifiniz verileri düz metin olarak saklamak ve en iyisini ummaktır. Ya da bilgileri hiç saklamayın. Öyle ya da böyle.

Bu ya da bu tür bir güvenliğe ihtiyacınız varsa ve yerel depolamaya ihtiyacınız varsa, özel bir uygulama oluşturun ...

Bu konunun bir keşfi olarak, "Web Şifreleme API'sini Kullanarak TodoMVC Güvenliğini Sağlama" başlıklı bir sunumum var ( video , kod ).

Uygulamayı parola koruyarak ve şifreleme için parola türetilmiş bir anahtar kullanarak localStorage'da şifrelenmiş yapılacaklar listesini saklamak için Web Şifreleme API'sını kullanır . Şifreyi unutur veya kaybederseniz, kurtarma olmaz. ( Feragatname - bir POC idi ve üretim kullanımı için tasarlanmamıştır. )

Diğer yanıtların belirttiği gibi, bu hala istemci bilgisayarda yüklü olan XSS veya kötü amaçlı yazılımlara karşı hassastır. Ancak, veriler sunucuda depolandığında ve uygulama kullanımdayken hassas veriler de bellekte olur. Çevrimdışı desteğin zorlayıcı kullanım durumu olabileceğini öneririm.

Sonunda, localStorage'ın şifrelenmesi büyük olasılıkla verileri yalnızca sisteme veya yedeklerine salt okuma erişimi olan saldırganlardan korur. OWASP İlk 10 madde A6'ya Duyarlı Veri Maruziyeti için az miktarda savunma ekler ve "Bu verilerden herhangi biri uzun süre açık metin olarak saklanıyor mu?" doğru şekilde.

Bu gerçekten ilginç bir makale. Yerel depolama kullanırken güvenlik sunmak için JS şifrelemesi uygulamayı düşünüyorum. Bunun sadece cihaz çalındığında (ve doğru şekilde uygulandığında) koruma sağlayacağı kesinlikle açıktır. Keylogger'lara karşı koruma sunmayacaktır. Ancak keylogger tehdidi, yürütme platformlarına (tarayıcı, yerel) bakılmaksızın tüm uygulamalarda bir sorun olduğu için bu bir JS sorunu değildir. İlk cevapta atıfta bulunulan "JavaScript Kripto Zarar Görüyor" makalesine gelince, bir eleştirim var; "Bu sorunu çözmek için SSL / TLS kullanabilirsiniz, ancak bu pahalı ve karmaşıktır" şeklinde belirtiyor. Bence bu çok iddialı bir iddia (ve muhtemelen oldukça taraflı). Evet, SSL'nin bir maliyeti var,

Sonucum - İstemci tarafı şifreleme kodu için bir yer var, ancak tüm uygulamalarda olduğu gibi, geliştiricilerin sınırlamalarını tanıması ve ihtiyaçları için uygunsa uygulaması ve risklerini azaltmanın yollarının sağlanması gerekir.

Hiçbir web sayfasına erişilemez (true) ancak chrome (ctl-shift-J) gibi geliştirme araçlarıyla kolayca erişilebilir ve kolayca düzenlenebilir. Bu nedenle, değeri saklamadan önce özel kripto gereklidir.

Ancak, javascript'in şifresini çözmesi (doğrulaması) gerekiyorsa, şifre çözme algoritması ortaya çıkar ve manipüle edilebilir.

Javascript, tamamen güvenli bir kapsayıcıya ve yalnızca js yorumlayıcısı tarafından kullanılabilen özel değişkenleri ve işlevleri düzgün bir şekilde uygulama yeteneğine ihtiyaç duyar. Ancak bu, kullanıcı güvenliğini ihlal eder - izleme verileri cezasız bir şekilde kullanılabilir.

Sonuç olarak, javascript asla tam olarak güvenli olmayacaktır.

Hayır.

localStorage'a herhangi bir web sayfası tarafından erişilebilir ve anahtara sahipseniz, istediğiniz verileri değiştirebilirsiniz.

Bununla birlikte, anahtarları güvenli bir şekilde şifrelemek için bir yol tasarlayabilirseniz, verileri nasıl aktardığınız önemli değildir, verileri bir kapatma içinde tutabilirseniz, veriler (bir şekilde) güvenlidir.