2011-11-22 13 views
10

मैं वर्तमान में एक एएसपी.नेट एमवीसी वेबसाइट पर काम कर रहा हूं, और मैं उस बिंदु पर आया हूं जहां मुझे वेबसाइट में डेटाबेस को एकीकृत करने की आवश्यकता है।मैं कनेक्शन स्ट्रिंग विवरण को सुरक्षित रूप से कैसे स्टोर और एक्सेस कर सकता हूं?

आम तौर पर मैं बस Web.config फाइल करने के लिए उचित कनेक्शन स्ट्रिंग जोड़ना होगा:

<add name="MainDB" 
    connectionString="Server=localhost; Database=TopSecretData; User Id=Joe; 
    password=password" providerName="System.Data.SqlClient" /> 

लेकिन वहाँ स्पष्ट रूप से एक स्पष्ट सुरक्षा दोष अगर मैं Web.config में सही मेरे उपयोगकर्ता आईडी और पासवर्ड छोड़ देते हैं, खासकर जब यह स्रोत के अंतर्गत है नियंत्रण।

संक्षेप में: मैं सार्वजनिक रूप से दिखाई देने के बिना अपने कनेक्शन स्ट्रिंग विवरण कैसे संग्रहीत कर सकता हूं?

उत्तर

15

सर्वोत्तम अभ्यास अपने कनेक्शन स्ट्रिंग अनुभाग को एन्क्रिप्ट करना है। aspnet_regiis.exe उपयोग, विभिन्न स्थानों में पाया जा सकता है:

  • प्रारंभ - दृश्य स्टूडियो - दृश्य स्टूडियो उपकरण - दृश्य स्टूडियो कमान देने के लिए प्रेरित
  • C: \ Windows \ Microsoft.NET \ फ्रेमवर्क \ v4.0.30319 (सुनिश्चित करते हुए आप एक व्यवस्थापक के रूप में चलाने)

से पहले: इस आदेश

<configuration> 
<connectionStrings> 
<add name="MainConnectionString" 
connectionString="data source=Ratbert;database=Sales;username=ASPNET;password=$Double_Rainbow2011" 
providerName="System.Data.SqlClient"/> 
</connectionStrings> 
</configuration> 

रन:

aspnet_regiis –pef connectionStrings c:\PathToWebSite 

या, यदि उपरोक्त आदेश काम नहीं करता है (और आप aspnet_regiis सहायता पाठ मिलता है), कोशिश

aspnet_regiis -pe connectionStrings -app "/" -site 6 

जहां "6" साइट के आईडी के रूप में IIS में सूचना दी है।

के बाद:

<connectionStrings configProtectionProvider="RsaProtectedConfigurationProvider"> 
    <EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element" 
    xmlns="http://www.w3.org/2001/04/xmlenc#"> 
    <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc" /> 
    <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#"> 
    <EncryptedKey xmlns="http://www.w3.org/2001/04/xmlenc#"> 
    <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" /> 
    <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#"> 
     <KeyName>Rsa Key</KeyName> 
    </KeyInfo> 
    <CipherData> 
     <CipherValue>Bf677iFrUFW ... +4n4ZZKXCTUAu2Y=</CipherValue> 
    </CipherData> 
    </EncryptedKey> 
    </KeyInfo> 
    <CipherData> 
    <CipherValue>UDEZ ...QfXUmM5rQ==</CipherValue> 
    </CipherData> 
    </EncryptedData> 
</connectionStrings> 

अब जब कि यह विकृत है, तो आप उसे संपादित नहीं कर सकते हैं। डिक्रिप्ट इस तरह:

aspnet_regiis –pdf connectionStrings c:\PathToWebSite 

या

aspnet_regiis -pd connectionStrings -app "/" -site 6 

और फिर बदल सकते हैं और फिर से एन्क्रिप्ट।

कनेक्शन स्ट्रिंग को पढ़ने के लिए, कॉन्फ़िगरेशन प्रबंधक स्टेटिक क्लास का उपयोग करें।

string connStr = 
ConfigurationManager 
.Connectionstrings["MainConnectionString"] 
.ConnectionString.ToString(); 

var myConnection = new SqlConnection(connStr); 

myConnection.Open(); 
+0

बिल्कुल सही! यह ठीक वही है जिसकी मुझे तलाश थी। –

1

आम दृष्टिकोण में encrypting the web.config और storing the connection strings in the registry शामिल हैं।

दूसरा लिंक एक बड़े बड़े लेख का हिस्सा है जिसमें एएसपी.NET एप्लिकेशन को सही ढंग से सुरक्षित करने के तरीके को शामिल किया गया है। यह वेबफॉर्म के लिए लिखा गया था, लेकिन सिद्धांत समान हैं। यह एक अच्छा पठन है और इसमें से अधिकतर आज भी लागू होता है, भले ही यह थोड़ा पुराना हो।

3

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

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

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

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

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

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

1

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