क्या स्थानीय भंडारण को कभी सुरक्षित माना जा सकता है? [बन्द है]

Question

मुझे एक वेब एप्लिकेशन विकसित करने की आवश्यकता है जो लंबे समय तक ऑफ़लाइन कार्य करेगा। इसे व्यवहार्य बनाने के लिए मैं संवेदनशील डेटा (व्यक्तिगत डेटा को सहेजने से नहीं बचा सकता लेकिन इस तरह का डेटा जो आप केवल हैश को स्टोर करेंगे) को स्थानीय संग्रहण में नहीं रखा जा सकता।

मैं स्वीकार करता हूं कि यह अनुशंसित अभ्यास नहीं है, लेकिन कुछ विकल्प दिए गए हैं जो मैं डेटा को सुरक्षित करने के लिए कर रहा हूं:

• स्टैनफोर्ड जावास्क्रिप्ट क्रिप्टो लाइब्रेरी और एईएस -256 का उपयोग करके स्थानीय भंडारण में जाने वाली सभी चीजों को एन्क्रिप्ट करना
• उपयोगकर्ता पासवर्ड एन्क्रिप्शन कुंजी है और डिवाइस पर संग्रहीत नहीं है
• ssl पर एक भी विश्वसनीय सर्वर से सभी सामग्री (जब ऑनलाइन) की सेवा
• Owasp antisamy प्रोजेक्ट का उपयोग कर सर्वर पर स्थानीय भंडारण से जाने वाले सभी डेटा को मान्य करना
• Appcache के नेटवर्क सेक्शन में, * का उपयोग नहीं करते हैं, और इसके बजाय केवल विश्वसनीय सर्वर से कनेक्शन के लिए आवश्यक URI को सूचीबद्ध करते हैं
• सामान्य रूप से OWASP XSS धोखा पत्र में सुझाए गए दिशानिर्देशों को लागू करने की कोशिश कर रहा है

मैं सराहना करता हूं कि शैतान अक्सर विस्तार में है, और जानता है कि सामान्य रूप से स्थानीय भंडारण और जावास्क्रिप्ट-आधारित सुरक्षा के बारे में बहुत संदेह है। क्या कोई टिप्पणी कर सकता है कि क्या हैं:

• उपरोक्त दृष्टिकोण में मूलभूत दोष?
• इस तरह की खामियों के लिए कोई संभव समाधान?
• जब एचटीएमएल 5 आवेदन लंबे समय तक ऑफ़लाइन होना चाहिए, तो स्थानीय भंडारण को सुरक्षित करने का कोई बेहतर तरीका?

किसी भी मदद के लिए धन्यवाद।

Comments

"मैं स्वीकार करता हूं कि यह अनुशंसित अभ्यास नहीं है" - क्या ऐसा है? क्या यह विपरीत नहीं है कि यह वास्तव में उसी के लिए बनाया गया है?

— हकरे

स्पष्ट करने के लिए, मेरा मतलब था कि स्थानीय भंडारण में संवेदनशील डेटा को संग्रहीत करने के लिए अभ्यास की सिफारिश नहीं की गई है ।

— user1173706

जैसे कि आपको बड़े नेटवर्क पर संवेदनशील डेटा पास नहीं करना चाहिए ?

— हकरे

@ user1173706 एप्लिकेशन को कार्य करने के लिए ऑफ़लाइन समय की विस्तारित अवधि के लिए क्यों चलना पड़ता है? उपयोगकर्ता क्या पसंद कर रहे हैं? आपको किन ब्राउज़र का समर्थन करना है? मुझे लगता है कि यह संभव है, लेकिन मुझे आपके परिदृश्य के बारे में जानना चाहिए ।

— बेंजामिन ग्रुएनबाम

@ बैंजामिन i ने सवाल अपडेट किया है। धन्यवाद।

— user1173706

Answer 1

WebCrypto

क्लाइंट-साइड (ब्राउज़र) जावास्क्रिप्ट में क्रिप्टोग्राफी के साथ चिंताएं नीचे दी गई हैं। इन सभी चिंताओं में से एक WebCrypto API पर लागू नहीं होती है , जो अब यथोचित समर्थित है ।

