15

तो मैं SQL प्रमाणीकरण का उपयोग कर अपने web.config में कनेक्शन स्ट्रिंग का उपयोग कर रहा हूं।क्या web.config में कनेक्शन स्ट्रिंग को सुरक्षित करने की आवश्यकता है?

बेशक लोग कहते हैं कि यह एक भेद्यता हो सकती है क्योंकि आप सादे टेक्स्ट में पासवर्ड संग्रहीत कर रहे हैं।

हालांकि, मुझे पता है कि, आईआईएस कभी भी web.config परोसता नहीं है, और web.config को केवल प्रशासकों और आईआईएस तक पहुंच पढ़ने चाहिए। तो यदि हैकर ने वेबसर्वर तक पहुंच प्राप्त की है, तो इससे कोई फर्क नहीं पड़ता कि मैं किस एन्क्रिप्शन का उपयोग करता हूं क्योंकि निजी कुंजी वेबसर्वर पर होगी।

कनेक्शन स्ट्रिंग को एन्क्रिप्ट करने से एन्फ्यूस्केशन के माध्यम से सुरक्षा के रूप में वर्गीकृत नहीं किया जाएगा?

क्या यह web.config कनेक्शन स्ट्रिंग को एन्क्रिप्ट करने और वेबसर्वर पर निजी कुंजी संग्रहीत करने योग्य है?

बेशक, अगर मैं एसएसएल का उपयोग नहीं करता हूं, तो मैं सादे टेक्स्ट में HTTP पर कनेक्शन स्ट्रिंग ट्रांसमिट कर रहा हूं। अगर मैं एसएसएल का उपयोग करता हूं तो इस समस्या को भी कम किया जाना चाहिए।

उत्तर

20

मैं यह नहीं कहूंगा कि Web.config में एक सादे टेक्स्ट पासवर्ड संग्रहीत करना एक सुरक्षा भेद्यता है, स्वयं में और स्वयं। लेकिन पासवर्ड को एनक्रिप्ट अस्पष्टता के माध्यम से एक उपयोगी रक्षा में गहराई उपाय ही नहीं, सुरक्षा है:

  1. क्या होगा यदि आईआईएस Web.config सेवा करने के लिए गलत ढंग से कॉन्फ़िगर है?
  2. क्या होगा यदि एएसपी.नेट (padding oracle vulnerability) में सुरक्षा भेद्यता की खोज की गई है जो किसी को Web.config डाउनलोड करने की अनुमति देता है?
  3. वेब सर्वर तक पहुंच की विभिन्न डिग्री हैं, पूर्ण प्रशासनिक विशेषाधिकारों से सर्वर-साइड कोड इंजेक्शन तक। यदि कोई हमलावर केवल बाद वाले को प्रबंधित कर सकता है, तो वह Web.config को पढ़ने में सक्षम हो सकता है लेकिन शायद मशीन कुंजी तक पहुंचने में सक्षम नहीं हो सकता है, खासकर यदि आपका एप्लिकेशन आंशिक विश्वास के तहत चल रहा है।

अंत में, यह तय करने के लिए आप पर निर्भर है कि Web.config में सादे टेक्स्ट पासवर्ड संग्रहीत करने का जोखिम स्वीकार्य है या नहीं। बेशक, यदि विंडोज प्रमाणीकरण एक विकल्प है, तो आप SQL प्रमाणीकरण के बजाय इसका उपयोग करने पर विचार करना चाहेंगे।

अद्यतन: जब सुरक्षा के बारे में बात, यह एक अच्छा विचार संपत्ति और खतरों पहचान करने के लिए है। इस मामले में, संपत्ति डेटाबेस में संवेदनशील डेटा है (यदि डेटा महत्वहीन है, तो पासवर्ड को सुरक्षित रखने के लिए परेशान क्यों करें?), और खतरे किसी हमलावर की संभावना है कि किसी भी तरह Web.config तक पहुंच प्राप्त हो और इस प्रकार डेटाबेस भी। एक संभावित शमन Web.config में डेटाबेस पासवर्ड एन्क्रिप्ट करना है।

कितना जोखिम है? क्या हमें वास्तव में ऐसी खगोलीय दुर्लभ घटना के लिए योजना बनाना है?

यह शमन पहले से ही इसके लायक साबित हो चुका है: जब एएसपी.नेट पैडिंग ऑरैक भेद्यता की खोज की गई थी। Web.config में सादे टेक्स्ट पासवर्ड संग्रहीत करने वाले किसी भी व्यक्ति को जोखिम था; जो भी पासवर्ड एन्क्रिप्ट किया गया था वह नहीं था। आप कितने निश्चित हैं कि अगले कुछ सालों में एएसपी.नेट में एक और समान भेद्यता की खोज नहीं की जाएगी?

क्या हमें स्रोत कोड एन्क्रिप्ट करना होगा और रन-टाइम पर डिक्रिप्ट करना चाहिए? मेरे लिए अत्यधिक लगता है।

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

