Als dit een verouderd project is dat op deze manier is gecodeerd, ben ik me momenteel niet bewust van een manier waarop het vatbaar kan zijn voor SQL-injectie, zolang elke tekenreeks op die manier wordt behandeld en de vragen eenvoudig zijn zoals je hebt laten zien.
Meer zekerheid dan dat kan ik echter niet geven. Zonder gebruik te maken van geparametriseerde queries is er altijd de mogelijkheid dat er een kwetsbaarheid is waar je nog niet aan hebt gedacht.
Zelf handmatig ontsnappen aan de offertes is foutgevoelig en kan soms mislukken op manieren die moeilijk van tevoren te anticiperen zijn. Bijvoorbeeld met de volgende tabel
CREATE TABLE myTable(title VARCHAR(100))
INSERT INTO myTable VALUES('Foo')
En opgeslagen procedure met behulp van dynamische SQL opgebouwd met tekenreeksaaneenschakeling
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)
Je kunt het volgende proberen
Normale update
EXEC UpdateMyTable N'Foo'
SELECT * FROM myTable /*Returns "Foo"*/
Poging tot SQL-injectie verijdeld
EXEC UpdateMyTable N''';DROP TABLE myTable--'
SELECT * FROM myTable /*Returns "';DROP TABLE myTable--"*/
SQL-injectiepoging slaagt en laat de tabel vallen
EXEC UpdateMyTable N'ʼ;DROP TABLE myTable--'
SELECT * FROM myTable /*Returns "Invalid object name 'myTable'."*/
Het probleem hier is dat de derde query U+02BC in plaats van de standaard apostrof en dan wordt de string toegewezen aan een varchar(max)
nadat de sanering heeft plaatsgevonden die dit in stilte omzet in een gewone apostrof.
Tot ik het antwoord hier las dat probleem zou nooit bij mij zijn opgekomen.