एक ऑफ़लाइन ऐप के लिए, आपको अभी भी एक सुरक्षित कीस्टोर को डिज़ाइन और कार्यान्वित करना होगा।

एक तरफ: यदि आप Node.js का उपयोग कर रहे हैं, तो अंतर्निहित क्रिप्टो एपीआई का उपयोग करें ।

देशी-जावास्क्रिप्ट क्रिप्टोग्राफी (प्री-वेबक्रिप्ट)

मुझे लगता है कि प्राथमिक चिंता यह है कि localStorageआपकी साइट के लिए पढ़ने वाले कंप्यूटर पर भौतिक पहुंच वाले व्यक्ति हैं , और आप चाहते हैं कि क्रिप्टोग्राफी उस पहुंच को रोकने में मदद करे।

अगर किसी की शारीरिक पहुंच है तो आप दूसरे पर हमला करने और पढ़ने से भी बदतर हैं। इनमें शामिल हैं (लेकिन यह सीमित नहीं हैं): कीलॉगर्स, ऑफ़लाइन स्क्रिप्ट संशोधन, स्थानीय स्क्रिप्ट इंजेक्शन, ब्राउज़र कैश पॉइज़निंग, और डीएनएस अप्रत्यक्ष। वे हमले केवल तभी काम करते हैं यदि उपयोगकर्ता मशीन का उपयोग करने के बाद समझौता कर लेता है। फिर भी, ऐसे परिदृश्य में भौतिक पहुंच का मतलब है कि आपको बड़ी समस्याएं हैं।

तो ध्यान रखें कि स्थानीय परिदृश्य जहां स्थानीय क्रिप्टो मूल्यवान है अगर मशीन चोरी हो जाती है।

पुस्तकालय हैं जो वांछित कार्यक्षमता को लागू करते हैं, जैसे स्टैनफोर्ड जावास्क्रिप्ट क्रिप्टो लाइब्रेरी । हालाँकि, अंतर्निहित कमज़ोरियाँ हैं, (जैसा कि @ ircmaxell के उत्तर से लिंक में उल्लिखित है):

1. एन्ट्रापी / यादृच्छिक संख्या पीढ़ी का अभाव;
2. सुरक्षित कीस्टोर का अभाव यानी निजी कुंजी को पासवर्ड-सुरक्षित होना चाहिए यदि स्थानीय रूप से संग्रहीत किया जाता है, या सर्वर पर संग्रहीत किया जाता है (जो ऑफ़लाइन पहुंच को बार करता है);
3. सुरक्षित-मिटा का अभाव;
4. समय की विशेषताओं का अभाव।

इन कमजोरियों में से प्रत्येक क्रिप्टोग्राफिक समझौता की श्रेणी से मेल खाती है। दूसरे शब्दों में, जबकि आपके पास नाम से "क्रिप्टो" हो सकता है, यह व्यवहार में एक इच्छा के विपरीत अच्छा होगा।

