Si este es un proyecto heredado que está codificado de esta manera, aunque no es óptimo, actualmente no estoy al tanto de ninguna forma en que pueda ser susceptible a la inyección de SQL siempre que cada cadena se trate de esa manera y las consultas sean simplemente simples. como usted ha mostrado.
Sin embargo, no puedo afirmar más certeza que eso. Sin utilizar consultas parametrizadas siempre existe la posibilidad de que haya alguna vulnerabilidad que aún no hayas considerado.
Escapar manualmente las comillas usted mismo es propenso a errores y, a veces, puede fallar de formas que son difíciles de anticipar por adelantado. Por ejemplo con la siguiente tabla
CREATE TABLE myTable(title VARCHAR(100))
INSERT INTO myTable VALUES('Foo')
Y procedimiento almacenado usando SQL dinámico creado con concatenación de cadenas
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)
Puedes intentar lo siguiente
Actualización normal
EXEC UpdateMyTable N'Foo'
SELECT * FROM myTable /*Returns "Foo"*/
Intento de inyección SQL frustrado
EXEC UpdateMyTable N''';DROP TABLE myTable--'
SELECT * FROM myTable /*Returns "';DROP TABLE myTable--"*/
El intento de inyección SQL tiene éxito y deja caer la tabla
EXEC UpdateMyTable N'ʼ;DROP TABLE myTable--'
SELECT * FROM myTable /*Returns "Invalid object name 'myTable'."*/
El problema aquí es que la tercera consulta pasa U+02BC en lugar del apóstrofe estándar y luego la cadena se asigna a un varchar(max) después de que ocurra el saneamiento, que silenciosamente convierte esto en un apóstrofe regular.
Hasta que leí la respuesta aquí ese tema nunca se me hubiera ocurrido.
