अपने कोड में कभी भी हार्ड-कोड पासवर्ड न रखें। यह हाल ही में शीर्ष 25 सबसे खतरनाक प्रोग्रामिंग गलतियों में लाया गया था :
अपने सॉफ्टवेयर में एक गुप्त खाते और पासवर्ड को हार्ड-कोड करना बेहद सुविधाजनक है - कुशल रिवर्स इंजीनियरों के लिए। यदि आपके सभी सॉफ़्टवेयर में पासवर्ड समान है, तो अनिवार्य रूप से उस पासवर्ड के ज्ञात होने पर प्रत्येक ग्राहक असुरक्षित हो जाता है। और क्योंकि यह हार्ड-कोडेड है, इसे ठीक करने के लिए बहुत बड़ा दर्द है।
आपको पासवर्ड सहित कॉन्फ़िगरेशन जानकारी को एक अलग फ़ाइल में संग्रहीत करना चाहिए जिसे एप्लिकेशन शुरू होने पर पढ़ता है। यह कूटबन्धन के परिणामस्वरूप पासवर्ड को लीक होने से रोकने का एकमात्र वास्तविक तरीका है (इसे शुरू करने के लिए बाइनरी में कभी संकलित न करें)।
इस सामान्य गलती के बारे में अधिक जानकारी के लिए, आप CWE-259 लेख पढ़ सकते हैं । लेख में समस्या के बारे में अधिक गहन परिभाषा, उदाहरण और बहुत सारी अन्य जानकारी शामिल है।
जावा में, ऐसा करने का सबसे आसान तरीका प्राथमिकता वर्ग का उपयोग करना है। यह सभी प्रकार की प्रोग्राम सेटिंग्स को स्टोर करने के लिए डिज़ाइन किया गया है, जिनमें से कुछ में उपयोगकर्ता नाम और पासवर्ड शामिल हो सकते हैं।
import java.util.prefs.Preferences;
public class DemoApplication {
Preferences preferences =
Preferences.userNodeForPackage(DemoApplication.class);
public void setCredentials(String username, String password) {
preferences.put("db_username", username);
preferences.put("db_password", password);
}
public String getUsername() {
return preferences.get("db_username", null);
}
public String getPassword() {
return preferences.get("db_password", null);
}
}
उपरोक्त कोड में, आप कॉल कर सकते हैं setCredentials उपयोगकर्ता नाम और पासवर्ड के लिए एक डायलॉग संकेत दिखाने के बाद विधि हैं। जब आपको डेटाबेस से कनेक्ट करने की आवश्यकता होती है, तो आप बस getUsernameऔर का उपयोग कर सकते हैंgetPassword संग्रहीत मूल्यों को पुनः प्राप्त करने के लिए विधियों का हैं। लॉगिन क्रेडेंशियल आपके बायनेरिज़ में हार्ड-कोडेड नहीं होंगे, इसलिए अपघटन एक सुरक्षा जोखिम पैदा नहीं करेगा।
महत्वपूर्ण लेख: वरीयता फाइलें सिर्फ सादे पाठ XML फाइलें हैं। सुनिश्चित करें कि आप अनधिकृत उपयोगकर्ताओं को कच्ची फ़ाइलों (UNIX अनुमतियाँ, Windows अनुमतियाँ, वगैरह) को देखने से रोकने के लिए उचित कदम उठाएँ। लिनक्स में, कम से कम, यह कोई समस्या नहीं है, क्योंकि कॉल Preferences.userNodeForPackageकरने से वर्तमान उपयोगकर्ता के होम डायरेक्टरी में XML फ़ाइल बन जाएगी, जो अन्य उपयोगकर्ताओं द्वारा वैसे भी गैर-पठनीय है। विंडोज में, स्थिति अलग हो सकती है।
अधिक महत्वपूर्ण नोट्स: इस स्थिति के लिए सही वास्तुकला क्या है, इस जवाब और अन्य की टिप्पणियों में बहुत चर्चा हुई है। मूल प्रश्न वास्तव में उस संदर्भ का उल्लेख नहीं करता है जिसमें आवेदन का उपयोग किया जा रहा है, इसलिए मैं उन दो स्थितियों के बारे में बात करूंगा जिनके बारे में मैं सोच सकता हूं। पहला ऐसा मामला है जिसमें प्रोग्राम का उपयोग करने वाला व्यक्ति पहले से ही जानता है (और जानने के लिए अधिकृत है) डेटाबेस क्रेडेंशियल। दूसरा मामला है जिसमें आप, डेवलपर, प्रोग्राम का उपयोग करने वाले व्यक्ति से डेटाबेस क्रेडेंशियल्स को गुप्त रखने की कोशिश कर रहे हैं।
पहला मामला: उपयोगकर्ता डेटाबेस लॉगिन क्रेडेंशियल जानने के लिए अधिकृत है
इस मामले में, ऊपर वर्णित समाधान मैं काम करेगा। जावाPreference वर्ग सादा पाठ में उपयोगकर्ता नाम और पासवर्ड संग्रहीत करेगा, लेकिन वरीयता फ़ाइल केवल अधिकृत उपयोगकर्ता द्वारा पठनीय होगी। उपयोगकर्ता केवल एक्सएमएल फ़ाइल को प्राथमिकताएं खोल सकता है और लॉगिन क्रेडेंशियल पढ़ सकता है, लेकिन यह सुरक्षा जोखिम नहीं है क्योंकि उपयोगकर्ता को क्रेडेंशियल्स को शुरू करने के लिए पता था।
दूसरा मामला: उपयोगकर्ता से लॉगिन क्रेडेंशियल छिपाने की कोशिश कर रहा है
यह अधिक जटिल मामला है: उपयोगकर्ता को लॉगिन क्रेडेंशियल का पता नहीं होना चाहिए लेकिन फिर भी डेटाबेस तक पहुंच की आवश्यकता है। इस मामले में, एप्लिकेशन चलाने वाले उपयोगकर्ता के पास डेटाबेस तक सीधी पहुंच होती है, जिसका अर्थ है कि कार्यक्रम को समय से पहले लॉगिन क्रेडेंशियल्स को जानना होगा। ऊपर वर्णित समाधान इस मामले के लिए उपयुक्त नहीं है। आप डेटाबेस लॉगिन क्रेडेंशियल्स को प्राथमिकता फ़ाइल में संग्रहीत कर सकते हैं, लेकिन वह उपयोगकर्ता उस फ़ाइल को पढ़ सकेगा, क्योंकि वे मालिक होंगे। वास्तव में, इस मामले को सुरक्षित तरीके से उपयोग करने का कोई अच्छा तरीका नहीं है।
सही मामला: एक बहु स्तरीय वास्तुकला का उपयोग करना
इसका सही तरीका यह है कि आपके डेटाबेस सर्वर और आपके क्लाइंट एप्लिकेशन के बीच में एक मध्य परत हो, जो व्यक्तिगत उपयोगकर्ताओं को प्रमाणित करता है और सीमित सेट के संचालन की अनुमति देता है। प्रत्येक उपयोगकर्ता के पास स्वयं के लॉगिन क्रेडेंशियल होंगे, लेकिन डेटाबेस सर्वर के लिए नहीं। क्रेडेंशियल्स मध्य परत (व्यावसायिक तर्क स्तरीय) तक पहुंच की अनुमति देगा और प्रत्येक उपयोगकर्ता के लिए अलग होगा।
प्रत्येक उपयोगकर्ता के पास अपना उपयोगकर्ता नाम और पासवर्ड होगा, जिसे किसी भी सुरक्षा जोखिम के बिना प्राथमिकता वाली फ़ाइल में स्थानीय रूप से संग्रहीत किया जा सकता है। इसे थ्री-टियर आर्किटेक्चर (टियर्स आपके डेटाबेस सर्वर, बिजनेस लॉजिक सर्वर और क्लाइंट एप्लिकेशन) कहा जाता है। यह अधिक जटिल है, लेकिन यह वास्तव में इस तरह का काम करने का सबसे सुरक्षित तरीका है।
संचालन का मूल क्रम है:
- ग्राहक उपयोगकर्ता के व्यक्तिगत उपयोगकर्ता नाम / पासवर्ड का उपयोग करके व्यापार तर्क स्तर के साथ प्रमाणित करता है। उपयोगकर्ता नाम और पासवर्ड उपयोगकर्ता के लिए जाने जाते हैं और किसी भी तरह से डेटाबेस लॉगिन क्रेडेंशियल से संबंधित नहीं हैं।
- यदि प्रमाणीकरण सफल होता है, तो क्लाइंट डेटाबेस से कुछ जानकारी मांगने के लिए बिजनेस लॉजिक टियर से अनुरोध करता है। उदाहरण के लिए, उत्पादों की एक सूची। ध्यान दें कि ग्राहक का अनुरोध SQL क्वेरी नहीं है; यह एक दूरस्थ प्रक्रिया कॉल है जैसे
getInventoryList।
- व्यावसायिक लॉजिक टियर डेटाबेस से जुड़ता है और मांगी गई जानकारी को पुनः प्राप्त करता है। उपयोगकर्ता के अनुरोध के आधार पर एक सुरक्षित एसक्यूएल क्वेरी बनाने के लिए व्यावसायिक तर्क स्तरीय है। SQL इंजेक्शन हमलों को रोकने के लिए SQL क्वेरी के किसी भी पैरामीटर को पवित्रा होना चाहिए।
- व्यापार तर्क स्तरीय सूची सूची को क्लाइंट अनुप्रयोग को वापस भेज देता है।
- क्लाइंट उपयोगकर्ता को इन्वेंट्री सूची प्रदर्शित करता है।
ध्यान दें कि पूरी प्रक्रिया में, क्लाइंट एप्लिकेशन कभी भी डेटाबेस से सीधे नहीं जुड़ता है । व्यापार तर्क स्तर एक प्रमाणित उपयोगकर्ता से एक अनुरोध प्राप्त करता है, एक सूची सूची के लिए ग्राहक के अनुरोध को संसाधित करता है, और उसके बाद ही एक SQL क्वेरी निष्पादित करता है।