Wenn dies ein Legacy-Projekt ist, das auf diese Weise codiert ist, ist mir derzeit keine Möglichkeit bekannt, dass es anfällig für SQL-Injection sein kann, solange jede Zeichenfolge auf diese Weise behandelt wird und die Abfragen einfach sind, obwohl dies nicht optimal ist diejenigen, wie Sie gezeigt haben.
Mehr Gewissheit kann ich aber nicht sagen. Ohne die Verwendung parametrisierter Abfragen besteht immer die Möglichkeit, dass es eine Schwachstelle gibt, die Sie noch nicht berücksichtigt haben.
Das manuelle Maskieren der Anführungszeichen ist fehleranfällig und kann manchmal auf eine Weise fehlschlagen, die im Voraus nur schwer vorhersehbar ist. Zum Beispiel mit der folgenden Tabelle
CREATE TABLE myTable(title VARCHAR(100))
INSERT INTO myTable VALUES('Foo')
Und gespeicherte Prozedur mit dynamischem SQL, aufgebaut mit String-Verkettung
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)
Sie können Folgendes versuchen
Normales Update
EXEC UpdateMyTable N'Foo'
SELECT * FROM myTable /*Returns "Foo"*/
SQL-Injection-Versuch vereitelt
EXEC UpdateMyTable N''';DROP TABLE myTable--'
SELECT * FROM myTable /*Returns "';DROP TABLE myTable--"*/
Der SQL-Injection-Versuch ist erfolgreich und löscht die Tabelle
EXEC UpdateMyTable N'ʼ;DROP TABLE myTable--'
SELECT * FROM myTable /*Returns "Invalid object name 'myTable'."*/
Das Problem hier ist, dass die dritte Abfrage U+02BC anstelle des Standard-Apostrophs und dann wird die Zeichenfolge einem varchar(max) zugewiesen nachdem die Sanierung erfolgt ist, wodurch dies stillschweigend in ein reguläres Apostroph umgewandelt wird.
Bis ich die Antwort hier gelesen habe Das Problem wäre mir nie in den Sinn gekommen.
