SQL-injektioner med erstatning af enkeltanførselstegn og valider heltal

Hvis dette er et ældre projekt, der er kodet på denne måde, så, selvom det ikke er optimalt, er jeg i øjeblikket ikke klar over nogen måde, hvorpå det kan være modtageligt for SQL-injektion, så længe hver streng behandles på den måde, og forespørgslerne bare er enkle som du har vist.

Jeg kan dog ikke sige mere sikkerhed end det. Uden at bruge parametriserede forespørgsler er der altid mulighed for, at der er en eller anden sårbarhed, som du endnu ikke har overvejet.

Manuelt at undslippe citaterne selv er udsat for fejl og kan nogle gange mislykkes på måder, der er svære at forudse på forhånd. For eksempel med følgende tabel

CREATE TABLE myTable(title VARCHAR(100))
INSERT INTO myTable VALUES('Foo')

Og lagret procedure ved hjælp af dynamisk SQL bygget op med strengsammenkædning

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)

Du kan prøve følgende

Normal opdatering

EXEC UpdateMyTable N'Foo'
SELECT * FROM myTable /*Returns "Foo"*/

SQL-injektionsforsøg afvist

EXEC UpdateMyTable N''';DROP TABLE myTable--'
SELECT * FROM myTable  /*Returns "';DROP TABLE myTable--"*/

SQL-injektionsforsøg lykkes og taber tabellen

EXEC UpdateMyTable N'ʼ;DROP TABLE myTable--'
SELECT * FROM myTable  /*Returns "Invalid object name 'myTable'."*/

Problemet her er, at den tredje forespørgsel passerer U+02BC i stedet for standardapostrof, og derefter tildeles strengen en varchar(max) efter at sanitet indtræffer, som lydløst konverterer dette til en regulær apostrof.

Indtil jeg læser svaret her det problem ville aldrig være faldet mig ind.