कहा जा रहा है कि सभी, मूल्यांकन मूल्यांकन उतना तुच्छ नहीं है जितना "जावास्क्रिप्ट क्रिप्टो कमजोर है, इसका उपयोग न करें"। यह एक समर्थन नहीं है, सख्ती से एक चेतावनी है और इसके लिए आपको उपरोक्त कमजोरियों के जोखिम, आपके द्वारा सामना किए जाने वाले वैक्टर की आवृत्ति और लागत और विफलता की स्थिति में शमन या बीमा के लिए आपकी क्षमता: जावास्क्रिप्ट क्रिप्टो, को समझने की आवश्यकता है। अपनी कमजोरियों के बावजूद, आपके जोखिम को कम कर सकता है लेकिन केवल सीमित तकनीकी क्षमता वाले चोरों के खिलाफ। हालाँकि, आपको यह मान लेना चाहिए कि जावास्क्रिप्ट क्रिप्टो में एक निर्धारित और सक्षम हमलावर के खिलाफ कोई मूल्य नहीं है जो उस जानकारी को लक्षित कर रहा है। कुछ लोग इसे डेटा को "एन्क्रिप्टेड" कहने के लिए भ्रामक मानते हैं जब कार्यान्वयन के लिए कई कमजोरियों को अंतर्निहित माना जाता है। दूसरे शब्दों में, आप अपने तकनीकी प्रदर्शन को थोड़ा कम कर सकते हैं लेकिन आप अपने वित्तीय जोखिम को प्रकटीकरण से बढ़ा सकते हैं। प्रत्येक स्थिति अलग है, ज़ाहिर है - और वित्तीय जोखिम के लिए तकनीकी जोखिम को कम करने का विश्लेषण गैर-तुच्छ है। यहाँ एक दृष्टांत सादृश्य है:कुछ बैंकों को अंतर्निहित जोखिम के बावजूद, कमजोर पासवर्ड की आवश्यकता होती है , क्योंकि कमजोर पासवर्ड से नुकसान का जोखिम मजबूत पासवर्ड का समर्थन करने के अंत-उपयोगकर्ता की लागत से कम है।

Guy यदि आपने अंतिम पैराग्राफ पढ़ा और सोचा "ब्रायन नाम के इंटरनेट पर कोई लड़का कहता है कि मैं जावास्क्रिप्ट क्रिप्टो का उपयोग कर सकता हूं", जावास्क्रिप्ट क्रिप्टो का उपयोग न करें।

प्रश्न में वर्णित उपयोग के मामले के लिए यह उपयोगकर्ताओं के लिए अपने स्थानीय विभाजन या होम निर्देशिका को एन्क्रिप्ट करने और एक मजबूत पासवर्ड का उपयोग करने के लिए अधिक समझ में आता है। उस प्रकार की सुरक्षा आमतौर पर अच्छी तरह से जांच की जाती है, व्यापक रूप से विश्वसनीय और आमतौर पर उपलब्ध है।

Comments

2011 से एनसीसी समूह द्वारा उपलब्ध कराए गए "जावास्क्रिप्ट क्रिप्टो का उपयोग न करें" के सामान्य रुख के लिए अतिरिक्त दस्तावेज (उद्धरण) उपलब्ध हैं: जावास्क्रिप्ट क्रिप्टोग्राफी को हानिकारक माना जाता है (विशेष रूप से डाउनलोड को सत्यापित करने के लिए टूल डाउनलोड करने के कैच -22 के कारण ... PRNG गुणवत्ता … इत्यादि)

— 26:३०

Answer 2

खैर, यहां मूल आधार है: नहीं, यह अभी तक सुरक्षित नहीं है।

असल में, आप जावास्क्रिप्ट में क्रिप्टो नहीं चला सकते हैं: जावास्क्रिप्ट क्रिप्टो हानिकारक माना जाता है ।

समस्या यह है कि आप मज़बूती से ब्राउज़र में क्रिप्टो कोड प्राप्त नहीं कर सकते हैं, और यहां तक ​​कि अगर आप कर सकते हैं, तो जेएस को आपको इसे सुरक्षित रूप से चलाने के लिए डिज़ाइन नहीं किया गया है। इसलिए जब तक ब्राउज़रों के पास एक क्रिप्टोग्राफ़िक कंटेनर (जो एन्क्रिप्ट किए गए मीडिया एक्सटेंशन प्रदान करते हैं, लेकिन उनके DRM उद्देश्यों के लिए रैल किए जा रहे हैं), तब तक सुरक्षित रूप से करना संभव नहीं होगा।

जहाँ तक "बेहतर तरीका" है, वहाँ अभी एक नहीं है। आपका एकमात्र विकल्प डेटा को सादे पाठ में संग्रहीत करना है, और सर्वश्रेष्ठ के लिए आशा है। या जानकारी को स्टोर न करें। किसी भी तरह से।

या तो वह, या यदि आपको उस प्रकार की सुरक्षा की आवश्यकता है, और आपको स्थानीय संग्रहण की आवश्यकता है, तो एक कस्टम एप्लिकेशन बनाएं ...

