防止SQL注入的字符编码转换与宽字节注入防御

SQL注入是Web安全领域最经典、最顽固的攻击方式之一，而宽字节注入则是其中一种利用字符编码差异绕过过滤机制的高级手法。核心问题在于：当Web应用使用GBK等多字节编码时，攻击者可以通过构造特殊的字节序列，让过滤函数"吃掉"转义符的前半部分，从而让后半部分的单引号逃逸出来，最终拼接成恶意SQL语句。防御的根本思路不是简单地做字符替换，而是要从编码统一、参数化查询、过滤逻辑三个层面同时下手，才能真正堵住这个漏洞。

一、宽字节注入到底是怎么回事

要理解宽字节注入，先得搞清楚单字节编码和多字节编码的区别。UTF-8是变长编码，一个字符可能占1到4个字节；而GBK是双字节编码，一个汉字固定占2个字节，第一个字节的范围是0x81到0xFE，第二个字节是0x40到0xFE（不含0x7F）。攻击者正是利用了这个特性。

举个具体的例子。假设你的PHP代码用addslashes()对用户输入做了转义：

$username = addslashes($_GET['username']);
$sql = "SELECT * FROM users WHERE name = '$username'";

正常情况下，用户输入一个单引号'会被转义成\'，SQL语句安全。但如果数据库连接使用的是GBK编码，攻击者输入的是%df%27（%df是GBK中一个合法的首字节，%27是单引号的URL编码），addslashes会在%df前面加一个反斜杠变成%df%5c%27。这时候%df%5c在GBK里会被解析成一个汉字，而%27（单引号）就"裸奔"了，直接逃逸出来执行注入。

二、字符编码转换为什么会引入风险

很多开发者在处理用户输入时，会做编码转换操作，比如从UTF-8转成GBK，或者从ISO-8859-1转成UTF-8。问题在于，如果转换函数本身不够严格，或者转换过程中没有校验字节序列的合法性，就会给攻击者留下操作空间。

常见的风险场景有三种。第一种是使用iconv()函数做转换时，如果目标编码不支持某些字节序列，iconv可能会静默截断或者产生意外结果。第二种是在Java中使用new String(bytes, charset)构造字符串时，如果bytes数组里包含非法的多字节序列，可能触发异常或者产生乱码，进而影响后续的安全判断。第三种是数据库连接层的编码设置不一致，比如PHP的mysql_set_charset('gbk')和实际表的编码不匹配，导致过滤和执行之间出现编码差异。

具体来说，如果你的过滤逻辑在UTF-8环境下执行，而数据库连接却是GBK，那么你过滤掉的字符在GBK环境下可能根本不是同一个字符，过滤形同虚设。

三、防御宽字节注入的核心方法

防御宽字节注入，不能只靠单一手段，需要多层防护。下面从编码层、过滤层、查询层三个维度详细讲。

1. 统一并锁定字符编码

这是最基础也是最重要的一步。确保从客户端到数据库的整条链路使用同一种编码，推荐统一使用UTF-8（更准确说是UTF-8mb4，支持完整的Unicode）。在PHP中，连接数据库后立即执行：

mysqli_set_charset($conn, 'utf8mb4');

在Java中，JDBC连接字符串要明确指定：

jdbc:mysql://host:3306/db?useUnicode=true&characterEncoding=utf8mb4

在Python的pymysql中：

connection = pymysql.connect(host='localhost', charset='utf8mb4')

编码统一之后，宽字节注入的前提条件就不存在了，因为UTF-8的多字节序列有严格的格式规范，不会出现GBK那种"首字节范围很宽"的情况。

2. 使用参数化查询彻底杜绝注入

参数化查询（Prepared Statement）是防御所有SQL注入的终极方案，包括宽字节注入。它的原理是把SQL语句的结构和数据完全分开，数据库引擎在编译阶段就确定了语句结构，用户输入的任何内容都只会被当作纯数据处理，不会被解析为SQL语法。

PHP PDO示例：

$stmt = $pdo->prepare("SELECT * FROM users WHERE name = :name");
$stmt->execute([':name' => $username]);

Java PreparedStatement示例：

PreparedStatement ps = conn.prepareStatement("SELECT * FROM users WHERE name = ?");
ps.setString(1, username);
ResultSet rs = ps.executeQuery();

Python示例：

cursor.execute("SELECT * FROM users WHERE name = %s", (username,))

只要你全程使用参数化查询，不管攻击者怎么折腾编码，都不可能注入成功。这是最推荐的做法，没有之一。

3. 如果必须拼接SQL，做严格的白名单过滤

