これがこのようにコーディングされたレガシープロジェクトである場合、最適ではありませんが、すべての文字列がそのように処理され、クエリが単純である限り、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を渡し、サニテーションが発生した後に文字列が a に割り当てられ、varchar(max)
これが暗黙のうちに通常のアポストロフィに変換されることです。
ここで答えを読むまで、その問題は私には決して起こらなかったでしょう。