Jika ini adalah proyek warisan yang dikodekan dengan cara ini, meskipun tidak optimal, saat ini saya tidak mengetahui cara apa pun yang dapat rentan terhadap injeksi SQL selama setiap string diperlakukan dengan cara itu dan kuerinya sederhana yang seperti yang telah Anda tunjukkan.
Namun saya tidak bisa menyatakan kepastian lebih dari itu. Tanpa menggunakan kueri parametris, selalu ada kemungkinan bahwa ada beberapa kerentanan yang belum Anda pertimbangkan.
Melarikan diri secara manual dari tanda kutip sendiri rawan kesalahan dan terkadang bisa gagal dengan cara yang sulit diantisipasi sebelumnya. Misalnya dengan tabel berikut
CREATE TABLE myTable(title VARCHAR(100))
INSERT INTO myTable VALUES('Foo')
Dan prosedur tersimpan menggunakan SQL dinamis yang dibangun dengan rangkaian string
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)
Anda dapat mencoba yang berikut
Pembaruan biasa
EXEC UpdateMyTable N'Foo'
SELECT * FROM myTable /*Returns "Foo"*/
Upaya Injeksi SQL digagalkan
EXEC UpdateMyTable N''';DROP TABLE myTable--'
SELECT * FROM myTable /*Returns "';DROP TABLE myTable--"*/
Upaya SQL Injection berhasil dan menjatuhkan tabel
EXEC UpdateMyTable N'ʼ;DROP TABLE myTable--'
SELECT * FROM myTable /*Returns "Invalid object name 'myTable'."*/
Masalahnya di sini adalah bahwa kueri ketiga melewati U+02BC alih-alih apostrof standar dan kemudian string ditetapkan ke varchar(max) setelah sanitasi terjadi yang secara diam-diam mengubah ini menjadi tanda kutip biasa.
Sampai saya membaca jawabannya di sini masalah itu tidak akan pernah terpikir oleh saya.
