使用存储过程为何仍无法完全避开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的代码。注入攻击不发生在语法层面，而发生在执行时字符串如何被落地处理。