数据库存储过程调用前的参数化传参防注入写法

调用存储过程时，很多人以为把输入参数直接拼接进SQL字符串就算完事，这恰恰是SQL注入攻击最喜欢钻的空子。即使业务逻辑封装在存储过程内部，参数传递这一层如果不做规范化处理，攻击者依然可以通过构造恶意参数值来篡改执行意图。问题的核心在于，调用方式决定了参数是以数据身份进入数据库引擎，还是以代码身份被解析执行。

最典型的错误写法就是把用户输入直接嵌入到调用语句中。比如在应用程序里拼接出这样一段命令：

string sql = "EXEC GetUserOrders '" + userId + "'";

这种写法下，userId 如果被传入 ''; DROP TABLE Orders; --，整个执行链就会断裂。数据库驱动会把这串内容当作完整的批处理指令提交，攻击者成功越过了存储过程本身的逻辑防线。问题不出在存储过程内部，而出在调用边界上。

参数化查询的核心机制是把SQL指令结构和数据值分离。数据库驱动在接收到参数化命令时，会先将SQL语句的骨架发送给数据库引擎进行编译，生成执行计划，然后再把参数值单独传递过去填充到占位符位置。这个过程中，参数值永远不会被当作SQL语法的一部分来解析，无论它包含什么样的特殊字符，都只是原始数据。

以SQL Server为例，正确的调用方式应该使用 SqlCommand 的参数集合：

using (SqlCommand cmd = new SqlCommand("GetUserOrders", connection))
{
    cmd.CommandType = CommandType.StoredProcedure;
    cmd.Parameters.Add("@UserId", SqlDbType.Int).Value = userId;
    // 其他参数...
    cmd.ExecuteReader();
}

这段代码里，存储过程名称和参数定义是分离的。@UserId 被明确声明为整型参数，数据库引擎在编译存储过程时就已经确定了它的数据类型和位置，传入的任何值都只能被当作整数处理。如果有人试图传入字符串或特殊字符，驱动层就会直接抛出类型转换异常，攻击载荷根本没有机会到达数据库引擎。

不同数据库系统对参数占位符的写法要求不一样，这一点在实际开发中经常被忽略。SQL Server使用 @参数名 的形式，命名参数清晰直观。Oracle在调用存储过程时通常使用冒号前缀，比如 :UserId，而且需要通过 OracleCommand 的参数绑定来传递。MySQL的存储过程调用同样支持 @参数名 的写法，但在使用某些连接器时，也可以用问号占位符按位置绑定。

PostgreSQL的函数调用场景中，如果使用 CALL 语句或者 SELECT function_name() 的方式，参数占位符通常写成 $1、$2 这样的位置编号。Npgsql驱动里可以这样写：

using (NpgsqlCommand cmd = new NpgsqlCommand("CALL update_inventory($1, $2)", conn))
{
    cmd.Parameters.AddWithValue("p1", productId);
    cmd.Parameters.AddWithValue("p2", quantity);
    cmd.ExecuteNonQuery();
}

关键点在于，无论占位符形式怎么变，参数值始终通过驱动层的参数集合传入，而不是拼接进SQL文本。这个原则是跨数据库通用的。

即使调用存储过程时使用了参数化方式，存储过程内部如果存在动态SQL拼接，仍然可能引发注入。很多开发者在存储过程内部用 sp_executesql 或者 EXECUTE 拼接字符串，然后把外部传入的参数直接嵌入到动态SQL里，这等于把防线从外部移到了内部，但漏洞依然存在。

正确的做法是在存储过程内部也使用参数化方式执行动态SQL。SQL Server的 sp_executesql 本身就支持参数化：

CREATE PROCEDURE SearchProducts
    @ProductName NVARCHAR(100)
AS
BEGIN
    DECLARE @sql NVARCHAR(MAX)
    SET @sql = N'SELECT * FROM Products WHERE ProductName LIKE @Name'
    
    EXEC sp_executesql @sql, N'@Name NVARCHAR(100)', @Name = @ProductName
END

这里外部传入的 @ProductName 先被存储过程接收，然后作为参数传递给内部的 sp_executesql，而不是直接拼接到 @sql 字符串里。这样即使参数值包含百分号、单引号或者SQL关键字，也只会被当作LIKE匹配的字符串处理。

MySQL存储过程中如果必须使用动态SQL，同样要利用 PREPARE 和 EXECUTE 的参数绑定能力：

CREATE PROCEDURE search_products(IN p_name VARCHAR(100))
BEGIN
    SET @sql = 'SELECT * FROM Products WHERE ProductName LIKE ?';
    PREPARE stmt FROM @sql;
    SET @name = CONCAT('%', p_name, '%');
    EXECUTE stmt USING @name;
    DEALLOCATE PREPARE stmt;
END

