क्या सीजीआई स्क्रिप्ट में एक सादा-पाठ पासवर्ड एक सुरक्षा छेद है?

Question

मैंने पढ़ा है कि चीजें आपके वेब सर्वर के साथ गलत हो सकती हैं जो वेब स्क्रिप्ट में सादे पाठ फ़ाइलों के रूप में PHP स्क्रिप्ट का प्रदर्शन कर सकती है; नतीजतन मैंने अपनी अधिकांश PHP स्क्रिप्ट को वेब रूट के बाहर एक निर्देशिका में स्थानांतरित कर दिया है। अब मैं सोच रहा हूं कि मेरे सीजीआई-बिन में सीजीआई स्क्रिप्ट के साथ ऐसा ही हो सकता है।

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

Answer 1

मैंने पढ़ा है कि चीजें आपके वेब सर्वर के साथ गलत हो सकती हैं जो वेब स्क्रिप्ट में सादे पाठ फ़ाइलों के रूप में PHP स्क्रिप्ट का प्रदर्शन कर सकती है; नतीजतन मैंने अपनी अधिकांश PHP स्क्रिप्ट को वेब रूट के बाहर एक निर्देशिका में स्थानांतरित कर दिया है। अब मैं सोच रहा हूं कि मेरे सीजीआई-बिन में सीजीआई स्क्रिप्ट के साथ ऐसा ही हो सकता है।

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

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

हां। वास्तव में, बस सुनिश्चित करें कि निर्देशिका वेबूट के बाहर है।

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

मेरी स्क्रिप्ट पर्ल बीटीडब्ल्यू में लिखी गई हैं।

मैं इसके लिए Config::* मॉड्यूल में से किसी एक का उपयोग करना चाहता हूं।

Answer 2

यह निश्चित रूप से एक सुरक्षा चिंता है। आपको एक अलग फ़ाइल में एन्क्रिप्टेड पासवर्ड स्टोर करना चाहिए और यह सुनिश्चित करना चाहिए कि केवल आपके ऐप तक पहुंच हो।

Answer 3

यदि आप cgi-bin के रूप में कॉन्फ़िगर निर्देशिका का उपयोग करते हैं, तो अपाचे कॉन्फ़िगरेशन के साथ त्रुटि को छोड़कर फ़ाइल को दिखाने का कोई तरीका नहीं है। यदि आप cgi-bin निर्देशिकाओं के बाहर पर्ल प्रोग्राम का उपयोग करते हैं लेकिन साइट रूट के अंदर, ऐसा हो सकता है।

इसके अलावा, आप केवल स्थानीय सॉकेट से कनेक्शन स्वीकार करने के लिए डीबी को कॉन्फ़िगर कर सकते हैं, इसलिए डीबी पासवर्ड जानना बेकार होगा।

Answer 4

यदि आप इससे बच सकते हैं तो स्क्रिप्ट में पासवर्ड को हार्डकोड करना निश्चित रूप से एक अच्छा विचार नहीं है। सौभाग्य से दोनों पोस्टग्रेस और MySQL समर्थन फ़ाइल से डीबी प्रमाण पत्र लोडिंग। पोस्टग्रेज़ के लिए आप ~/.pgpass और MySQL के लिए मेरा मानना ​​है कि यह ~/.my है।cnf। किसी भी मामले में आप अनुमतियों को समायोजित करेंगे ताकि केवल स्क्रिप्ट चलाने वाले उपयोगकर्ता को फ़ाइल को पढ़ने की अनुमति हो। इस दृष्टिकोण का लाभ यह है कि फ़ाइल को पढ़ने के लिए आपको कोड लिखना नहीं है - डीबी क्लाइंट लाइब्रेरी स्वचालित रूप से करता है।

Answer 5

साझा करने की एक चिंता साझा होस्टिंग के लिए विशिष्ट है।

यदि आप अन्य उपयोगकर्ताओं के साथ साझा किए गए होस्ट पर हैं, तो उनसे पासवर्ड छिपाना असंभव हो सकता है। यह ओएस और वेबसर्वर के लिए कॉन्फ़िगरेशन विवरण पर निर्भर करता है।

उदाहरण के लिए, यह है जिस पर एक उपयोगकर्ता के लिए एक ही रास्ता एक वेबसाइट फ़ाइलों पठनीय या वेब सर्वर उपयोगकर्ता उन्हें पढ़ने योग्य बनाने के लिए है करने के लिए लिखने योग्य बनाने के लिए/सभी उपयोगकर्ताओं के लिए लिखने योग्य पेशकश लिनक्स पर एक अपाचे विन्यास के लिए आम बात है ।

आप इन सभी उपयोगकर्ताओं पर भरोसा नहीं कर सकते हैं कि वे खुद का दुरुपयोग न करें, लेकिन यदि इनमें से किसी एक वेबसाइट की भेद्यता है जो घुसपैठियों को पूर्ण फ़ाइल सिस्टम देखने की अनुमति देती है, तो घुसपैठ करने वाले अन्य सभी वेबसाइटों पर इसका फायदा उठा सकते हैं।

इसके खिलाफ प्रतिद्वंद्विता हैं, लेकिन वे उपयोगकर्ताओं के लिए चीजों को जटिल करते हैं, इसलिए कई होस्टर्स उन्हें लागू नहीं करते हैं।

Answer 6

आप पहले से ही सही उत्तर मिल गया है की तुलना में मैं प्रदान कर सकते हैं, लेकिन एक नोट के रूप:

यह बहुत बुरा रूप प्लेन, अवधि के रूप में पासवर्ड स्टोर करने के लिए है।

वैसे ही अनुमति के बिना फ़ाइलों को ओवरराइट या हटाने के लिए यह बहुत खराब रूप है। यदि आप ऐसा करते हैं, तो आपको या आपके क्लाइंट को बट में अंततः काट देगा।