二次注入是指攻击者将构造好的恶意数据先提交并正常存入数据库，在后续业务逻辑从该数据库读取这些数据并拼接到新的SQL语句中执行时，才真正触发注入攻击。在SQL Server环境中，由于很多开发习惯把用户输入直接写入表字段，后续查询又使用字符串拼接，导致攻击面被悄悄放大。与一次注入相比，二次注入更隐蔽，因为第一次入库时数据看起来毫无危害。
二次注入在SQL Server中的形成原理
假设某系统的用户注册功能接收昵称并写入表Users，昵称字段本身没有做严格转义，仅在前端做了长度限制。攻击者提交昵称admin''--，系统将其作为普通文本存入数据库。此时数据安静地躺在表中，并不会造成任何破坏。问题在于，当后台管理员查询该用户详情时，程序使用拼接方式构造SQL：SELECT * FROM Users WHERE name=''' + @name + '''，读出的恶意值参与拼接后改变了原语句语义。
这种攻击的核心在于信任了“已经入库的数据”。很多团队认为数据既然过了一次校验就可以信任，但SQL Server不会区分数据来自外部输入还是内部存储。只要后续查询采用动态SQL拼接，且未对取值做参数化或转义，二次注入就必然存在。理解这一点，才能明白为什么防御必须前移到数据入库之前。
入库前严格转义过滤的实现方式
在SQL Server里，最稳妥的入库前处理是使用参数化命令，由ADO.NET或存储过程参数机制自动完成转义。但如果业务必须使用拼接，则应在写入前显式替换单引号为两个单引号，并剥离注释符。下面示例展示一个入库前过滤函数，在C#调用前对字符串做处理：
// 对即将写入SQL Server的字符串做二次注入防护
public static string SafeForSqlServer(string input)
{
if (string.IsNullOrEmpty(input))
return input;
// 单引号替换为两个单引号，阻止字符串提前闭合
string step1 = input.Replace("'", "''");
// 去除常见注释序列，降低后续拼接被截断风险
step1 = step1.Replace("--", string.Empty);
step1 = step1.Replace("/*", string.Empty).Replace("*/", string.Empty);
return step1;
}
// 调用示例：在插入前过滤
string nick = SafeForSqlServer(userInput);
string sql = "INSERT INTO Users(name) VALUES('" + nick + "')";
上面代码虽然做了基础转义，但仍有局限：它依赖开发者的手动调用，容易遗漏。更推荐的做法是在存储过程内部统一处理，利用SQL Server自身的QUOTENAME或REPLACE函数，在写入表之前强制规范化。这样无论上层怎么调用，数据落库形态都是安全的。
以下为SQL Server端的入库过滤示例，在存储过程中对入参先转义再插入，彻底隔离拼接风险：
CREATE PROCEDURE sp_SafeInsertUser
@rawName NVARCHAR(100)
AS
BEGIN
-- 入库前转义单引号，并去掉注释符
DECLARE @safeName NVARCHAR(100);
SET @safeName = REPLACE(@rawName, '''', '''''');
SET @safeName = REPLACE(@safeName, '--', '');
SET @safeName = REPLACE(@safeName, '/*', '');
SET @safeName = REPLACE(@safeName, '*/', '');
INSERT INTO Users(name) VALUES(@safeName);
END
参数化查询为何是更优解
严格转义过滤能解决大部分二次注入，但本质上仍属于“字符层防御”，一旦业务出现新语法结构就可能失效。SQL Server提供的参数化查询从协议层将代码与数据分离，从根本上消除拼接。下面展示使用SqlParameter的写法，数据无论包含什么字符都不会改变SQL语义：
using (SqlCommand cmd = new SqlCommand("INSERT INTO Users(name) VALUES(@name)", conn))
{
// 参数化后，恶意单引号仅作为数据，不会被解析为语句边界
cmd.Parameters.AddWithValue("@name", userInput);
cmd.ExecuteNonQuery();
}
参数化不仅防御二次注入，也提升执行计划缓存命中率。对于读取后再使用的场景，同样要用参数化读取，例如从表取昵称后查询订单，也应写成SELECT * FROM Orders WHERE owner=@owner并传参。只有写入和读取两侧都参数化，才能构建完整闭环。
校验层与入库层的职责划分
不少项目把防注入完全押在前端或接口层校验，这是二次注入频发的原因。前端校验可被绕过，接口层若只验格式不转义，数据入库仍是裸数据。正确分工是：接口层做业务格式校验，入库层做强制转义或参数化，两者互补。可以用统一的基础设施拦截所有写库操作，自动套用转义规则。
下表对比三种常见方案的适用性与维护成本：
| 方案 | 防御二次注入能力 | 维护成本 | 适用场景 |
|---|---|---|---|
| 手动转义函数 | 中，依赖调用规范 | 高，易遗漏 | 遗留拼接系统改造 |
| 存储过程内转义 | 较高，集中管控 | 中，需统一入口 | 多数内部系统 |
| 全链路参数化 | 高，结构性解决 | 低，框架原生支持 | 新项目与重构 |
从长期看，推动全链路参数化是性价比最高的路径。但在无法一步到位的现实里，至少保证数据入库前执行严格转义过滤，可把二次注入风险压到最低。开发团队应将此动作写入代码规范，并在代码评审中重点检查拼接写入点。
SQL_Server二次注入转义过滤修改时间：2026-08-04 15:03:39