有些场景下不得不拼接SQL（比如动态表名、动态排序字段），这时候不能用参数化查询，就需要做白名单过滤。注意，是白名单，不是黑名单。黑名单永远有被绕过的可能。

比如动态表名：

$allowed_tables = ['users', 'orders', 'products'];
if (!in_array($table, $allowed_tables)) {
    die('非法表名');
}
$sql = "SELECT * FROM $table";

比如动态排序字段：

$allowed_columns = ['id', 'name', 'created_at'];
$direction = $dir === 'desc' ? 'DESC' : 'ASC';
if (!in_array($column, $allowed_columns)) {
    die('非法字段');
}
$sql = "SELECT * FROM users ORDER BY $column $direction";

白名单的核心思想是：只允许你明确知道安全的值通过，其他一切拒绝。这比任何正则过滤都可靠。

四、编码转换时的安全实践

如果业务确实需要做编码转换（比如对接老系统、处理文件导入等），必须遵循以下安全规范。

第一，转换前校验源数据的字节合法性。不要直接把任意字节数组丢给转换函数。在PHP中，可以用mb_check_encoding()先验证：

if (!mb_check_encoding($input, 'UTF-8')) {
    die('输入编码不合法');
}
$converted = mb_convert_encoding($input, 'GBK', 'UTF-8');

第二，使用安全的转换模式。iconv函数支持//IGNORE和//TRANSLIT模式，但这些模式会静默处理错误，在安全场景下不推荐使用。应该使用严格模式，遇到非法序列直接报错：

$result = iconv('UTF-8', 'GBK//TRANSLIT', $input);
// 或者更严格的
$result = iconv('UTF-8', 'GBK', $input); // 非法序列会返回false

第三，转换完成后再次校验结果。确保转换后的数据在目标编码下是合法的，没有产生意外的控制字符或者特殊字节。

第四，永远不要信任用户指定的目标编码。如果用户可以选择"导出为GBK"或者"导出为Shift_JIS"，你必须在服务端做白名单校验，只允许特定的编码值，而不是把用户的输入直接传给转换函数。

五、容易被忽视的其他编码相关注入

除了经典的GBK宽字节注入，还有几种编码相关的攻击方式值得注意。

一是UTF-7编码注入。UTF-7是一种用ASCII字符表示Unicode的编码方式，用+和-作为切换符。某些邮件系统和旧版IE浏览器会自动解析UTF-7，如果你的过滤没有处理UTF-7，攻击者可以用+ADw-script+AD4-alert(1)+ADw-/script+AD4-这样的方式绕过过滤执行XSS或者SQL注入。

二是二次编码注入。攻击者先对 payload 做URL编码，再做Unicode编码，再做Hex编码，层层套娃。如果你的过滤只做了一层解码，多层编码就能绕过去。防御方法是递归解码直到没有变化为止，或者直接用白名单。

三是同形字攻击。比如用全角字符代替半角单引号，或者用看起来像字母a的西里尔字母а。这种不算严格意义上的编码注入，但在字符处理不当的系统里同样能造成问题。解决办法是在过滤前做NFKC标准化：

$normalized = Normalizer::normalize($input, Normalizer::FORM_KC);

六、实战中的综合防御策略

在真实的生产环境中，防御SQL注入和编码攻击需要一套完整的策略，而不是某一个单一技巧。

首先，架构层面：数据库连接统一UTF-8mb4，应用层统一UTF-8，HTTP层声明charset=utf-8。三层编码一致，从根本上消除编码差异带来的风险。

其次，代码层面：所有数据库操作用参数化查询，动态部分用白名单，绝不用addslashes或者mysql_real_escape_string作为唯一防线。这两个函数在特定编码下都有被绕过的历史。

再次，输入验证层面：对所有用户输入做类型校验（数字就强制转int，布尔就强制转bool），对字符串做长度限制和字符白名单校验。不要相信任何"特殊字符过滤"能解决所有问题。

最后，监控层面：开启数据库的慢查询日志和错误日志，部署WAF（Web应用防火墙）做规则检测，对异常的SQL模式（比如大量出现%df、0xbf等字节）做告警。编码注入虽然隐蔽，但在流量层面往往有迹可循。

七、总结

宽字节注入本质上是编码不一致和过滤不严格共同造成的漏洞。防御它不需要多么复杂的技术，关键在于三点：编码统一用UTF-8mb4、查询全部参数化、动态内容白名单。把这三点做到位，不管是GBK宽字节、UTF-7还是任何编码变体的注入，都没有生存空间。安全不是靠某一个函数解决的，而是靠体系化的防御思维。

防止SQL注入的字符编码转换与宽字节注入防御

服务指南

帮助中心