सुरक्षित डेटाबेस कनेक्शन आमतौर पर JAR फ़ाइलों में लागू कैसे होते हैं?

Question

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

वैसे भी, मुझे पूरा यकीन है कि यह डेवलपर सुरक्षा भेद्यता को नहीं जानता अगर वह उसे पीछे की तरफ रखता है। और मुझे जावा/जेएआर फाइलों के बारे में पर्याप्त जानकारी नहीं है कि उसे पर क्या करना चाहिए, केवल उसे बताएं कि वह नहीं करनी चाहिए।

तो रिमोट MySQL डेटाबेस से कनेक्ट एक वितरित JAR फ़ाइल लिखते समय सामान्य सुरक्षा विचार क्या हैं? क्या कनेक्शन विवरण (उपयोगकर्ता नाम और/या पासवर्ड) एन्क्रिप्ट करने का कोई मानक तरीका है? आईआईआरसी, नहीं हैं .jar फाइलें सिर्फ ज़िप अभिलेखागार की महिमा करती हैं, और कोई भी फ़ाइल को अनपैक करने और स्रोत कोड में कनेक्शन विवरण देखने के लिए नहीं कर सकता? जार फ़ाइल सामग्री एन्क्रिप्ट करने का कोई तरीका है?

---

अद्यतन: मुझे डेवलपर से निम्नलिखित स्पष्टीकरण प्राप्त हुआ। क्या यह सही लगता है?

जार फ़ाइल में सभी कक्षाएं एन्क्रिप्टेड हैं। मैंने हमेशा जार फ़ाइल में संग्रहीत करने से पहले सभी क्लास फ़ाइलों को एन्क्रिप्ट किया है। यदि आप कोई भी [redacted] जार खोलते हैं, तो आपको केवल एन्क्रिप्टेड कोड दिखाई देगा। इसलिए क्लास को डिकंपलिंग करके उपयोगकर्ता को स्रोत कोड देखने में सक्षम होने का कोई मौका नहीं है। कक्षाएं डीबी से कनेक्ट करने के लिए जेडीबीसी का उपयोग करती हैं, खोज ईंगिन को एसबीएल चलाने के लिए डीबी से कनेक्ट करने की आवश्यकता होती है। ये sqls जार फ़ाइल में teh एन्क्रिप्टेड clasees में हैं।

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

Answer 1

हाँ, जार सिर्फ फ़ाइलें ज़िप कर रहे हैं, तो यह WinZip का प्रयोग करके एक खोलने के लिए और सामग्री को देखने के लिए पूरी तरह से संभव है। यदि आप जानते हैं कि आप क्या कर रहे हैं, तो आप अंदर एक सादा पाठ पासवर्ड पा सकते हैं।

ऐसा लगता है कि आपके जेएआर में एक क्लाइंट है जो सीधे डेटाबेस से जुड़ता है। आप यह नहीं कहते कि यह इंटरनेट या वीपीएन या लैन पर किया जाता है या नहीं। क्या डेटाबेस क्लाइंट से दूरस्थ रूप से तैनात किया गया है?

यह एक कारण है कि क्लाइंट/सर्वर ऐप्स चले गए: इंटरनेट पर उन्हें सुरक्षित करना मुश्किल है।

आपका ऐप क्लासिक क्लाइंट-सर्वर की तरह लगता है। क्या मेरे पास वह अधिकार है?

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

यह आपको एसक्यूएल इंजेक्शन हमलों के खिलाफ एक लड़ने का मौका भी दे सकता है।

यदि आप जेएआर सामग्री को एन्क्रिप्ट करते हैं तो आपको लोड होने पर उन्हें डिक्रिप्ट करने के लिए कस्टम क्लास लोडर लिखना होगा। कमजोर दिल के लिए नहीं।

यदि आपका ग्राहक एक स्विंग ऐप है, तो प्रत्येक घटक के लिए पंजीकृत श्रोताओं और ईवेंट हैंडलरों में निर्मित सभी तर्क और डेटाबेस सामग्री के साथ, आपके हाथों पर एक गंभीर पुनर्लेखन होगा। आप एक सेवा उन्मुख वास्तुकला के लिए आगे बढ़ेंगे, जहां सभी काम सर्वर की तरफ से सेवाओं द्वारा किया जाता है। क्लाइंट केवल क्लासिक एमवीसी में जो करता है वह करता है: सर्वर पक्ष के साथ ईवेंट पास करें और परिणाम प्रदर्शित करें। आपका ग्राहक बहुत हल्का होगा।

