12
मुझे अपने एएसपी.NET एप्लिकेशन में एसक्यूएल इंजेक्शन के लिए कमजोर होने से बचने की जरूरत है। मैं इसे कैसे पूरा कर सकता हूं?मैं अपने एएसपी.NET एप्लिकेशन में एसक्यूएल इंजेक्शन हमलों से कैसे बच सकता हूं?
A
उत्तर
19
भले ही आपके प्रश्न बहुत सामान्य है, हमेशा कुछ नियम लागू होते हैं:
- उपयोग पैरामिट्रीकृत प्रश्नों (
SqlParameterसाथSqlCommand) और मानकों में उपयोगकर्ता इनपुट डाल दिया। - अनचेक उपयोगकर्ता इनपुट से SQL स्ट्रिंग्स का निर्माण न करें।
- मान लें कि आप एक स्वच्छता दिनचर्या तैयार कर सकते हैं जो हर प्रकार की विकृति के लिए उपयोगकर्ता इनपुट की जांच कर सकता है। एज मामलों को आसानी से भुला दिया जाता है। संख्यात्मक इनपुट की जांच करना आपको सुरक्षित पक्ष पर लाने के लिए काफी आसान हो सकता है, लेकिन स्ट्रिंग इनपुट के लिए केवल पैरामीटर का उपयोग करें।
- द्वितीय-स्तरीय vulnerabilites की जांच करें - SQL तालिका मानों से SQL क्वेरी स्ट्रिंग्स का निर्माण न करें यदि इन मानों में उपयोगकर्ता इनपुट शामिल है।
- डेटाबेस संचालन को समाहित करने के लिए संग्रहीत प्रक्रियाओं का उपयोग करें।
-4
संग्रहीत प्रक्रियाओं का उपयोग करने का प्रयास करें, और अपने डेटा पर इनपुट को सत्यापित करें। किसी भी प्रत्यक्ष एसक्यूएल का उपयोग न करें जैसे INSERT INTO ...
+0
संग्रहित प्रक्रिया यह कोई लेना देना नहीं है, तो आप कॉल parameterizing नहीं द्वारा एक असुरक्षित रास्ते में एक सपा निष्पादित कर सकते हैं। – Flory
16
Prepared Statements का उपयोग करें (एएसपी.NET ट्यूटोरियल से लिंक करें जो 'उत्पादों के लिए नोड्स जोड़ने के लिए' अनुभाग में तैयार कथन का उपयोग करता है)। यही सब है इसके लिए।
ठीक है, या Linq to SQL या NHibernate जैसे ओआरएम का उपयोग करें, वे आंतरिक रूप से तैयार कथन का उपयोग करते हैं।
4
एसक्यूएल इंजेक्शन होती है क्योंकि डेटाबेस के लिए क्वेरी वास्तविक समय में निर्माण किया जा रहा है, उदाहरण के लिए:
SELECT * From Table1 WHERE " + UserInput
UserInput दुर्भावनापूर्ण हो सकता है और अन्य बयान है कि आप का इरादा नहीं हो सकती है।
इससे बचने के लिए, आपको अपनी क्वेरी को एकसाथ संयोजित करने से बचने की आवश्यकता है।
आप parametrized प्रश्नों का उपयोग करके इसे पूरा कर सकते हैं - अपने विशेष डीबी स्वाद के लिए DBCommand ऑब्जेक्ट देखें।
10
पैरामीटर का उपयोग करें!
SqlCommand getPersons = new SqlCommand("SELECT * FROM Table WHERE Name = @Name", conn);
यहाँ @Name पैरामीटर जहां एसक्यूएल इंजेक्शन से बचना चाहते हैं और Conn एक है: सचमुच यह इतना आसान :-)
अपने (साथ सी # एमएस Sql सर्वर के लिए) इस तरह के प्रश्नों बनाएं है SqlConnection ऑब्जेक्ट। तब पैरामीटर मान आप निम्न कर जोड़ने के लिए:
getPersons.Parameters.AddWithValue("@Name", theName);
यहाँ theName एक चर नाम आप खोज रहे हैं शामिल हैं।
अब उस क्वेरी पर किसी भी एसक्यूएल इंजेक्शन करना असंभव होना चाहिए।
चूंकि यह आसान है पैरामीटर का उपयोग न करने का कोई कारण नहीं है।
+0
+1। –
1
उम्मीद है, इस में मदद मिलेगी:
http://www.codersbarn.com/post/2008/11/01/ASPNET-Data-Input-Validation.aspx
संक्षिप्त उत्तर पैरामिट्रीकृत प्रश्नों का उपयोग करने के लिए है।
एंथोनी :-) www.codersbarn.com
3
स्कॉट गुथरी इस बारे में posted a decent little article एक समय पहले।
एक प्रकार सुरक्षित पैरामीटर एन्कोडिंग प्रणाली का उपयोग किए बिना गतिशील एसक्यूएल बयान का निर्माण नहीं है: इस रिपोर्ट में उन्होंने खुद को बचाने के लिए 5 सुझाव देता है।[...]
हमेशा पहले कभी अपने आवेदन की सुरक्षा की समीक्षा का संचालन उत्पादन में डाल दिया, और एक औपचारिक सुरक्षा प्रक्रिया सभी कोड किसी भी समय आप अपडेट की समीक्षा की स्थापना करते हैं।[...]
एक डेटाबेस के भीतर स्पष्ट-पाठ में संवेदनशील डेटा कभी दुकान।[...]
सुनिश्चित करें कि आप स्वचालन इकाई परीक्षण है कि विशेष रूप से SQL इंजेक्शन हमलों के खिलाफ अपने डेटा का उपयोग परत और आवेदन को सत्यापित लिखें।[...]
अपने डेटाबेस नीचे लॉक केवल वेब अनुप्रयोग यह अनुमतियों के न्यूनतम सेट है कि यह कार्य करने के लिए की जरूरत है तक पहुँचने देने के लिए।[...]
वह समझाने का एक सभ्य काम क्यों इन महत्वपूर्ण हैं, और कई अन्य संसाधनों के रूप में अच्छी तरह लिंक ...
1
हमेशा ही पैरामिट्रीकृत का उपयोग करता है प्रश्नों।
2
उपयोगकर्ता इनपुट पर भरोसा न करें, हमेशा इसे सत्यापित करें, और एसक्यूएल पैरामीटर का उपयोग करें। एसक्यूएल इंजेक्शन को रोकने के लिए पर्याप्त आधार होना चाहिए।
-2
समझें कि वास्तव में एसक्यूएल इंजेक्शन क्या है और फिर कभी भी ऐसा कुछ भी लिखना न करें जो इसके लिए कमजोर है।
0
पुस्तक, "बिल्डिंग सिक्योर एएसपी.NET अनुप्रयोग" गाइड, इस विषय पर section है।
3
पैरामीट्रिज्ड प्रश्नों और/या संग्रहीत प्रक्रियाओं का उपयोग करें और SQL पैरामीटर के माध्यम से अपने पैरामीटर पार्स करें। कभी भी स्ट्रिंग को संयोजित करके SQL कोड उत्पन्न करता है। एसक्यूएल इंजेक्शन और सुरक्षित कोड लिखने के बारे में कुछ पढ़ना भी करें, क्योंकि एसक्यूएल इंजेक्शन को रोकने से सुरक्षा का केवल एक छोटा सा हिस्सा है। कई और हैं (जैसे एक्सएसएस - क्रॉस साइट स्क्रिप्टिंग)। यदि कोई हैकर आपकी साइट/एप्लिकेशन से समझौता करना चाहता है तो वह केवल एसक्यूएल इंजेक्शन के लिए अधिक खोज करेगा।
10
कभी विश्वास उपयोगकर्ता इनपुट - मान्यता नियंत्रण, नियमित अभिव्यक्ति, कोड का उपयोग कर सभी पाठ बॉक्स प्रविष्टियों का सत्यापन करें, और इतने पर
कभी गतिशील एसक्यूएल का उपयोग करें - पैरामिट्रीकृत एसक्यूएल उपयोग या संग्रहित प्रक्रियाओं
कभी व्यवस्थापक-स्तरीय खाते का उपयोग कर डेटाबेस से कनेक्ट करें - डेटाबेस से कनेक्ट करने के लिए सीमित पहुंच खाते का उपयोग करें
डी सादा पाठ में स्टोर रहस्यों पर नहीं - एन्क्रिप्ट या हैश पासवर्ड और अन्य संवेदनशील डेटा; आपको कनेक्शन स्ट्रिंग्स को भी एन्क्रिप्ट करना चाहिए
अपवादों को न्यूनतम जानकारी प्रकट करना चाहिए - त्रुटि संदेशों में बहुत अधिक जानकारी प्रकट न करें; अनचाहे त्रुटि की स्थिति में न्यूनतम जानकारी प्रदर्शित करने के लिए customErrors का उपयोग करें; MSDN Stop SQL Injection पर झूठी
उपयोगी लिंक करने के लिए सेट डिबग
+0
अच्छा जवाब, लेकिन, मैं "गतिशील एसक्यूएल का उपयोग कभी नहीं" से असहमत हूं। गतिशील एसक्यूएल एक बहुत ही सामान्य शब्द है और यह बहुत शक्तिशाली हो सकता है और ऐसे कई मामले हैं जहां इसका उपयोग किया जाना चाहिए। आपका बिंदु केवल पैरामीटर के रूप में परिवर्तनीय डेटा पास होना चाहिए। –
+0
ऐ रॉबिन, मैं मानता हूं कि डायनामिक एसक्यूएल बहुत उपयोगी हो सकता है और कुछ अच्छे मामले हैं जहां इसका इस्तेमाल किया जाना चाहिए, मेरे बिंदुओं पर जहां पूरी तरह से बाहरी दुनिया में उपयोगकर्ता के साथ बातचीत पर आधारित है, उन्हें एसक्यूएल इंजेक्शन रोकने के लिए। उदाहरण के लिए, एसक्यूएल के संगतता द्वारा उपयोगकर्ता द्वारा दर्ज मूल्यों के साथ निर्मित एक SQL कथन। – kevchadders
+0
हम्म मुझे अभी -1 वोट मिले हैं और साथ ही मेरे नीचे कई पदों को हम सभी को नीचे ला रहे हैं? (सभी एक ही उपयोगकर्ता द्वारा शायद ??) – kevchadders
0
अन्य लोगों ने कहा के रूप में, गतिशील एसक्यूएल बयान बनाने के लिए उपयोगकर्ता इनपुट जोड़ नहीं है; गतिशील एसक्यूएल का उपयोग करते समय हमेशा पैरामीटरयुक्त एसक्यूएल का उपयोग करें। हालांकि मैं इंगित करता हूं कि यह नियम तब भी लागू होता है जब संग्रहीत प्रो के अंदर गतिशील एसक्यूएल बनाते हैं। यह तथ्य कुछ लोग अक्सर अनदेखा करते हैं। उन्हें लगता है कि वे सुरक्षित हैं क्योंकि वे "संग्रहित प्रक्रियाओं का उपयोग कर रहे हैं।"
0
Microsoft.Security.AntiXss.UrlEncode और SQL इंजेक्शन का उपयोग कर XSS सुरक्षित UrlEncode का उपयोग करें। या आप ASP.NET - JSON - Serialization और Deserialization
मैकफी फ्री टूल से साइटडिगर के साथ अपने एप्लिकेशन का परीक्षण भी कर सकते हैं।
कुछ अधिक कर रहे हैं here
नेट सुरक्षा टूलकिट v1.0 .NETMon v1.0 Validator.NET v1.0
0
हर कोई कहता है "का प्रयोग करें पैरामीटर" से। अगर हमें इतना मुश्किल नहीं था तो हमें इसे कम कहना होगा।
QueryFirst का उपयोग करें। Concatenate करने के लिए प्रलोभन हटा दिया गया है, और सही तरीका सबसे आसान तरीका बन जाता है। आप अपने एसक्यूएल में @myParam टाइप करके केवल पैरामीटर बनाते हैं, टूल बाकी करता है।
अस्वीकरण: मैं QueryFirst लिखा
उनमें से सभी, शायद आखिरी व्यक्ति को छोड़कर, पहले एक द्वारा निहित किए गए हैं (यदि आपका सभी इनपुट तैयार बयान (या पैरामीटरयुक्त प्रश्न) के उपयोग से हमेशा से बच निकला है, तो नहीं? या आपको लगता है कि सूक्ष्म मतभेद हैं? –
नहीं, लेकिन कोई भी जो इस तरह के प्रश्न पूछता है, उसके पास प्रभावों की कोई दृढ़ समझ नहीं है। उन्हें स्पष्ट करना समझदारी का समर्थन कर रहा है। आपके अनुभव और क्षमताओं को अमूर्त वृद्धि के रूप में, आपको स्पष्टीकरण की आवश्यकता नहीं होगी, और आप अब ऐसे प्रश्न पूछने की संभावना नहीं रखते हैं। – Tomalak
यह एक अच्छा जवाब है, लेकिन मुझे लगता है कि "डेटाबेस संचालन को समाहित करने के लिए संग्रहीत प्रक्रियाओं का उपयोग करें" भ्रामक है। पैरामीटरेटेड गतिशील एसक्यूएल पैरामीटरकृत संग्रहीत प्रक्रियाओं के समान सुरक्षित है। शायद आपको स्पष्टता के लिए अपने उत्तर में यह अधिक अंतर्निहित बनाना चाहिए। –