必须用 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 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 标准重新过一遍校验逻辑。