मुझे लगता है कि उनके पास पहले से ही आपके बॉक्स तक पहुंच सीमित है, तो आपका होस्ट विफल हो गया है या आपने पहले से ही कमजोर सेवाओं को स्थापित किया है।

एएसपी.नेट या आपके कोड में सुरक्षा भेद्यता के बारे में क्या? वे समय-समय पर पॉप अप करते हैं।

मेरी चिंता मानक प्रथाओं है। क्या यह एक मानक है?

माइक्रोसॉफ्ट has recommended कनेक्शन स्ट्रिंग एन्क्रिप्ट करना।

  • कैसे संभव है कि एक हमलावर की खोज और एक सुरक्षा भेद्यता कि Web.config को उजागर करता है का फायदा उठाने में सक्षम हो जाएगा यह है:

    आपको क्या करना चाहिए जोखिम का मूल्यांकन कि एक प्लेन टेक्स्ट पासवर्ड भंडारण बन गया है? पिछले इतिहास के आधार पर, मैं कहूंगा कि संभावना कम है (लेकिन "खगोलीय रूप से" कम नहीं)।

  • आपका डेटा कितना मूल्यवान या संवेदनशील है? यदि आप जो भी स्टोर कर रहे हैं वह आपकी बिल्ली की तस्वीरें है, तो शायद इससे कोई फर्क नहीं पड़ता कि हमलावर को आपका डेटाबेस पासवर्ड मिल जाता है या नहीं। लेकिन अगर आप personally identifiable information संग्रहीत कर रहे हैं, तो कानूनी दृष्टिकोण से, मैं कहूंगा कि आपको अपने कनेक्शन को एन्क्रिप्ट करने सहित अपने एप्लिकेशन को सुरक्षित करने के लिए सभी संभव उपाय करना चाहिए।
+0

1. यह डिफ़ॉल्ट विकल्प है, और आपको इसे मैन्युअल रूप से सेट करना होगा। 2। फिर उनके पास पहले से ही आपके स्रोत कोड तक पहुंच है। क्या हमें स्रोत कोड एन्क्रिप्ट करना होगा और रन-टाइम पर डिक्रिप्ट करना चाहिए? मेरे लिए अत्यधिक लगता है। 3. मुझे लगता है कि अगर आपके पास पहले से ही आपके बॉक्स तक पहुंच सीमित है, तो आपका होस्ट विफल हो गया है या आपने पहले से ही कमजोर सेवाओं को स्थापित किया है। ---- मेरे लिए web.config एन्क्रिप्ट करना obfuscation के माध्यम से सुरक्षा है। यह मेरे जैसा होगा, मेरे जावास्क्रिप्ट स्रोत कोड को सुरक्षित करने के लिए मेरे जावास्क्रिप्ट को एन्क्रिप्ट करना (भले ही वेब ब्राउजर इसे पढ़ सके)। मेरी चिंता मानक प्रथाओं है। क्या यह एक मानक है ???? – Dexter

+0

आगे, यह कितना जोखिम है? क्या यह आम है कि लोग वेब पर एएसपीनेट वेबसाइटों पर web.configs तक पहुंच रहे हैं? मेरा मतलब है, आईआईएस एक अपरिवर्तनीय त्रुटि का सामना कर सकता है और गलती से web.config प्रदर्शित कर सकता है क्योंकि यह web.config को पढ़ने की कोशिश कर रहा है और कुछ समय के लिए कुछ वेबसाइट प्रदर्शित करता है। क्या हमें वास्तव में ऐसी खगोलीय दुर्लभ घटना के लिए योजना बनाना है? अधिकांश PHP वेबसाइट अपने डेटाबेस पासवर्ड की सुरक्षा के लिए कुछ प्रकार की settings.php या config.php का भी उपयोग करती है, और केवल इसकी पढ़ने की अनुमतियों को बदलती है। वे या तो एन्क्रिप्ट नहीं करते हैं (यहां तक ​​कि उत्पादन सर्वर में भी)। – Dexter

+0

मैंने अपने अपडेट किए गए उत्तर में अपने प्रश्नों को संबोधित करने का प्रयास किया है। –

3

मुझे लगता है कि यह "बाहरी" सुरक्षा से नहीं है, बल्कि "अंदर" के लिए है।

कभी-कभी, SQL व्यवस्थापक/उपयोगकर्ता और ओएस व्यवस्थापक अलग-अलग लोग होते हैं। लेकिन ओएस व्यवस्थापक के पास सभी फाइलों तक पहुंच है, इसलिए वह web.config फ़ाइल में आसानी से एसक्यूएल क्रेडेंशियल पढ़ सकता है। लेकिन उन प्रमाण-पत्रों को एक तरह से एन्क्रिप्ट किया जा सकता है, यहां तक ​​कि ओएस व्यवस्थापक को डिक्रिप्ट करने का कोई तरीका नहीं है।

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

+2

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

+0

मुझे नहीं लगता कि प्रमाण पत्र पढ़ना संभव है। मुझे सटीक प्रक्रिया याद नहीं है, लेकिन मेरा मानना ​​है कि ओएस व्यवस्थापक एन्क्रिप्शन को पढ़ने के लिए असंभव है। – Euphoric