यह आपकी विकास टीम और व्यवसाय के लिए सबसे बड़ा झटका होगा।

Answer 2

इसे सादे पाठ में रखने के लिए (मुझे लगता है) गंभीर कमजोर है। वास्तव में, कोई जार निकालने और उस सादा पाठ में जो लिखा है उसे पढ़ सकता है।

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

Answer 3

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

Answer 4

मैं अक्सर कुछ जवाब देकर अपना उत्तर शुरू करूंगा: "कोई भी व्यक्ति एक सुरक्षा योजना बना सकता है जिसे वह तोड़ नहीं सकता"।

अब, अद्यतन को ध्यान में रखते हुए जहां एन्क्रिप्शन और ओबफ्यूसेशन का उल्लेख उसी अद्यतन में किया गया है, यह ध्यान रखना बुद्धिमान होगा कि एन्क्रिप्शन obfuscation के समान नहीं है। तकनीकी रूप से, एन्क्रिप्शन में कुछ सादे टेक्स्ट को सिफरटेक्स्ट में बदलने के लिए एक कुंजी का उपयोग शामिल होता है, जिसमें सादे टेक्स्ट केवल मूल कुंजी के ज्ञान के साथ पुनर्प्राप्त करने योग्य होता है। Obfuscation परिभाषा द्वारा एन्क्रिप्शन के करीब कहीं भी नहीं है - इसमें निष्पादन योग्य स्रोत कोड से जानकारी को हटाने में शामिल है, जो निष्पादन योग्य रूप से "कठिन" रिवर्स-इंजीनियर के लिए प्रस्तुत करता है। आम तौर पर, obfuscation में छोटे से प्रतीकों का प्रतिस्थापन शामिल होता है, और कभी-कभी, स्रोत कोड की पुनरावृत्ति होती है जो मूल के निष्पादन प्रोफ़ाइल को बनाए रखने के दौरान रिवर्स-इंजीनियर स्रोत कोड को पढ़ने में मुश्किल होती है (obfuscated स्रोत कोड में एक ही कोड और डेटा प्रवाह पथ होते हैं मूल के रूप में)।

यहां महत्व के बारे में, यह तथ्य है कि पासवर्ड को स्रोत कोड में कोड किया गया है। यह मानना ​​उचित है कि obfuscated स्रोत कोड में हार्ड कोडित पासवर्ड भी शामिल होगा। यह धारणा उचित है क्योंकि अधिकांश obfuscators ने कभी भी constant pool within a class file को म्यूटेट करने का प्रयास नहीं किया है - निरंतर पूल को म्यूट करना खतरनाक है जिसके परिणामस्वरूप रनटाइम व्यवहार में परिवर्तन हो सकता है। यदि पासवर्ड को स्ट्रिंग के रूप में स्रोत कोड में हार्ड-कोड किया गया है, तो कक्षा फ़ाइल (obfuscated या नहीं) में String constant pool में पासवर्ड होगा, जिसे JVM द्वारा स्मृति में लोड किया जाएगा (बिना डिक्रिप्शन या डिकोडिंग प्रक्रिया के के बीच)।

इस मामले में सबसे अच्छा अभ्यास अंत उपयोगकर्ता को डेटाबेस उपयोगकर्ता आईडी और पासवर्ड निर्दिष्ट करने के लिए प्राप्त करना है (यदि वे एप्लिकेशन सेटअप का प्रबंधन कर रहे हैं), इन उपयोगकर्ता को क्रेडेंशियल्स सुरक्षित रूप से सुरक्षित करने के लिए (यह प्रकृति पर निर्भर करता है एप्लिकेशन; जावा ईई अनुप्रयोगों को कंटेनर इन क्रेडेंशियल्स को प्रबंधित करने का प्रयास करना चाहिए), और इन क्रेडेंशियल्स को सुरक्षित स्टोर से पुनर्प्राप्त होने पर सुरक्षित रूप से प्रबंधित करें। आप अधिक पॉइंटर्स के लिए Insecure Storage पर OWASP आलेख को देखना चाहेंगे।

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