为什么SQL Server中的动态拼接容易被注入_通过sp_executesql存储过程加固-SQL-PHP中文网

动态拼接sql字符串本身不安全，唯一真正防注入的方式是用sp_executesql参数化执行，且参数必须为纯值、禁止任何拼接；表名列名等结构需白名单校验，quotename()仅作最后转义。

为什么sql server中的动态拼接容易被注入_通过sp_executesql存储过程加固

动态拼接 SQL 字符串本身不安全，sp_executesql 不是“加固手段”，而是唯一能真正切断注入链路的执行方式——前提是不用它来拼接，只用它来参数化。

为什么 EXEC(@sql) 拼接字符串等于主动开门

只要把用户输入直接塞进 @sql 字符串里，无论加没加单引号、有没有 REPLACE(@input, '''', '''''')，都拦不住绕过。攻击者输入 admin''; DROP TABLE users--，拼出来就是合法语法的两条语句。

EXEC(@sql) 把整段字符串当 T-SQL 编译执行，数据库不区分哪部分是结构、哪部分是数据
引号转义只是文本替换，不是语义隔离；SQL Server 解析时早就不看“转义”这回事了
哪怕只拼一个 WHERE 条件，漏判 NULL 或空字符串，就可能让恶意片段逃逸到语句末尾

sp_executesql 的正确用法：参数必须是纯值，不能是拼出来的字符串

sp_executesql 防注入的前提，是它的参数列表（第二个参数）和值列表（第三个及之后）里，**不出现任何字符串拼接结果**。常见错误写法：N'@p1 nvarchar(50) = ''' + @user_input + ''' ' —— 这又回到拼接老路，@p1 声明本身就被污染了。

声明参数类型用静态 Unicode 字符串：N'@name nvarchar(100), @age int'
传参用变量原值：@name = @inputName, @age = @inputAge，不加引号、不拼 N 前缀
@stmt 里只出现 @name 这类占位符，绝不出现 ''' + @inputName + '''

示例正确写法：

DECLARE @sql NVARCHAR(MAX) = N'SELECT * FROM Users WHERE name = @name AND status = @status';<br>EXEC sp_executesql @sql,<br>  N'@name nvarchar(100), @status char(1)',<br>  @name = @inputName,<br>  @status = @inputStatus;

表名、列名、排序字段这些非参数内容怎么处理

参数化对标识符无效，@tablename 不能直接放进 FROM @tablename。这类内容必须走白名单或系统视图校验，QUOTENAME() 只是最后一步转义，不能替代前置判断。

先查 sys.tables 确认存在且属预期 schema：IF NOT EXISTS (SELECT 1 FROM sys.tables t JOIN sys.schemas s ON t.schema_id = s.schema_id WHERE s.name = 'dbo' AND t.name = @table_name)
禁止用 OBJECT_ID(@table_name) 单独判断——它不校验 schema，'malicious; DROP TABLE x--' 可能被截断后误判
白名单优先用 CASE WHEN @sort_col IN ('created_at', 'status') THEN @sort_col ELSE 'id' END，再套 QUOTENAME()
所有动态拼接点都要检查：ORDER BY、GROUP BY、临时表名、CONTEXT_INFO 读取后构造的 SQL、OPENROWSET 连接字符串