Ако това е наследен проект, който е кодиран по този начин, макар и да не е оптимален, в момента не знам за някакъв начин, по който може да бъде податлив на 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) след извършване на санирането, което тихо преобразува това в обикновен апостроф.
Докато не прочетох отговора тук този проблем никога не би ми хрумнал.
