Jeśli jest to przestarzały projekt, który jest zakodowany w ten sposób, to, chociaż nie jest optymalny, nie jestem obecnie świadomy w żaden sposób, że może być podatny na wstrzyknięcie SQL, o ile każdy ciąg jest traktowany w ten sposób, a zapytania są po prostu proste te, jak pokazałeś.
Nie mogę jednak stwierdzić większej pewności niż to. Bez użycia sparametryzowanych zapytań zawsze istnieje możliwość, że istnieje jakaś podatność, której jeszcze nie brałeś pod uwagę.
Ręczne unikanie cytatów jest podatne na błędy i czasami może zakończyć się niepowodzeniem w sposób trudny do przewidzenia z góry. Na przykład z poniższą tabelą
CREATE TABLE myTable(title VARCHAR(100))
INSERT INTO myTable VALUES('Foo')
I procedura składowana przy użyciu dynamicznego SQL zbudowanego z konkatenacją ciągów
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)
Możesz wypróbować następujące
Normalna aktualizacja
EXEC UpdateMyTable N'Foo'
SELECT * FROM myTable /*Returns "Foo"*/
Próba wstrzyknięcia SQL udaremniona
EXEC UpdateMyTable N''';DROP TABLE myTable--'
SELECT * FROM myTable /*Returns "';DROP TABLE myTable--"*/
Próba wstrzyknięcia SQL kończy się pomyślnie i opuszcza tabelę
EXEC UpdateMyTable N'ʼ;DROP TABLE myTable--'
SELECT * FROM myTable /*Returns "Invalid object name 'myTable'."*/
Problem polega na tym, że trzecie zapytanie przechodzi U+02BC zamiast standardowego apostrofu, a następnie ciąg jest przypisany do varchar(max) po wykonaniu warunków sanitarnych, które po cichu zamieniają to w zwykły apostrof.
Dopóki nie przeczytam odpowiedź tutaj ten problem nigdy by mi nie przyszło do głowy.