Comments

Downvoter: क्या आप बेहतर उत्तर दे सकते हैं? मुझे लगता है कि यह कुछ हद तक विवादास्पद मुद्दा है जहां सुरक्षा पेशेवरों (और गैर-पेशेवरों) के बीच महत्वपूर्ण असहमति है, इसलिए वैकल्पिक दृश्य-बिंदु साझा करने के लायक होगा। जब तक आप किसी अन्य कारण से नीचे नहीं जा रहे हैं, उस स्थिति में मैं इस उत्तर को कैसे सुधार सकता हूं?

— १

@ircmaxell मुझे नहीं, लेकिन मैं इस जवाब से असहमत हूं। "समस्या यह है कि आप मज़बूती से ब्राउज़र में क्रिप्टो कोड प्राप्त नहीं कर सकते हैं, और यहां तक ​​कि अगर आप कर सकते हैं, तो जेएस को आपको इसे सुरक्षित रूप से चलाने के लिए डिज़ाइन नहीं किया गया है।" - क्यों? अंतर्निहित समस्या क्या है? आप स्टैनफोर्ड जावास्क्रिप्ट एन्क्रिप्शन लाइब्रेरी और इसमें एन्क्रिप्ट / डिक्रिप्ट का उपयोग कर सकते हैं। आप हैश कर सकते हैं, और आप सुरक्षित रूप से सब कुछ कर सकते हैं। जेएस में मानक क्रॉपीओ कर रहे ऑफ़लाइन ऐप में मुझे यहाँ अंतर्निहित समस्या नहीं दिख रही है, किसी अन्य भाषा में निर्मित ऐप की तरह।

— बेंजामिन ग्रुएनबाम

@BenjaminGruenbaum: समस्या यह है कि कई स्थान हैं जहां उस क्रिप्टो-कोड को तीसरे नंबर के कोड के साथ इंटरैक्ट करना होगा। उस लेख का पूरा बिंदु यह है कि आप निष्पादन पर्यावरण को नियंत्रित नहीं कर सकते। तो आप स्टैनफोर्ड क्रिप्टो लिब स्थापित करें। फिर क्या होगा अगर कुछ ब्राउज़र प्लगइन sjcl.encryptहमलावर को कुंजी ईमेल करने के लिए ओवरराइड करता है? JS में यह 100% संभव है और इसे रोकने के लिए आप कुछ नहीं कर सकते। और वह अंतर्निहित बिंदु है। अन्य जेएस को आपके डेटा को गंदा करने से रोकने के लिए कोई "सुरक्षा" तंत्र नहीं हैं। और यह एक समस्या है ।

— ircmaxell

@ircmaxell यदि आप कुत्तों के साथ सोते हैं, तो आप fleas के साथ जागने की उम्मीद नहीं कर सकते। यदि उपयोगकर्ता एक मैलवेयर ऐड इंस्टॉल करता है, तो यह उसी तरह है जैसे कि उपयोगकर्ता अपने पीसी पर वायरस इंस्टॉल कर रहा है, यह उससे अलग नहीं है। आपका जावा या सी प्रोग्राम उतना ही सुरक्षित हो सकता है जितना इसे प्राप्त होता है लेकिन जैसे ही हमलावर के पास कोड चलाने की क्षमता होती है आप खराब हो जाते हैं। जेएस के लिए यह अलग नहीं है। Addons ब्राउज़र में केवल जादुई रूप से प्रकट नहीं होते हैं। इसके अलावा, एन्क्रिप्ट की गई जानकारी को सहेजने से उपयोगकर्ता को मैलवेयर होने पर किसी भी तरह से मदद नहीं मिलेगी, क्योंकि यह डेटा को लाइव करने में बाधा उत्पन्न कर सकता है।

— बेंजामिन ग्रुएनबाम

