在SQL存储过程中如何编写动态SQL语句并防止注入攻击？

必须用 sp_executesql 防注入，EXEC 无法隔离代码与数据；动态对象名需校验系统视图+白名单；参数须强类型+前置校验；隐性字符串拼接点（如 CONTEXT_INFO、OPENROWSET）同样高危。

必须用 sp_executesql，不能用 EXEC —— 后者根本没法防注入，哪怕参数看起来“干净”。

为什么 EXEC 是硬伤，sp_executesql 才是唯一出路

SQL Server 对 EXEC 的处理方式是：把整个字符串当命令直接编译执行。用户输入一旦混进字符串里，就等于给了攻击者一把数据库钥匙。sp_executesql 则不同，它强制分离 SQL 模板和参数值，在编译阶段就切断数据与结构的耦合。

• 错误写法：EXEC('SELECT * FROM users WHERE id = ' + @id) —— 传入 @id = '1; DROP TABLE users; --' 就会删表
• 正确写法分三段：@sql 里只放模板（如 N'SELECT * FROM users WHERE status = @status'），第二个参数声明类型（如 N'@status TINYINT'），第三个参数绑定值（如 @status = 1）
• 漏掉任何一段都会失效：省略类型声明、不带 @param = value 格式、或在 @sql 里拼接变量，都等于没防

动态对象名（表名、列名、排序字段）怎么安全处理

SQL Server 不允许把表名、列名当参数传，所以 sp_executesql 对它们完全无效。硬拼就是高危点，QUOTENAME() 只防单引号，挡不住 ]; DROP TABLE x; -- 这类结尾注入。

• 必须查系统视图校验存在性和归属：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)
• 排序字段等走硬编码白名单：IF @sort_col NOT IN ('created_at', 'status', 'name') THROW 50000, 'Invalid sort column', 1
• 别用 OBJECT_ID(@table_name) 单独判断 —— 它不校验 schema，恶意输入可能被截断后误判

参数类型声明必须窄、强、带前置校验

用了 sp_executesql 不代表万事大吉。参数类型太宽或没约束，等于给绕过留门。

• 数字类用具体类型：@user_id INT，开头加硬范围检查：IF @user_id < 1 OR @user_id > 999999 RETURN
• 字符串立即检查长度和内容：IF LEN(@name) = 0 OR LEN(@name) > 50 OR @name NOT LIKE '[a-zA-Z0-9_]%' RETURN
• 禁止在过程里做 CAST(@input AS NVARCHAR) 或 CONVERT —— 转换失败报错，成功转换后可能已失真

最容易被忽略的隐性拼接点在哪

这些地方往往藏得深、审查看不出，但一出问题就是高危漏洞：

• 用 CONTEXT_INFO 存用户 ID 后在触发器里拼 SQL
• 用 OPENROWSET 构造远程查询字符串
• 日志记录逻辑里把参数转成字符串再拼进 INSERT 语句

只要涉及“把变量转成字符串 + 拼到 SQL 里”，不管上下文多隐蔽，都得按动态 SQL 标准重新过一遍校验逻辑。