为什么在SQL中使用存储过程依然无法完全避免注入风险

存储过程本身不防SQL注入，关键在于是否安全编写；若内部拼接用户输入（如EXEC(@sql)或CONCAT），仍会中招，必须使用参数化方式（如sp_executesql配合显式参数绑定）或静态SQL。

存储过程本身不免疫SQL注入

很多人误以为只要用了 CREATE PROCEDURE，就天然防注入——其实完全不是。存储过程只是把SQL逻辑封装起来，如果内部仍用字符串拼接构造动态查询，风险一点没少。关键看它怎么写，而不是它叫不叫“存储过程”。

动态拼接 EXEC(@sql) 是高危操作

在 SQL Server 中，EXEC(@sql) 或 sp_executesql @sql 如果参数来自用户输入且未经处理，就是典型的注入入口。哪怕整个逻辑都在存储过程里，只要最终执行的语句是拼出来的，攻击者就能塞进 UNION SELECT、WAITFOR DELAY 甚至 DROP TABLE。

• @sql 变量若由 username + ''' OR 1=1 --' 拼接而来，EXEC 会照单全收
• sp_executesql 本身支持参数化，但必须显式传参；如果只传一个拼好的字符串进去，等于白搭
• MySQL 的 PREPARE stmt FROM @sql + EXECUTE stmt 同理，拼接即危险

参数化 ≠ 存储过程自动参数化

存储过程的输入参数（如 @name NVARCHAR(50)）本身是安全的，但仅限于它们被直接用于 WHERE 条件等静态上下文。一旦你用这些参数去拼 @sql，再 EXEC，那参数就退化成普通字符串了。

正确做法是：用 sp_executesql 的参数绑定机制，把用户输入作为参数传进去，而不是拼进 SQL 字符串里。例如：

DECLARE @sql NVARCHAR(MAX) = 'SELECT * FROM users WHERE name = @name';EXEC sp_executesql @sql, N'@name NVARCHAR(50)', @name = @input;

这里 @input 是受控参数，不会被解析为代码。

权限控制和错误信息暴露会放大风险

即使存储过程里没拼接，如果它用的是高权限账号（比如 sa），或者开启详细错误（SET ARITHABORT ON 导致报错泄露表结构），攻击者就能靠盲注或错误型注入逐步探出数据。存储过程不自带最小权限，也不自动屏蔽错误细节。

• 数据库账号应只具备该存储过程所需的最低权限，比如仅 SELECT 某几张表
• 避免在生产环境返回原始 SQL 错误，尤其不能让 Msg 102 或表名字段名直接暴露给前端
• 日志中记录的是调用参数，不是拼出来的完整 SQL —— 否则等于帮攻击者留证据

真正容易被忽略的，是开发者常把“写了存储过程”当成安全结项标志，却没检查里面有没有一行 SET @sql = 'SELECT ... ' + @user_input。注入不发生在语法层面，而发生在执行时字符串如何落地。