USING子句把变量值绑定到占位符上，保证了动态SQL的执行也不会把参数当作代码解析。

参数化防注入的效果很大程度上取决于参数类型的精确程度。如果为了方便把所有参数都定义成字符串类型，然后在存储过程内部做隐式转换，这会削弱防御能力。攻击者可能利用类型转换过程中的边界条件来构造特殊输入。

比如一个预期接收整数的参数，如果定义成了 NVARCHAR，那么传入 '1 OR 1=1' 这样的字符串就不会在驱动层被拦截，进入存储过程后如果参与了动态SQL拼接，风险就回来了。所以参数类型应该尽可能精确：整数用 SqlDbType.Int，日期用 SqlDbType.DateTime，布尔用 SqlDbType.Bit，字符串要指定最大长度。

cmd.Parameters.Add("@OrderId", SqlDbType.Int).Value = orderId;
cmd.Parameters.Add("@OrderDate", SqlDbType.Date).Value = orderDate;
cmd.Parameters.Add("@IsActive", SqlDbType.Bit).Value = isActive;
cmd.Parameters.Add("@Description", SqlDbType.NVarChar, 500).Value = description;

这种严格类型定义让数据库驱动在参数传递之前就进行类型校验，非法的数据格式在应用层就被拦截，不会进入数据库执行上下文。

现代开发中大量使用ORM框架，很多人以为用了Entity Framework或MyBatis就自动免疫注入了，实际上如果写法不当，ORM同样可能产生拼接漏洞。

Entity Framework中调用存储过程时，如果使用 FromSqlRaw 或者 ExecuteSqlRaw 并手动拼接字符串，就会绕过参数化保护。正确的做法是使用 FromSqlInterpolated 或者带参数的重载：

// 错误写法
var orders = context.Orders
    .FromSqlRaw("EXEC GetUserOrders " + userId)
    .ToList();

// 正确写法
var orders = context.Orders
    .FromSqlInterpolated($"EXEC GetUserOrders {userId}")
    .ToList();

FromSqlInterpolated 会把插值字符串自动转换为参数化命令，userId 被当作 SqlParameter 处理。MyBatis中，存储过程调用要在映射文件里使用 #{参数名} 的语法，而不是 ${参数名}，后者会直接进行字符串替换，存在注入风险。

在分层架构中，参数从表示层传递到数据访问层，每一层都可能对参数值做处理。如果某一层对参数进行了额外的转义或编码，反而可能破坏参数化的效果。常见的一个错误是在业务逻辑层对字符串参数手动添加单引号转义，然后再传给数据访问层，结果参数值里多出了反斜杠或重复的单引号，既破坏了数据完整性，又可能产生新的注入路径。

正确的做法是保持参数值的原始性，让数据访问层统一通过参数化方式处理。表示层只负责输入验证，比如检查邮箱格式、数字范围、字符串长度等，但不做任何SQL相关的转义。业务逻辑层处理业务规则，数据访问层严格使用参数化命令。这样职责清晰，不会出现多层转义导致的混乱。

除了安全层面的收益，参数化调用在性能上也有显著优势。数据库引擎在执行参数化命令时，如果SQL语句骨架相同而只是参数值不同，可以重用之前编译好的执行计划，减少硬解析的开销。对于高并发场景下频繁调用的存储过程，这个缓存机制能大幅降低CPU消耗。

相比之下，字符串拼接方式每次生成的SQL文本都不同，数据库引擎需要重新解析和编译，执行计划缓存命中率极低。所以参数化不仅是安全实践，也是性能优化的基础手段。

误区一：存储过程内部没有动态SQL，所以调用时拼接参数也没关系。实际上调用语句本身如果拼接，攻击者可以在调用层面注入额外的SQL命令，比如闭合字符串后追加 ;EXEC xp_cmdshell '...'。

误区二：对参数值做了HTML编码或URL编码后再传入，以为这样能防注入。编码后的内容在数据库里只是普通字符串，但如果存储过程内部对这些内容做了解码或动态执行，风险依然存在。而且编码会改变数据的原始形态，影响业务逻辑。

误区三：只对字符串参数做参数化，数字和日期参数直接拼接。数字和日期参数如果拼接，攻击者同样可以构造出改变SQL语义的输入，比如在数字后面追加 ; DELETE FROM...。

日常开发中可以对照以下检查项：所有存储过程调用是否都使用了参数化命令；参数类型是否精确匹配数据库字段类型；存储过程内部是否存在字符串拼接的动态SQL，如果有是否也使用了参数化执行；ORM调用是否避免了字符串拼接的原始SQL方法；代码审查时是否把参数传递方式作为安全检查点。

参数化传参不是可选的优化项，而是数据库交互的安全基线。把这条基线守住了，SQL注入攻击在调用存储过程这个环节就找不到突破口。