二次注入和宽字节编码是两种容易被忽视但危害极大的SQL注入漏洞。二次注入发生在数据首次存入数据库时未被正确处理，而在后续的查询中被“信任”地取出并执行，从而引发攻击。宽字节编码则常见于使用GBK、GB2312等双字节字符集的系统中，攻击者通过巧妙构造特殊字符（如“%df'”），利用数据库和程序对字符转换的差异，绕过常见的转义函数（如addslashes或mysql_real_escape_string），成功注入恶意SQL语句。要彻底防御，必须采用参数化查询（预编译语句）作为根本解决方案，并辅以全面的字符集统一与严格的输入验证。

二次注入：隐藏在数据库深处的“延时炸弹”

与直接攻击输入点的传统注入不同，二次注入更为隐蔽。其攻击流程通常分为两步：第一步，攻击者将包含恶意SQL片段的输入（例如，用户名中输入“admin'-- ”）提交给应用。如果应用仅对输入进行了转义或过滤后就存入数据库，那么这个恶意片段会以转义后的形式（如“admin\'-- ”）被原样保存。此时，数据库里的数据看起来是“安全”的。第二步，当应用在另一个逻辑中（如修改密码、查询信息）从数据库取出这个“受信任”的数据，并直接拼接到新的SQL语句中时，问题就爆发了。因为从数据库取出的字符串是转义前的原始形式（“admin'-- ”），当它被拼接进新SQL语句时，其中的单引号就会闭合原有查询，注释符“--”则会使后续条件失效，从而让攻击者能够以admin身份执行任意操作，比如修改其他用户的密码。

防御二次注入的核心策略

防御二次注入的关键在于彻底放弃“信任”任何来自外部和内部的数据。首先，最有效、最根本的方法是全程使用参数化查询（预编译语句）。无论是首次入库还是后续从库中取出数据再查询，所有变量都必须作为参数传递，确保数据永远被当作数据处理，而非SQL代码的一部分。其次，必须对所有输入进行严格的、上下文相关的验证和过滤，包括从数据库取出的数据在用于二次查询前。最后，实施最小权限原则，确保数据库连接账户仅拥有必要的最低权限，即使发生注入，其破坏力也有限。

// 错误的做法：从数据库取出数据后直接拼接
String username = getUserFromDB(id); // 假设取出的是 "admin'-- "
String sql = "UPDATE users SET password='" + newPassword + "' WHERE username='" + username + "'";
// 生成的SQL: UPDATE users SET password='newPass' WHERE username='admin'-- '
// "-- "之后的条件被注释，导致admin用户的密码被更改。

// 正确的做法：使用参数化查询（以Java PreparedStatement为例）
String username = getUserFromDB(id);
String sql = "UPDATE users SET password=? WHERE username=?";
PreparedStatement stmt = connection.prepareStatement(sql);
stmt.setString(1, newPassword);
stmt.setString(2, username); // 即使username是"admin'-- "，也会被安全地作为参数值处理
stmt.executeUpdate();

宽字节注入：字符编码不一致埋下的陷阱

宽字节注入主要影响使用GBK、BIG5等宽字节字符集（一个字符由两个字节表示）的PHP等语言环境。其根源在于数据库、连接层、应用程序三者的字符集设置不一致。以经典的“%df'”攻击为例：当应用使用addslashes或mysql_real_escape_string函数对输入的单引号（'）进行转义时，会在其前面加上反斜杠（\），变成“\'”（对应字符：%5C%27）。如果数据库连接使用GBK编码，而攻击者输入“%df'”（%df%27），经过转义函数会变成“%df%5c%27”。在GBK编码中，%df%5c恰好构成了一个合法的宽字节字符“運”（或其他字），这样，后面的%27（单引号）就被成功“释放”出来，闭合了SQL语句，导致注入成功。

彻底封堵宽字节编码漏洞

解决宽字节注入需要一套组合拳。首要且最有效的措施是统一字符集：将数据库、连接、应用前端的字符集全部设置为UTF-8。UTF-8是一种多字节但安全的编码，能从根本上避免宽字节拼接问题。在PHP中，应在建立数据库连接后立即执行“SET NAMES 'utf8'”或使用PDO的DSN参数设置字符集。其次，避免使用不安全的转义函数如addslashes，转而使用指定字符集的函数，如mysql_real_escape_string（需配合正确字符集连接）或更好的是，直接升级到支持参数化查询的MySQLi或PDO扩展。对于遗留系统，可以在转义函数后，对输入进行二次过滤，将“%df%5c”这类组合进行替换。

// 易受宽字节攻击的PHP代码示例（使用GBK字符集和addslashes）
$user = addslashes($_GET['user']); // 输入 %df' ， 转义后为 %df%5c%27
$sql = "SELECT * FROM users WHERE name='$user'";
// 实际查询： SELECT * FROM users WHERE name='運''
// 由于%df%5c被GBK解析为"運"，单引号逃逸，语法错误导致暴露信息或可进一步注入。

// 安全的做法：使用PDO与UTF-8字符集进行参数化查询
$pdo = new PDO('mysql:host=localhost;dbname=test;charset=utf8', 'user', 'pass');
$stmt = $pdo->prepare('SELECT * FROM users WHERE name = :name');
$stmt->execute([':name' => $_GET['user']]); // 输入被安全地作为参数处理

构建纵深防御体系：超越单一解决方案

仅依赖一种防御手段是危险的。一个健壮的系统应构建纵深防御体系。第一层是输入验证：在数据入口处进行严格的白名单验证，只允许符合预期格式（如邮箱格式、数字范围）的数据通过。第二层是使用参数化查询：这是防御所有类型SQL注入的基石，确保所有数据库操作都通过预编译语句完成。第三层是统一的字符集管理：强制使用UTF-8，并在代码、数据库配置、HTTP头中明确声明。第四层是最小权限原则和错误处理：数据库账户按需授权，避免使用高权限的root账户；同时，应用应关闭详细的数据库错误回显，使用自定义的错误页面，防止攻击者通过报错信息获取数据库结构。第五层是定期安全审计与漏洞扫描：使用自动化工具和手动代码审查，定期检查潜在的二次注入点和字符集问题。

总结：安全是一种思维习惯

防止SQL注入，尤其是二次注入和宽字节编码这类深层漏洞，远非配置一个函数或修复一行代码那么简单。它要求开发者和架构师将“不信任”原则内化为一种思维习惯。任何数据，无论来自用户输入、文件上传、第三方API还是自家数据库，在进入SQL命令执行流程前，都必须经过参数化查询的洗礼。同时，确保整个数据流通道（从浏览器到数据库存储层）字符集的一致与纯净，是消除编码类漏洞的前提。通过将根本性的参数化查询、严格的输入验证、统一的UTF-8环境以及深度防御策略相结合，才能从根本上瓦解SQL注入攻击的威胁，建立起牢固的应用安全防线。