@BenjaminGruenbaum: असहमत। एक सामान्य एप्लिकेशन में, आपको या तो ऐप को स्वयं (मेमोरी स्थानों को पढ़ने के लिए) समझौता करना होगा, या बॉक्स पर रूट एक्सेस प्राप्त करना होगा (ओएस से समझौता करना होगा)। किसी भी तरह से, आपको सामान्य व्यवहार करने की तुलना में कुछ गहरा समझौता करने की आवश्यकता है। जेएस सामान्य व्यवहार में यह अनुमति देता है। कौन सी समस्या है ...

— ircmaxell

Answer 3

इस विषय की खोज के रूप में, मेरी एक प्रस्तुति है जिसका शीर्षक है "सिक्योरिंग टूडो एमवीसी वेब क्रिप्टोग्राफी एपीआई का उपयोग करना" ( वीडियो , कोड )।

यह वेब क्रिप्टोग्राफी एपीआई का उपयोग अनुप्रयोग की रक्षा करने वाले पासवर्ड द्वारा स्थानीयस्टोरेज में एन्क्रिप्टेड टूडू सूची को स्टोर करने और एन्क्रिप्शन के लिए पासवर्ड व्युत्पन्न कुंजी का उपयोग करने के लिए करता है। यदि आप पासवर्ड भूल जाते हैं या खो देते हैं, तो कोई पुनर्प्राप्ति नहीं है। ( डिस्क्लेमर - यह एक पीओसी था और इसका उपयोग उत्पादन के लिए नहीं किया गया था। )

अन्य उत्तर के रूप में, यह अभी भी XSS या क्लाइंट कंप्यूटर पर स्थापित मैलवेयर के लिए अतिसंवेदनशील है। हालाँकि, कोई भी संवेदनशील डेटा स्मृति में होगा जब डेटा सर्वर पर संग्रहीत होता है और एप्लिकेशन उपयोग में होता है। मेरा सुझाव है कि ऑफ़लाइन समर्थन सम्मोहक उपयोग का मामला हो सकता है।

अंत में, लोकलस्टोरेज को एन्क्रिप्ट करना संभवतः केवल हमलावरों के डेटा की सुरक्षा करता है जो केवल सिस्टम या इसके बैकअप तक पहुंच पढ़ चुके हैं। यह OWASP शीर्ष 10 आइटम A6-Sensitive Data Exposure के लिए गहराई से रक्षा की एक छोटी राशि जोड़ता है , और आपको जवाब देने की अनुमति देता है "क्या इस डेटा में से कोई भी स्पष्ट पाठ लंबी अवधि में संग्रहीत है?" सही ढंग से।

Answer 4

यह यहाँ एक बहुत ही दिलचस्प लेख है। मैं स्थानीय भंडारण का उपयोग करते समय सुरक्षा प्रदान करने के लिए JS एन्क्रिप्शन लागू करने पर विचार कर रहा हूं। यह बिल्कुल स्पष्ट है कि यह केवल सुरक्षा की पेशकश करेगा यदि डिवाइस चोरी हो गया है (और सही तरीके से लागू किया गया है)। यह keyloggers आदि के खिलाफ सुरक्षा की पेशकश नहीं करेगा। हालांकि यह एक जेएस मुद्दा नहीं है क्योंकि keylogger खतरा सभी अनुप्रयोगों की समस्या है, भले ही उनके निष्पादन मंच (ब्राउज़र, देशी) की परवाह किए बिना। जैसा कि लेख "जावास्क्रिप्ट क्रिप्टो माना जाता है हानिकारक" पहले उत्तर में संदर्भित है, मेरी एक आलोचना है; यह बताता है कि "आप इस समस्या को हल करने के लिए एसएसएल / टीएलएस का उपयोग कर सकते हैं, लेकिन यह महंगा और जटिल है"। मुझे लगता है कि यह एक बहुत ही महत्वाकांक्षी दावा है (और संभवतः पक्षपाती)। हाँ, एसएसएल की एक लागत है,

मेरा निष्कर्ष - क्लाइंट-साइड एन्क्रिप्शन कोड के लिए एक जगह है, हालांकि सभी अनुप्रयोगों के साथ डेवलपर्स को इसकी सीमाओं को पहचानना चाहिए और यदि उनकी आवश्यकताओं के लिए उपयुक्त है तो इसे लागू करना चाहिए, और यह सुनिश्चित करने के तरीके हैं कि यह जोखिमों को कम करने के तरीके हैं।