+0

'aspnet_regiis -pd section' –

3

ध्यान दें कि, यदि उत्पादन पासवर्ड web.config फ़ाइल में मौजूद हैं, तो उस फ़ाइल तक पहुंच वाले किसी भी डेवलपर को उत्पादन डेटाबेस तक पहुंच है। यह विशेष रूप से एक समस्या है जब कनेक्शन स्ट्रिंग में उपयोगकर्ता नाम डेटाबेस को पढ़ने/लिखने के लिए उपयोग किया जाता है। डेवलपर्स के लिए यह तब भी संभव हो सकता है जब चीजें "फिक्स" कभी भी नहीं हुईं।

+0

हाँ, मैं सहमत हूं। मुझे लगता है कि यह डेवलपर्स से सुरक्षा होगी, एफ़टीपी एक्सेस वाले उपयोगकर्ता, जिन्हें उत्पादन डेटाबेस तक पहुंच/बदलने की अनुमति नहीं दी जा सकती है (और वेब-सर्वर व्यवस्थापक पहुंच नहीं है)। यह मेरी एक विशेष चिंता नहीं है क्योंकि डेवलपर्स कम हैं और vetted। लेकिन निश्चित रूप से आंतरिक रूप से सही चर्चा करने के लिए कुछ? – Dexter

+0

यह इस बात पर भी निर्भर करता है कि आपका उद्योग कितना और कैसे नियंत्रित होता है। कुछ उद्योग यह दिखाने में सक्षम होना चाहिए कि उनका उत्पादन डेटा सुरक्षित है। –

+0

मैंने उन लोगों से मुलाकात की है जिन्होंने तर्क दिया है कि web.config कमजोर है और "सिस्टम में किसी अन्य ऐप के माध्यम से पहुंच प्राप्त करने" तक पहुंच योग्य है। और यह मेरे दिमाग को उड़ा दिया क्योंकि, अगर उनके पास आपके वेबसर्वर तक पहुंच है, तो उनके पास पहले से ही आपका सभी स्रोत कोड भी है --- क्या हम इसे भी एन्क्रिप्ट करते हैं ??? तो मुझे विश्वास है कि यह उन डेवलपर्स से कुछ प्रकार की सुरक्षा है जिनके पास पहले से ही स्रोत कोड पहुंच है, लेकिन डेटाबेस एक्सेस करने की अनुमति नहीं है। मुझे लगता है कि डेवलपर मुद्दे की तुलना में यह एक मेजबान मुद्दा है। – Dexter

1

मैं IHackStuff ऑनलाइन ब्लॉग पर कुछ लेख पढ़ता था। सभी जानकारी

filetype:config web.config -CVS 

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

+0

-1: क्षमा करें, मैं आपको विश्वास नहीं करता हूं। आईआईएस के माध्यम से एक .config फ़ाइल की सेवा करने का प्रयास करें और आप देखेंगे। अगर आपको लगता है कि यह सच है, तो सबूत के साथ एक लिंक पोस्ट करें। –

+0

https://svn.koolkraft.net/nblogr/tags/34/NBlogr.Web/Web.config – CoderRoller

+0

ftp://202.120.107.88/incoming/WebSite1/Web.config – CoderRoller

0

आपको यह कहना सही है कि web.config ब्राउज़र पर ASP.NET द्वारा सेवा नहीं की जाएगी। लेकिन डेवलपर्स सतर्क हैं, इसलिए जब वे एक नया संस्करण जारी करते हैं, तो कभी-कभी वे web.config.old या web.config.bak जैसे किसी ज्ञात अच्छे web.config की प्रतिलिपि बनाते हैं। और क्योंकि डेवलपर्स आलसी हैं, रिलीज के बाद वे पुराने वेब.कॉन्फिग को हटाना भूल जाते हैं, या रिलीज को रोलबैक करने की आवश्यकता होने पर कुछ दिनों तक इसे लटकते रहें।

अब, .old और .bak फ़ाइलों एक ब्राउज़र है, जो इसे एक स्क्रिप्ट या एक उपकरण है जो इन फ़ाइलों और एक हमलावर के लिए उन्हें डाउनलोड जो तब पर उन के माध्यम से जा सकते हैं के लिए स्कैन लिखने के लिए आसान है का मतलब है को पेश की जानी होगा उपयोगकर्ता नाम और पासवर्ड के साथ कनेक्शन स्ट्रिंग देखने के लिए उनके अवकाश, और अचानक से क्रेडिट कार्ड नंबर आपके डेटाबेस इंटरनेट प्रसारित कर रहे हैं ...

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

+0

कॉन्फ़िगरेशन फ़ाइल अनुभागों को एन्क्रिप्ट करने के लिए मानक .NET क्षमता के अलावा आपको कुछ भी क्यों चाहिए और उन्हें स्वचालित रूप से उपयोग पर डिक्रिप्ट करने की आवश्यकता क्यों है? –