सी # कोड से एमएसएसएलएल सर्वर पर एसक्यूएल इंजेक्शन से बचने के लिए एल्गोरिदम?

Question

सी # .नेट प्लेटफॉर्म पर एसक्यूएल इंजेक्शन से बचने का सबसे अच्छा तरीका क्या होगा।

यदि आपके पास कोई है तो कृपया सी # कार्यान्वयन पोस्ट करें।

Answer 1

शीर्ष 10 बातें हम सुरक्षित रहने के लिए क्या कर सकते हैं (इनमें से कोई भी यह सब कर सकते हैं।)

1. धारणा है कि, अपनाना "सभी डेटा बुराई है।" सभी डेटा, डेटाबेस में या हमारे फाइल सिस्टम पर संग्रहीत डेटा भी संदिग्ध है। हमारे फ़ायरवॉल के बाहर ऐप्स से क्वेरी इनपुट नहीं, जैसे क्वेरी स्ट्रिंग्स, फॉर्म फ़ील्ड्स, कुकीज इत्यादि। सिस्टम का समझौता करने के लिए कुछ भी इस्तेमाल किया जा सकता है।

2. जावास्क्रिप्ट या एचटीएमएल फ़ील्ड की लंबाई या यहां तक ​​कि सर्वर-साइड वेब एपीआई क्लाइंट-साइड सत्यापन का उपयोग करने वाले क्लाइंट-साइड सत्यापन पर भरोसा न करें। उपयोगिता में सुधार के लिए इसका इस्तेमाल करें, लेकिन इसे एकमात्र गार्ड के रूप में भरोसा न करें। पता करें कि एनईटी काम जैसे एपीआई द्वारा प्रदान किए गए वैधकर्ता कैसे। उन्हें मंजूरी के लिए मत लेना। उनके चारों ओर तरीके हैं।

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

4. जब संभव हो, तो "अद्यतन", "हटाएं", "ड्रॉप", "चयन करें", "परिवर्तन" आदि के साथ स्ट्रिंग डेटा फ़िल्टरिंग, फ़्लैगिंग या पकड़ने पर विचार करें। यह संभव नहीं हो सकता है स्ट्रिंग। "1212 लेमोन्ड्रॉप एलएन", "वाल्टर्सबर्ग, पीए", और "टेबल रॉक, एनई" वैध पता फ़ील्ड हैं। इनमें से किसी भी मैच से मेल खाने वाले फ़ील्ड के लिए सभी तालिका डेटा का दैनिक स्कैन चलाकर देरी वाले हमलों या भेद्यताएं प्रकट हो सकती हैं। लॉगिंग, आईपी प्रतिबंध, ईमेल अलर्ट इत्यादि भी लॉग इन किया जा सकता है क्योंकि डेटा इनबाउंड आता है।

5. संग्रहीत प्रक्रियाओं और/या पैरामीटरयुक्त प्रश्नों को जितना संभव हो सके उपयोग करें। डीबी क्लाइंट कोड और एसक्यूएल में गतिशील एसक्यूएल से बचें। (अपनी संग्रहीत प्रक्रियाओं में बाहरी अनुभागों के साथ गतिशील कोड के साथ निष्पादन कथन से बचें !!!) पैरामीटरेशन एस्ट्रोफ़े, स्ट्रिंग फील्ड लम्बाई, और टाइप चेक जैसे स्ट्रिंग टर्मिनेटर से बच जाएगा। हम उन एपीआई पर हमेशा भरोसा नहीं कर सकते जो पैरामीटर को सही होने के लिए प्रदान करते हैं, लेकिन वे लोगों में से अधिकांश की तुलना में डेटाबेस idiosyncracies के बारे में अधिक जागरूक हैं।

6. सुनिश्चित करें कि दुनिया भर में पढ़ने योग्य/निष्पादन योग्य वेब निर्देशिका में कोई भटक कोड नहीं है। यदि यह सक्रिय साइट का हिस्सा नहीं है, तो इसे कहीं सुरक्षित रूप से संग्रहीत करें और इसे सार्वजनिक दृश्य से हटा दें। अप्रयुक्त संग्रहीत प्रक्रियाओं के लिए ही चला जाता है।

7. डेटाबेस एपीआई पर अद्यतित रहें। कुछ एपीआई में एसक्यूएल कथन निष्पादित करने के कुछ तरीके दूसरों के जितना सुरक्षित नहीं हैं।

8. एक-तरफा एन्क्रिप्शन के साथ सुरक्षित रूप से पासवर्ड स्टोर करें। इस तरह, उपयोगकर्ता नाम और पासवर्ड के एक टेबल डंप को अभी भी लोगों को बाहर रखना चाहिए।

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

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

और # 11, इस सूची को हमेशा संशोधित/संशोधित करें। हमेशा अद्यतित रहें। सक्रिय होना। विचार के बाद नहीं, इसे अग्रिम प्राथमिकता और आवश्यकता बनाएं।

Answer 2

कोई एल्गोरिदम आवश्यक नहीं है - बस SQL ​​कथन बनाने के लिए स्ट्रिंग concatenation का उपयोग न करें। इसके बजाय SqlCommand.Parameters संग्रह का उपयोग करें। यह मूल्यों के सभी आवश्यक भागने (जैसे ' को '' के साथ बदलना) करता है और यह सुनिश्चित करता है कि आदेश सुरक्षित रहेगा क्योंकि किसी और (यानी माइक्रोसॉफ्ट) ने सभी परीक्षण किए हैं।

उदा। संग्रहीत प्रक्रिया को कॉल करना:

using (var connection = new SqlConnection("...")) 
using (var command = new SqlCommand("MySprocName", connection)) 
{ 
    command.CommandType = CommandType.StoredProcedure; 
    command.Parameters.AddWithValue("@Param1", param1Value); 
    return command.ExecuteReader(); 
} 

यह तकनीक इनलाइन एसक्यूएल स्टेटमेंट्स के लिए भी काम करती है, उदाहरण के लिए

var sql = "SELECT * FROM MyTable WHERE MyColumn = @Param1"; 
using (var connection = new SqlConnection("...")) 
using (var command = new SqlCommand(sql, connection)) 
{ 
    command.Parameters.AddWithValue("@Param1", param1Value); 
    return command.ExecuteReader(); 
}