क्लाइंट-साइड वेब एप्लिकेशन में गुप्त डेटा को सुरक्षित रूप से संग्रहीत करना


11

मेरे पास यह वेब एप्लिकेशन है जो सभी क्लाइंट-साइड टेक्नोलॉजी (HTML, CSS, JavaScript / AngularJS, आदि ...) के लिए जा रहा है। यह वेब एप्लिकेशन डेटा तक पहुंचने और संशोधित करने के लिए REST API के साथ सहभागिता करने जा रहा है। अभी यह अनिर्धारित है कि REST API किस प्रकार की प्रमाणीकरण प्रणाली का उपयोग करने वाली है।

मेरी समझ से, किसी भी प्रकार के एपीआई प्रमाणीकरण प्रणाली (एपीआई कुंजी, OAuth 1/2, आदि ...) में कुछ डेटा होने चाहिए जो गुप्त रखने की आवश्यकता है अन्यथा पहुंच से समझौता किया जा सकता है। API कुंजियों के लिए, उन्हें कुंजी स्वयं गुप्त रखने की आवश्यकता है, OAuth 2 के लिए ग्राहक गुप्त / एक्सेस टोकन / ताज़ा टोकन को गुप्त रखने की आवश्यकता है, मुझे यकीन है कि OAuth 1 में शामिल 4 कुंजी में से कुछ को गुप्त रखने की आवश्यकता है (नहीं OAuth 1 के साथ बहुत अधिक अनुभव)। मैं यह सोचने की कोशिश कर रहा हूं कि क्या इस गुप्त सामान को सर्वर साइड पर एक मध्यम परत के बिना शुद्ध क्लाइंट-साइड वेब एप्लिकेशन में संग्रहीत करने का कोई तरीका है।

मैं इस बारे में सोचने की कोशिश कर रहा हूं और मैं ऐसा करने के लिए किसी जगह के बारे में नहीं सोच सकता। मेरा मतलब है कि मैं इसे जावास्क्रिप्ट में संग्रहीत नहीं कर सकता क्योंकि कोई भी स्रोत को देख सकता है या कंसोल को खोल सकता है और डेटा प्राप्त कर सकता है। मैं 100% सुनिश्चित नहीं हूं कि लोकलस्टोरेज कितना सुरक्षित है और अगर उपयोगकर्ता उस डेटा को एक्सेस / संशोधित कर सकते हैं। यहां तक ​​कि अगर स्थानीय भंडारण सुरक्षित था, तो मैं जिन दो तरीकों से डेटा प्राप्त करने के बारे में सोच सकता हूं, वे नहीं हैं। एक तरीका सिर्फ डेटा को जावास्क्रिप्ट सोर्स कोड में स्टोर करना है जो सबसे असुरक्षित चीज है जिसके बारे में मैं सोच सकता हूं। अब अगर मैं OAuth 2 जैसी किसी चीज़ का उपयोग कर रहा था, जिसमें बाकी आपी खुद मुझे टोकन देंगे, तब भी यह सुरक्षित नहीं होगा (पहले विकल्प से बेहतर) क्योंकि उन टोकन को सादे पाठ के रूप में लौटाया जाएगा जो कोई भी देख सकता है कंप्यूटर जो अनुरोध कर रहा है वह देख सकता है।

क्या कोई ऐसा तरीका है जिससे एप्लिकेशन पूरी तरह से क्लाइंट साइड पर चल रहा हो, सर्वर साइड पर किसी प्रकार की मध्य परत के बिना सुरक्षित रूप से डेटा के गुप्त टुकड़ों को स्टोर करने में सक्षम हो?



लोकलस्टोरेज ब्राउज़र-विशिष्ट है, लेकिन विंडोज पर ओपेरा को एक उदाहरण के रूप में लेते हुए, यह उपयोगकर्ता के प्रोफ़ाइल फ़ोल्डर में बस कुछ डिस्क फाइलें है, इसलिए यह अनिवार्य रूप से असुरक्षित है।
रॉस पैटरसन

एक तरीका यह होगा कि db में सर्वर पर सीक्रेट रखें और केवल क्लाइंट पर application_id रखें। फिर सर्वर से ओउथ क्वेरी करें, इसलिए यह किसी प्रकार का प्रॉक्सी दृष्टिकोण है।
साइमन पोलाक

जवाबों:


9

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

आप चीजों को छिपा सकते हैं, और सामान प्राप्त करना कठिन बना सकते हैं, लेकिन अंत में वे इसे बाहर निकाल सकते हैं, अगर वे पर्याप्त प्रयास करें।


4
^ यह। "गुप्त" गुप्त डेटा कैसे है, और कितना समय और पैसा वास्तव में इसकी रक्षा कर रहा है? "उद्योग मानक" प्रयास पर्याप्त हो सकते हैं।
डेव

+1 उत्कृष्ट उत्तर। एक जावास्क्रिप्ट डिबगर के साथ, मैं आपके एप्लिकेशन को बदल सकता हूं, मध्यवर्ती मान देख सकता हूं, आदि। अगर मुझे जानकारी चाहिए, तो मैं इसे प्राप्त करूंगा।
रॉस पैटरसन

2

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


0

एक विकल्प REST एपीआई के लिए पहुँच प्रदान करने या उपयोगकर्ता लॉगिन पर आधारित नहीं है; यह एक सत्र-आधारित टोकन (गाइड, हैशेड स्ट्रिंग, जो कुछ भी आप चाहते हैं) को लौटा सकता है जो कि एक्सेस को प्रमाणित करने के लिए अन्य REST API कॉल को पास किया जा सकता है।

यदि आप ग्राहक मशीन पर उपयोगकर्ता लॉगिन जानकारी संग्रहीत करने के बारे में चिंतित हैं, तो न करें, लेकिन उपयोगकर्ता को हर बार खाता और पासवर्ड जानकारी दर्ज करनी होगी

ऐसा नहीं है कि OAuth एट अल से परिचित है, लेकिन मैं ऊपर प्रमाणीकरण जानकारी को लगातार स्टोर करने के लिए कोई सम्मोहक कारण नहीं देखता हूं ...


कारणों के लिए, हमेशा "आराम" होता है जो स्पष्ट रूप से "सुरक्षा" और "सुरक्षा" का कट्टर-प्रसार है।
हेनन
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.