Sql इंजेक्शन को रोकने के लिए पैरामीटर्स वास्तव में पर्याप्त हैं?

Question 1

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

लेकिन मुझे आश्चर्य हो रहा है कि क्या यह वास्तव में सच है। क्या कोई ज्ञात एसक्यूएल इंजेक्शन हमले हैं जो एक पैरामीटर क्वेरी के खिलाफ सफल होंगे? क्या आप उदाहरण के लिए एक स्ट्रिंग भेज सकते हैं जो सर्वर पर एक बफर अतिप्रवाह का कारण बनता है?

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

संपादित करें: यह स्पष्ट करने के लिए कि मैं मापदंडों और मानकीकृत प्रश्नों से क्या मतलब रखता हूं। एक स्ट्रिंग में sql क्वेरी बनाने के बजाय "वैरिएबल्स" का उपयोग करने का मेरा मतलब है कि मापदंडों का उपयोग करके।
इसलिए ऐसा करने के बजाय:

SELECT * FROM Table WHERE Name = 'a name'

हम यह करते हैं:

SELECT * FROM Table WHERE Name = @Name

और फिर क्वेरी / कमांड ऑब्जेक्ट पर @Name पैरामीटर का मान सेट करें।

Question 2

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

आप प्लेसहोल्डर्स के अंदर फ़ंक्शंस का उपयोग नहीं कर सकते हैं, और आप प्लेसहोल्डर्स को कॉलम या टेबल नामों के रूप में उपयोग नहीं कर सकते हैं, क्योंकि वे स्ट्रिंग फाइनल्स के रूप में बच गए हैं और उद्धृत किए गए हैं।

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

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

Question 3

नहीं, जब भी आप किसी SQL क्वेरी में अनवांटेड डेटा को इंटरपोलेट करते हैं, तब भी SQL इंजेक्शन का जोखिम रहता है।

क्वेरी पैरामीटर SQL सिंटैक्स से शाब्दिक मानों को अलग करके इस जोखिम से बचने में मदद करते हैं।

'SELECT * FROM mytable WHERE colname = ?'

यह ठीक है, लेकिन डायनेमिक SQL क्वेरी में डेटा को इंटरपोलेट करने के अन्य उद्देश्य हैं जो क्वेरी मापदंडों का उपयोग नहीं कर सकते हैं, क्योंकि यह एक एसक्यूएल मूल्य नहीं है, बल्कि एक टेबल का नाम, कॉलम का नाम, अभिव्यक्ति, या कुछ अन्य सिंटैक्स है।

'SELECT * FROM ' + @tablename + ' WHERE colname IN (' + @comma_list + ')'
' ORDER BY ' + @colname'

इससे कोई फर्क नहीं पड़ता कि आप संग्रहीत प्रक्रियाओं का उपयोग कर रहे हैं या एप्लिकेशन कोड से डायनेमिक SQL क्वेरी को सीधे निष्पादित कर रहे हैं। जोखिम अभी भी है।

इन मामलों में उपाय आवश्यकतानुसार FIEO को नियोजित करना है :

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

Question 4

"पैरामीटर क्वेरी" की परिभाषा के बारे में इस धागे में कुछ भ्रम प्रतीत होता है।

एसक्यूएल जैसे संग्रहित खरीद जो मापदंडों को स्वीकार करता है।
SQL जिसे DBMS पैरामीटर संग्रह का उपयोग करके कहा जाता है।

पूर्व परिभाषा को देखते हुए, कई लिंक काम करने के हमलों को दिखाते हैं।

लेकिन "सामान्य" परिभाषा बाद वाली है। उस परिभाषा को देखते हुए, मैं किसी भी SQL इंजेक्शन हमले के बारे में नहीं जानता जो काम करेगा। इसका मतलब यह नहीं है कि कोई नहीं है, लेकिन मुझे अभी तक इसे देखना नहीं है।

