SQL注入绕过过滤的宽字节与二次编码组合

宽字节注入与二次编码组合的本质，是攻击者利用字符集转换过程中的“吞字节”特性，绕过传统的addslashes或magic_quotes_gpc防御。当后端使用GBK等宽字节字符集，而数据库连接编码与前端不一致时，一个精心构造的%df%27就能让转义符号反斜杠被“吃掉”，从而暴露出单引号，打破SQL语句的闭合边界。这种攻击手法至今仍在各类CTF竞赛和实战渗透中频繁出现，因为它直击了编码转换这一底层逻辑漏洞。

要理解宽字节注入，必须先明白GBK编码的字节范围。GBK编码中，第一个字节（高字节）的范围是0x81-0xFE，第二个字节（低字节）的范围是0x40-0xFE。当PHP的addslashes函数处理一个单引号时，会在前面加上反斜杠（0x5c），变成%5c%27。如果攻击者在单引号前添加一个%df，传入的参数就变成了%df%27。经过addslashes处理后变成%df%5c%27。当MySQL使用GBK编码解析时，%df%5c正好落在GBK的合法范围内，被解析成一个汉字“運”，而后面的%27则作为独立的单引号被保留下来。这个单引号就成功逃逸了转义，可以直接闭合前面的SQL语句，从而注入恶意代码。

原始输入：1%df' 
经过addslashes：1%df%5c%27 
GBK解析：1運' 
结果：单引号成功逃逸

这种攻击成立需要三个条件：数据库连接编码设置为GBK或兼容GBK的字符集；使用了addslashes或类似的转义函数；参数在转义后才进行字符集转换。很多老旧的PHP项目使用mysql_query("SET NAMES 'gbk'")来设置连接编码，这恰恰触发了宽字节注入的条件。因为SET NAMES会同时改变客户端、连接和结果集的字符集，导致转义后的数据在传输到数据库时被重新解析。

二次编码注入比单纯的宽字节注入更加隐蔽。它的场景通常出现在数据经历了两次编码转换的过程中。最经典的案例是：用户输入先经过URL解码，然后经过addslashes转义，最后存入数据库时又经历了一次GBK编码解析。假设攻击者输入%25%32%37，第一次URL解码后变成%27，这是一个单引号的URL编码形式。如果应用程序又对它进行了一次解码，%27就会变成真正的单引号。但此时addslashes可能已经处理完毕，单引号就绕过了转义。

更复杂的组合是：攻击者输入%df%25%35%63。第一次URL解码后变成%df%5c，这恰好是宽字节“運”的编码。如果程序对这个结果再次进行URL解码，%df%5c会被当作普通字符处理，不会触发宽字节解析。但如果程序将第一次解码的结果直接拼接到SQL语句中，并且数据库连接是GBK编码，那么%df%5c就会被解析成汉字，如果后面跟着%27，单引号就会逃逸。这种多层解码的逻辑漏洞，在实际的Web应用中并不罕见，尤其是那些对参数进行多次编码处理的框架。

攻击者输入：%df%25%35%63%25%32%37
第一次URL解码：%df%5c%27
GBK解析：運'
结果：单引号逃逸，且绕过了某些只检查原始输入的WAF

二次编码的核心在于利用应用程序对参数进行多次解码的逻辑缺陷。很多开发者在获取参数时会习惯性地调用urldecode，而框架底层可能已经做了一次解码，这就造成了双重解码。攻击者通过精心构造多层编码的payload，可以绕过那些只在原始输入层面进行检测的防御机制。

当宽字节注入和二次编码组合在一起时，攻击的穿透力会大幅提升。典型的攻击链是这样的：应用程序从GET或POST参数中获取数据，底层框架自动进行了一次URL解码；然后业务代码中又手动调用了一次urldecode；接着数据被addslashes转义；最后在GBK编码的数据库连接中执行SQL查询。攻击者可以构造%25%64%66%25%32%37这样的输入。第一次解码后变成%64%66%27，第二次解码后变成df'。addslashes处理成df\'，即df%5c%27。进入GBK数据库后，%df%5c被解析成汉字，单引号逃逸。

这种组合攻击的威力在于，它能绕过那些只防御单一攻击向量的WAF规则。很多WAF会检测%df%27这样的宽字节特征，但对于%25%64%66%25%32%37这种多层编码的形式，由于看起来只是普通的百分号编码，很容易被忽略。攻击者还可以利用其他编码形式，比如HTML实体编码、Base64编码等，与宽字节注入结合，创造出更多样的绕过手法。

在实际渗透测试中，宽字节注入的利用需要根据具体情况调整payload。如果目标过滤了单引号，可以尝试使用宽字节闭合其他字符，比如双引号、反斜杠本身、或者注释符。GBK编码中，%df%5c是经典组合，但%81%5c、%a1%5c等同样有效。如果%df被过滤，可以尝试其他高字节范围的值，只要低字节是%5c即可。有些应用会过滤%5c，这时可以尝试寻找其他需要转义的字符，比如%bf%27也能形成宽字节组合。

