把SQL语句封装进存储过程，一度被当作防范SQL注入的银弹。这种想法只对了一半：如果存储过程内部采用参数化方式处理输入，确实能杜绝注入；但如果开发者在过程体里拼接动态SQL字符串，用户输入依然会被数据库引擎当作命令解析，注入漏洞原封不动地被保留了下来。理解这一点，是做好数据库层安全防护的前提。
存储过程防注入的原理到底是什么
存储过程之所以能防注入，靠的不是存储过程这个形式本身，而是参数化查询机制。当应用程序调用存储过程并传入参数时，数据库引擎会把这些参数当作纯粹的数据值处理，而不会将其解析为SQL语法的一部分。即使用户输入了类似' OR '1'='1这样的恶意片段，它也只会被当作一个普通的字符串与字段值比较，永远不会改变SQL语句的执行逻辑。
下面是一个安全的存储过程写法，查询条件完全通过参数传递：
CREATE PROCEDURE GetUserByName
@UserName NVARCHAR(50)
AS
BEGIN
-- 参数化查询，@UserName 只会被当作数据值处理
SELECT UserId, UserName, Email
FROM Users
WHERE UserName = @UserName;
END这个例子中，无论传入什么内容，WHERE子句的结构都是固定的。数据库在编译执行计划时就已经确定了语句的骨架，参数只是填充数据的占位符。这就是参数化的本质安全所在。但要注意，这种保护只存在于参数直接参与查询的场景，一旦过程内部开始拼接字符串，情况就完全不同了。
过程内部拼接动态SQL的典型漏洞
来看一个存在注入风险的存储过程，这种写法在实际项目中相当常见，尤其是在需要动态表名、动态排序字段的场景下：
CREATE PROCEDURE SearchOrders
@Keyword NVARCHAR(100),
@SortField NVARCHAR(50)
AS
BEGIN
DECLARE @sql NVARCHAR(MAX);
-- 危险写法：直接拼接用户输入
SET @sql = 'SELECT OrderId, Amount, CreatedAt FROM Orders
WHERE Remark LIKE ''%' + @Keyword + '%''
ORDER BY ' + @SortField;
EXEC (@sql);
END表面上看，外部调用是参数化的，似乎很安全。但过程内部用字符串拼接构造了新的SQL语句，再通过EXEC执行，此时用户输入重新回到了被解析的位置。攻击者传入'%; DROP TABLE Orders;--这样的内容，拼接出来的语句结构就被彻底篡改，注入攻击与没有存储过程时没有任何区别。
更隐蔽的问题在于动态排序字段。因为ORDER BY后面接的是列名而非数据值，无法直接参数化，很多开发者就直接拼接了事。攻击者完全可以传入CASE WHEN (SELECT COUNT(*) FROM AdminUsers)>0 THEN Amount ELSE Price END这类内容，通过观察排序结果推断数据库中的敏感信息，这就是典型的盲注手法。整个过程在数据库层面静默完成，应用日志里可能只留下一次看似正常的查询记录。
安全写法：sp_executesql与QUOTENAME的正确组合
对于数据值类的动态拼接，标准做法是改用sp_executesql并显式声明参数类型：
CREATE PROCEDURE SearchOrders
@Keyword NVARCHAR(100),
@SortField NVARCHAR(50)
AS
BEGIN
DECLARE @sql NVARCHAR(MAX);
-- 数据值通过参数传递，安全
SET @sql = N'SELECT OrderId, Amount, CreatedAt FROM Orders
WHERE Remark LIKE @kw
ORDER BY ' + QUOTENAME(@SortField);
-- QUOTENAME 会将输入包裹为 [xxx]，阻隔特殊字符逃逸
EXEC sp_executesql @sql,
N'@kw NVARCHAR(102)',
@kw = N'%' + @Keyword + N'%';
END这个改造包含两个关键点。第一，LIKE条件中的用户输入改为参数@kw传递，通配符拼接发生在参数赋值阶段，不会影响语句结构。第二，无法参数化的排序字段使用QUOTENAME函数包裹，它会把输入转成形如[Amount]的带括号标识符，即使含有恶意字符也会被转义或直接报错，无法逃逸出标识符边界。
不过QUOTENAME并非万能，更稳妥的方案是配合白名单校验。对于表名、列名这类必须动态的标识符，先检查输入是否在允许的集合内，不在则直接拒绝：
IF @SortField NOT IN ('Amount', 'CreatedAt', 'OrderId')
BEGIN
RAISERROR('非法的排序字段', 16, 1);
RETURN;
END白名单的优点是逻辑清晰、不存在绕过空间，QUOTENAME则作为兜底防线。两者结合，动态标识符的安全问题基本可以封死。此外还要注意，sp_executesql相比EXEC还有一个附带好处：参数化的语句更容易被查询计划缓存复用，对性能也有正面作用。
如何排查现有存储过程中的注入隐患
对于已经上线的系统，可以通过检索过程定义文本快速定位风险点。以SQL Server为例，sys.sql_modules视图保存了所有模块的完整定义，配合模糊匹配即可筛选出包含EXEC调用的过程：
SELECT OBJECT_NAME(object_id) AS ProcName, definition FROM sys.sql_modules WHERE definition LIKE '%EXEC (%' OR definition LIKE '%EXEC(%' OR definition LIKE '%sp_executesql%';
筛出的过程需要逐个人工审查，重点关注三处信号：一是字符串拼接中出现了过程参数，二是声明了NVARCHAR变量用于存放SQL文本，三是存在动态表名、列名或排序字段。命中任何一条，都应该按照上文的方式改造。审查时不要只看单个语句，还要留意游标循环内部、异常处理分支里的动态执行，这些角落最容易被忽略。
除了技术改造，流程上也要建立约束：把存储过程纳入代码评审范围，明确禁止在过程内部拼接用户可控输入；在CI流程中加入静态扫描规则，对新增的动态SQL自动告警。安全防护从来不是单一措施能完成的，存储过程只是链条中的一环，只有每一环都按参数化的纪律来写，数据库层才能真正成为可靠的防线。