直接拼接where条件字符串是高危操作，必须用sp_executesql配合占位符参数化处理；表名列名等标识符需白名单校验+quotename()兜底；所有入参须强类型声明并前置合法性检查。
直接拼接 WHERE 条件字符串就是高危操作
只要写 SET @sql = 'WHERE status = ''' + @status + '''' 这类语句，就等于把注入入口焊死在存储过程里。SQL Server 不会因为你用了 CREATE PROCEDURE 就自动隔离数据和代码——它只认最终执行的字符串。
常见错误现象：传入 @status = 'active'' OR 1=1 --'，拼出的条件变成 WHERE status = 'active' OR 1=1 --'，绕过全部业务逻辑。
- 所有动态 WHERE 字段值必须走参数化，不能拼进字符串
- 哪怕只拼一个值，也必须用
sp_executesql配合占位符，而不是EXEC - 数值型参数声明时别偷懒用
NVARCHAR(MAX)，要写成@id INT或@amount DECIMAL(10,2)
用 sp_executesql 实现安全条件拼接的硬性要求
sp_executesql 本身不防注入，只有满足三个条件才真正安全：SQL 模板硬编码、参数定义字符串显式声明类型长度、值绑定严格分离。
正确写法示例：
DECLARE @sql NVARCHAR(MAX) = N'SELECT * FROM orders WHERE 1=1';
IF @status IS NOT NULL
SET @sql = @sql + N' AND status = @s';
IF @min_amount IS NOT NULL
SET @sql = @sql + N' AND amount >= @a';
<p>EXEC sp_executesql
@sql,
N'@s TINYINT, @a DECIMAL(10,2)',
@s = @status,
@a = @min_amount;</p>
- 拼接部分只加条件骨架（
AND status = @s），不碰值 - 第二个参数
N'@s TINYINT, @a DECIMAL(10,2)'必须写全类型和精度，不能简写为@s SQL_VARIANT - 第三个及之后的参数必须用
@s = @status形式传值，不能只写@status
表名/列名/ORDER BY 这类标识符没法参数化，怎么办
SQL Server 确实不支持 SELECT * FROM @table_name，但 QUOTENAME() 不是万能解药——它只防单引号，挡不住 ]; DROP TABLE users;-- 这种结尾注入。
真正可行的做法只有白名单校验 + 显式映射：
- 先用
IF @sort_col NOT IN ('created_at', 'total', 'user_id') THROW 50000, 'Invalid sort column', 1 - 再用
SET @sql = @sql + N' ORDER BY ' + QUOTENAME(@sort_col) - 对动态表名同理：查
sys.tables或维护固定列表，禁止任何通配或模糊匹配 - 别信正则替换、
REPLACE(@input, '''', '''''')这类“转义”，绕过方式太多
容易被忽略的上游污染点
很多存储过程本身写得规范，但调用层传进来的 @status 已经是拼接过的结果——比如 Web 层把多个字段拼成 JSON 字符串再传给数据库，存储过程一拆包就中招。
- 检查所有入参是否经过中间件或 ORM 的二次处理（如 MyBatis 的
${}被误用） - 在存储过程开头加校验：
IF @status NOT IN (0,1,2) RETURN或IF LEN(@name) > 50 OR @name LIKE '%[^a-zA-Z0-9]%' RETURN - 数字类参数别依赖隐式转换，
@id NVARCHAR(20)接收后又CAST(@id AS INT)是典型陷阱——攻击者可传'1; WAITFOR DELAY ''0:0:5''; --'，CAST 前 SQL 已执行
最麻烦的不是语法怎么写，而是整个链路里任意一环把用户输入当代码使，整条防线就失效。