Comments

ऐतिहासिक रूप से प्रारंभिक कनेक्शन बातचीत के साथ असाधारण लागतें (यांत्रिक, वित्तीय नहीं) थीं। इस बिंदु पर कि निगम समर्पित SSL समाप्ति उपकरणों का उपयोग करेंगे, जो प्रमाणपत्र जारी करने और आश्वासन लागतों से परे आर्थिक रूप से महंगा हो सकता है। आज उनमें से कई मुद्दों को सुलझा लिया गया है, जैसे बाद के अनुरोधों पर प्रारंभिक हैंडशेक से बचने के लिए विस्तारित अवधि सत्र दृढ़ता।

— अमाकेलॉयर

Answer 5

किसी भी वेबपृष्ठ (सत्य) तक पहुंच योग्य नहीं है, लेकिन आसानी से सुलभ है और देव टूल्स के माध्यम से आसानी से संपादित किया जा सकता है, जैसे क्रोम (सीटीएल-शिफ्ट-जे)। इसलिए, मूल्य को संग्रहीत करने से पहले कस्टम क्रिप्टो आवश्यक है।

लेकिन, अगर जावास्क्रिप्ट को डिक्रिप्ट (मान्य करने के लिए) करने की आवश्यकता है, तो डिक्रिप्ट एल्गोरिथ्म उजागर हो जाता है और हेरफेर किया जा सकता है।

जावास्क्रिप्ट को पूरी तरह से सुरक्षित कंटेनर और निजी चर और कार्यों को ठीक से लागू करने की क्षमता की आवश्यकता है जो केवल जेएस दुभाषिया के लिए उपलब्ध हैं। लेकिन, यह उपयोगकर्ता सुरक्षा का उल्लंघन करता है - चूंकि ट्रैकिंग डेटा का उपयोग अशुद्धता के साथ किया जा सकता है।

नतीजतन, जावास्क्रिप्ट कभी भी पूरी तरह से सुरक्षित नहीं होगा।

Answer 6

नहीं।

किसी भी वेबपृष्ठ द्वारा लोकलस्टोरेज सुलभ है, और यदि आपके पास कुंजी है, तो आप जो चाहें डेटा बदल सकते हैं।

यह कहा जा रहा है, यदि आप कुंजी को सुरक्षित रूप से एन्क्रिप्ट करने का एक तरीका तैयार कर सकते हैं, तो इससे कोई फर्क नहीं पड़ता कि आप डेटा को कैसे स्थानांतरित करते हैं, यदि आप डेटा को किसी क्लोजर में शामिल कर सकते हैं, तो डेटा सुरक्षित (कुछ हद तक) है।

Comments

यह "किसी भी वेबपेज" के लिए प्रशंसनीय नहीं है। यह केवल वर्तमान डोमेन के पृष्ठों तक ही पहुँचा जा सकता है।

— dtabuenc

@dtabuenc इसके विपरीत, मैंने कुछ समय पहले एक पेन बनाया था जो आपके लोकलस्टोरीज में बिना किसी हैक्स के हर एक कुंजी / मूल्य युग्म दिखाता है ।

— नरकोल ११

नहीं! माफ़ करना। स्थानीय संग्रहण प्रति डोमेन अलग-थलग है। एक डोमेन में चल रहा कोड उन मानों तक नहीं पहुंच सकता है जो किसी अन्य डोमेन द्वारा स्थानीय भंडारण में संग्रहीत किए गए थे। उदाहरण के लिए, google.com लोकल स्टोरेज में सामान का एक गुच्छा संग्रहीत करता है। आप अपने पेन उदाहरण में google.com से किसी भी कुंजी को सूचीबद्ध नहीं कर पाएंगे।

— dtabuenc

@dababenc ने इसका परीक्षण किया, आप सही कह रहे हैं।

— नरकंकाल ११