对于二次编码的利用，关键是要摸清目标应用的数据处理流程。可以通过输入%25%33%36这种测试串来观察返回结果。如果返回的是%36，说明进行了一次解码；如果返回的是数字6，说明进行了两次解码。确定了处理流程后，就可以精确构造多层编码的payload。常见的编码组合包括：双重URL编码、URL编码与HTML实体编码混合、URL编码与Unicode编码混合等。每种组合都对应着特定的解码顺序和场景。

测试二次解码的探针：
输入：%25%33%36
一次解码：%36
二次解码：6
观察返回内容即可判断解码次数

在绕过WAF方面，宽字节与二次编码的组合提供了丰富的变形空间。可以将payload中的关键字符用多层编码包裹，比如将单引号编码为%25%32%37，将空格编码为%25%32%30，将等号编码为%25%33%64。还可以在编码之间插入无关的字符或注释，打乱WAF的正则匹配。例如，在%df和%27之间插入SQL注释//，变成%df///%27，如果WAF的规则不够严谨，就可能被绕过。另外，利用数据库的字符处理特性，比如MySQL会自动处理反斜杠转义，在某些场景下也能创造出新的绕过路径。

最彻底的防御方案是使用PDO或MySQLi的预处理语句，并将参数绑定与字符集设置完全分离。预处理语句将SQL逻辑与数据完全隔离，从根本上杜绝了注入的可能性。如果必须使用传统的mysql扩展，正确的做法是使用mysql_set_charset设置连接编码，而不是使用SET NAMES。mysql_set_charset会通知MySQL客户端库当前的字符集，使得mysql_real_escape_string能够正确地考虑字符集因素进行转义。

安全的连接设置示例：
$mysqli = new mysqli("localhost", "user", "password", "database");
$mysqli->set_charset("gbk");
// 后续使用预处理语句
$stmt = $mysqli->prepare("SELECT * FROM users WHERE id = ?");
$stmt->bind_param("i", $id);
$stmt->execute();

在代码层面，需要避免对用户输入进行多次解码。如果框架已经自动解码了参数，业务代码中就不应再次调用urldecode。对于确实需要进行编码转换的场景，应该使用白名单方式严格限制允许的字符集，并在每次转换后重新进行安全过滤。在WAF规则配置上，应该检测解码后的实际内容，而不是仅检查原始输入。可以设置递归解码检测机制，对参数进行多次解码直到不再变化，然后对最终结果进行恶意特征匹配。

从架构层面看，统一使用UTF-8字符集是避免宽字节注入的最有效方法。UTF-8编码不存在宽字节吞并的问题，因为它的多字节序列有严格的格式约束，不会将转义符反斜杠与前面的字节错误组合。如果业务必须使用GBK编码，那么数据库连接、表字段、PHP内部编码应该保持完全一致，避免任何编码转换环节。同时，在连接数据库后立即执行SET character_set_client=gbk, character_set_connection=gbk, character_set_results=gbk，确保整个数据流使用统一的字符集。

对于历史遗留系统，无法大规模修改字符集的情况下，可以在应用层增加一道过滤。具体做法是：在获取用户输入后，检查其中是否包含GBK编码中可能形成宽字节的高字节字符（0x81-0xFE）。如果检测到这类字节，可以强制对输入进行GBK编码验证，检查是否能正确解码。如果解码失败或解码后包含危险字符，则拒绝该请求。这种方法虽然不能完全杜绝攻击，但可以大幅提高攻击门槛。

安全测试人员可以通过构造特定的payload来检测目标是否存在宽字节注入。常用的检测探针包括：在参数后添加%df%27，观察页面是否报错或返回异常；添加%df%5c%27，检查是否出现宽字节解析特征；添加%25%64%66%25%32%37测试二次编码组合。如果页面返回了数据库错误信息，或者返回内容与正常请求有明显差异，就说明可能存在注入点。使用SQLMap等自动化工具时，可以指定--tamper参数使用chardoubleencode或charencode等脚本，模拟宽字节和二次编码的攻击向量。

在代码审计中，需要重点关注以下几个函数的使用：addslashes、mysql_real_escape_string、urldecode、iconv、mb_convert_encoding。检查这些函数的调用顺序和上下文，如果发现先转义后转换编码的模式，或者存在多次解码的逻辑，就应该标记为潜在风险点。同时检查数据库连接部分的代码，看是否使用了SET NAMES而非mysql_set_charset。对于使用GBK编码的项目，这些审计点尤其重要。

宽字节注入与二次编码组合攻击，本质上是利用字符集转换和多次解码的逻辑漏洞。防御这类攻击不能仅依靠单一的转义函数，而需要从编码架构、数据流处理、安全编码规范三个层面综合施策。使用UTF-8编码和预处理语句是最佳实践，可以一劳永逸地解决这类问题。对于无法立即迁移的GBK项目，必须严格规范编码转换流程，使用正确的字符集设置函数，并在每次解码后重新评估数据安全性。安全是一个持续对抗的过程，理解攻击原理才能构建真正有效的防御体系。