टिप्पणियों से, मैं खुद को स्पष्ट रूप से पर्याप्त रूप से व्यक्त नहीं कर रहा हूं, इसलिए यहां एक उदाहरण है जो उम्मीद है कि स्पष्ट होगा:

यह दृष्टिकोण है एसक्यूएल इंजेक्शन के लिए खुला

exec dbo.MyStoredProc 'DodgyText'

यह दृष्टिकोण SQL इंजेक्शन के लिए खुला नहीं है

using (SqlCommand cmd = new SqlCommand("dbo.MyStoredProc", testConnection))
{
    cmd.CommandType = CommandType.StoredProcedure;
    SqlParameter newParam = new SqlParameter(paramName, SqlDbType.Varchar);
    newParam.Value = "DodgyText";
    .....
    cmd.Parameters.Add(newParam);
    .....
    cmd.ExecuteNonQuery();
}

Question 5

डायनेमिक क्वेरी बनाने के लिए उपयोग किया जाने वाला स्ट्रिंग प्रकार (varchar, nvarchar, आदि) का कोई भी sql पैरामीटर अभी भी असुरक्षित है

अन्यथा पैरामीटर प्रकार रूपांतरण (उदाहरण के लिए, दशमलव, तिथि, आदि) पैरामीटर के माध्यम से sql को इंजेक्ट करने के किसी भी प्रयास को समाप्त करना चाहिए

संपादित करें: एक उदाहरण, जहां पैरामीटर @ p1 एक तालिका नाम है

create procedure dbo.uspBeAfraidBeVeryAfraid ( @p1 varchar(64) ) 
AS
    SET NOCOUNT ON
    declare @sql varchar(512)
    set @sql = 'select * from ' + @p1
    exec(@sql)
GO

यदि @ p1 को ड्रॉप-डाउन सूची से चुना गया है तो यह एक संभावित sql-injection attack वेक्टर है;

यदि @ p1 प्रोग्रामेटिक रूप से w / तैयार किया जाता है, तो उपयोगकर्ता की हस्तक्षेप करने की क्षमता समाप्त हो जाती है, तो यह संभावित sql-injection attack वेक्टर नहीं है

Question 6

एक बफर अतिप्रवाह एसक्यूएल इंजेक्शन नहीं है।

पैरामीटर क्वेरीज़ की गारंटी देता है कि आप SQL इंजेक्शन के खिलाफ सुरक्षित हैं। वे गारंटी नहीं देते कि आपके SQL सर्वर में बग के रूप में संभावित कारनामे नहीं हैं, लेकिन कुछ भी गारंटी नहीं देगा।

Question 7

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

Question 8

अतिप्रवाह / छंटनी के माध्यम से विशेष प्रकार के एसक्यूएल इंजेक्शन के प्रति संवेदनशील होने के लिए एक संग्रहीत खरीद के लिए संभव है, देखें: यहां डेटा ट्रंकेशन द्वारा सक्षम इंजेक्शन:

http://msdn.microsoft.com/en-us/library/ms161953.aspx

Question 9

बस याद रखें कि मापदंडों के साथ आप आसानी से स्ट्रिंग को स्टोर कर सकते हैं, या उपयोगकर्ता नाम कह सकते हैं यदि आपकी कोई नीतियां नहीं हैं, "); ड्रॉप टेबल उपयोगकर्ता; -"

यह अपने आप में कोई नुकसान नहीं पहुंचाएगा, लेकिन आप बेहतर जानते हैं कि आपके आवेदन में आगे कहां और कैसे तिथि का उपयोग किया जाता है (जैसे कि कुकी में संग्रहीत, बाद में अन्य सामान करने के लिए पुनः प्राप्त।

Question 10

आप उदाहरण के रूप में गतिशील sql चला सकते हैं

DECLARE @SQL NVARCHAR(4000);
DECLARE @ParameterDefinition NVARCHAR(4000);

SELECT  @ParameterDefinition = '@date varchar(10)'

SET @SQL='Select CAST(@date AS DATETIME) Date'

EXEC sp_executeSQL @SQL,@ParameterDefinition,@date='04/15/2011'