これがこのようにコーディングされたレガシープロジェクトである場合、最適ではありませんが、すべての文字列がそのように処理され、クエリが単純である限り、SQL インジェクションの影響を受ける可能性があることを現在認識していません。あなたが示したもの。
しかし、それ以上の確信はありません。パラメータ化されたクエリを使用しないと、まだ考慮していない脆弱性が存在する可能性が常にあります。
自分で引用符を手動でエスケープすると、エラーが発生しやすく、事前に予測するのが難しい方法で失敗することがあります。たとえば、次の表を使用します
CREATE TABLE myTable(title VARCHAR(100))
INSERT INTO myTable VALUES('Foo')
そして、文字列連結で構築された動的 SQL を使用するストアド プロシージャ
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)
以下を試すことができます
通常更新
EXEC UpdateMyTable N'Foo'
SELECT * FROM myTable /*Returns "Foo"*/
SQL インジェクションの試みは失敗しました
EXEC UpdateMyTable N''';DROP TABLE myTable--'
SELECT * FROM myTable /*Returns "';DROP TABLE myTable--"*/
SQL インジェクションの試行が成功し、テーブルが削除されます
EXEC UpdateMyTable N'ʼ;DROP TABLE myTable--'
SELECT * FROM myTable /*Returns "Invalid object name 'myTable'."*/
ここでの問題は、3 番目のクエリが U+02BC 標準のアポストロフィの代わりに、文字列が varchar(max) に割り当てられます サニテーションが発生した後、これは静かに通常のアポストロフィに変換されます。
こちらの回答 を読むまでは その問題は私には決して起こらなかったでしょう。