仅能生成完整SQL字符串时，如何生成防范SQL注入的安全SQL命令？

1. DECLARE变量赋值的写法能否防范SQL注入？ #

不能。这种写法本质上还是把用户输入直接拼接进SQL字符串中，依然存在注入风险。

比如用户输入内容为：'; DROP TABLE tablename; --，拼接后的SQL会变成：

DECLARE @Name varchar(50);
SET @Name = ''; DROP TABLE tablename; --';
SELECT * FROM tablename WHERE name = @Name

此时恶意的DROP TABLE语句会被执行，所以这种写法无法防范注入。

2. 如何生成可防范SQL注入的安全SQL命令字符串？ #

由于你的执行服务仅支持纯SQL字符串、不接受参数化查询，只能通过严格的字符串转义来降低注入风险，核心是根据目标数据库的规则转义用户输入中的特殊字符：

针对SQL Server的处理方式 #

SQL Server中需要将用户输入里的单引号'替换为双单引号''，示例代码：

// 转义用户输入中的单引号
var escapedSearchName = incomingdata.searchName.Replace("'", "''");
// 拼接生成安全的SQL
var sql = $@"
DECLARE @Name varchar(50);
SET @Name = '{escapedSearchName}';
SELECT * FROM tablename WHERE name = @Name";

或者直接拼接在WHERE子句中（效果一致）：

var escapedSearchName = incomingdata.searchName.Replace("'", "''");
var sql = $"SELECT * FROM tablename WHERE name = '{escapedSearchName}'";

其他数据库的转义规则参考 #

• MySQL：同样将单引号'替换为双单引号''，若使用反斜杠转义需注意额外处理反斜杠本身
• PostgreSQL：单引号'替换为双单引号''，也可使用美元引号包裹变量，但纯字符串拼接场景下优先用双单引号转义

注意：字符串转义是参数化查询不可用时的替代方案，无法做到100%安全（比如不同数据库的特殊字符规则差异），如果有机会升级执行服务支持参数化查询，这才是最安全的方案。

内容的提问来源于stack exchange，提问作者RHarris