यदि यह एक विरासत परियोजना है जिसे इस तरह से कोडित किया गया है, तो इष्टतम नहीं होने पर, मुझे वर्तमान में किसी भी तरह से पता नहीं है कि यह SQL इंजेक्शन के लिए अतिसंवेदनशील हो सकता है जब तक कि प्रत्येक स्ट्रिंग को उस तरीके से व्यवहार किया जाता है और प्रश्न केवल सरल होते हैं जिन्हें आपने दिखाया है।
हालाँकि मैं इससे अधिक निश्चितता नहीं बता सकता। पैरामीट्रिज्ड प्रश्नों का उपयोग किए बिना हमेशा संभावना है कि कुछ भेद्यता है जिस पर आपने अभी तक विचार नहीं किया है।
मैन्युअल रूप से उद्धरणों से बचना स्वयं त्रुटि प्रवण है और कभी-कभी उन तरीकों से विफल हो सकता है जिनका पहले से अनुमान लगाना मुश्किल होता है। उदाहरण के लिए निम्न तालिका के साथ
CREATE TABLE myTable(title VARCHAR(100))
INSERT INTO myTable VALUES('Foo')
और स्ट्रिंग संयोजन के साथ निर्मित गतिशील SQL का उपयोग करके संग्रहीत कार्यविधि
CREATE PROC UpdateMyTable
@newtitle NVARCHAR(100)
AS
/*
Double up any single quotes
*/
SET @newtitle = REPLACE(@newtitle, '''','''''')
DECLARE @UpdateStatement VARCHAR(MAX)
SET @UpdateStatement = 'UPDATE myTable SET title=''' + @newtitle + ''''
EXEC(@UpdateStatement)
आप निम्न कोशिश कर सकते हैं
सामान्य अपडेट
EXEC UpdateMyTable N'Foo'
SELECT * FROM myTable /*Returns "Foo"*/
SQL इंजेक्शन प्रयास विफल
EXEC UpdateMyTable N''';DROP TABLE myTable--'
SELECT * FROM myTable /*Returns "';DROP TABLE myTable--"*/
SQL इंजेक्शन का प्रयास सफल होता है और तालिका को छोड़ देता है
EXEC UpdateMyTable N'ʼ;DROP TABLE myTable--'
SELECT * FROM myTable /*Returns "Invalid object name 'myTable'."*/
यहां मुद्दा यह है कि तीसरी क्वेरी U+02BC मानक एपॉस्ट्रॉफी के बजाय और फिर स्ट्रिंग को varchar(max) . को असाइन किया जाता है स्वच्छता के बाद जो चुपचाप इसे नियमित धर्मत्याग में बदल देता है।
जब तक मैं यहां उत्तर पढ़ता हूं वह मुद्दा मेरे साथ कभी नहीं हुआ होगा।
