"अविश्वसनीय आरंभीकरण" दोष - एसक्यूएल कनेक्शन

Question

मैं निम्नलिखित किया है ... बनाने के दौरान

private static IDbConnectionProvider CreateSqlConnectionProvider(DbConfig dbConfig) 
{ 
    return new QcDbConnectionProvider(() => 
     { 
      SqlConnectionStringBuilder csBuilder = new SqlConnectionStringBuilder(); 

      if (!string.IsNullOrEmpty(dbConfig.DataSource)) 
       csBuilder.DataSource = dbConfig.DataSource; 

      if (!string.IsNullOrEmpty(dbConfig.Database)) 
       csBuilder.InitialCatalog = dbConfig.Database; 

      . 
      . 
      . 
      . 

      return new SqlConnection(csBuilder.ConnectionString); 
     }); 
} 

ग्राहक कोड विश्लेषण करने के लिए Veracode उपकरण का उपयोग कर रहा है और Veracode एक दोष "अविश्वसनीय आरंभीकरण" पर पता लगाया है

return new SqlConnection(csBuilder.ConnectionString); 

इसके अलावा

, जिन्हें आप नीचे dbConfig प्रारंभ किया जा रहा है ...

DbConfig configDbConfig = new DbConfig 
{ 
    Database = codeFile.ConfigurationDb, 
    DataSource = codeFile.DataSource, 
    IntegratedSecurity = sqlCredentials.UseWindowsAuthentication ? 1 : 0, 
    UserId = sqlCredentials.UseWindowsAuthentication ? null : sqlCredentials.SqlUserName, 
    ClearTextPassword = sqlCredentials.UseWindowsAuthentication ? null : sqlCredentials.SqlUserPassword 
}; 

इस दोष को ठीक करने के लिए मुझे और क्या करने की ज़रूरत है? this link के अनुसार, मैं SqlConnectionStringBuilder का उपयोग कर कनेक्शन स्ट्रिंग बना रहा हूं जो कनेक्शन स्ट्रिंग बनाने से सुरक्षित है।

अग्रिम धन्यवाद ... अविश्वसनीय प्रारंभ जारी करने के लिए

Answer 1

विवरण है:

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

अपने मामले में आप फ़ाइल से dbConfig के लिए डेटा पढ़ रहे हैं:

if (TryReadCodeFile(configurationProfileFile...)) { 
    DbConfig configDbConfig = new DbConfig... 
} 

ध्यान दें कि आप भी एक लाइन नंबर के साथ आना चाहिए पाने चेतावनी (गलत कोड प्रतिबंध लगाना करने के लिए)। आपके द्वारा पोस्ट किए गए कोड में लगभग हर चीज इस समस्या को उत्पन्न कर सकती है (मुझे नहीं लगता कि sqlCredentials कहां से आता है लेकिन यह स्पष्ट समस्या में होने पर सुरक्षा समस्याओं का एक और स्रोत भी हो सकता है - या आपके आवेदन में डिक्रिप्ट करने के लिए कोड पहुंच योग्य है)।

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

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

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

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

ध्यान रखें कि आपका आवेदन आपके पूरे सिस्टम में कम सुरक्षित आइटम के रूप में सुरक्षित होगा। ध्यान दें कि एप्लिकेशन को सुरक्षित (मुझे पता है, यह शब्द बहुत अस्पष्ट है) पासवर्ड एन्क्रिप्ट करने के लिए पर्याप्त नहीं है।

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

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

1) सिस्टम जहां फ़ाइलों का समर्थन करता है, आपके आवेदन के मुकाबले किसी और के द्वारा सुलभ नहीं है। आपकी एप्लिकेशन सुरक्षा सिस्टम सुरक्षा से अधिक नहीं हो सकती है।

2) आपकी समर्थन फ़ाइलें वैध प्रति मशीन (विभिन्न मशीनों के बीच प्रतियों से बचने के लिए) हैं और वे इस तरह से एन्क्रिप्ट किए गए हैं कि उन्हें किसी भी व्यक्ति द्वारा बदला जा सकता है (जानबूझकर या नहीं)। 3) आपकी समर्थन फाइलें प्रति-मशीन मान्य हैं और वे हैंश है जिस तरह से आपका एप्लिकेशन बाहरी परिवर्तनों का पता लगा सकता है।

4) इससे कोई फ़र्क नहीं पड़ता कि उपयोगकर्ता आपकी कॉन्फ़िगरेशन फ़ाइलों के साथ क्या करते हैं, एप्लिकेशन स्वयं ही इसके व्यवहार को नहीं बदल सकता है (उदाहरण के लिए यह एक ही इंस्टॉलेशन है जहां केवल एक डीबी और एक कैटलॉग मौजूद है)।