Pokud se jedná o starší projekt, který je kódován tímto způsobem, pak, i když to není optimální, nejsem si v současné době vědom žádným způsobem, že by mohl být náchylný k injektování SQL, pokud je každý řetězec ošetřen tímto způsobem a dotazy jsou jednoduché ty, jak jsi ukázal.
Nemohu však prohlásit o nic větší jistotu. Bez použití parametrizovaných dotazů vždy existuje možnost, že existuje nějaká zranitelnost, o které jste dosud neuvažovali.
Ruční únik z uvozovek je náchylný k chybám a někdy může selhat způsoby, které je obtížné předem předvídat. Například pomocí následující tabulky
CREATE TABLE myTable(title VARCHAR(100))
INSERT INTO myTable VALUES('Foo')
A uložená procedura pomocí dynamického SQL vytvořeného se zřetězením řetězců
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)
Můžete zkusit následující
Normální aktualizace
EXEC UpdateMyTable N'Foo'
SELECT * FROM myTable /*Returns "Foo"*/
Pokus o vložení SQL zmařen
EXEC UpdateMyTable N''';DROP TABLE myTable--'
SELECT * FROM myTable /*Returns "';DROP TABLE myTable--"*/
Pokus o SQL Injection je úspěšný a zahodí tabulku
EXEC UpdateMyTable N'ʼ;DROP TABLE myTable--'
SELECT * FROM myTable /*Returns "Invalid object name 'myTable'."*/
Problém je v tom, že třetí dotaz prochází U+02BC místo standardního apostrofu a pak je řetězec přiřazen k varchar(max) poté, co dojde k sanitaci, která to tiše převede na běžný apostrof.
Dokud si nepřečtu odpověď zde ten problém by mě nikdy nenapadl.