PbootCMS V3.2.9前台SQL注入漏洞：绕过字符过滤的布尔盲注实战
1. PbootCMS V3.2.9漏洞背景
PbootCMS作为国内流行的企业建站系统，凭借其开源免费、模板标签简单易用的特点，被广泛应用于各类企业网站开发。最新统计显示，全网使用PbootCMS的网站超过34万个，其中V3.2.9版本存在一个高危的前台SQL注入漏洞。这个漏洞的特殊之处在于，系统虽然对用户输入进行了严格的字符过滤（仅允许中文、字母、数字等基础字符），但攻击者仍能通过特定手法实现数据窃取。
我在实际渗透测试中发现，很多使用该版本的系统都存在这个安全隐患。漏洞允许攻击者在无需登录的情况下，直接获取后台管理员账号等敏感信息。更值得警惕的是，这个漏洞其实是早期CVE-2021-28245漏洞的变种，官方在后续版本中并未彻底修复，导致新版本仍然受到影响。
2. 漏洞原理深度解析
2.1 漏洞触发点分析
漏洞的核心位于/apps/home/controller/SearchController.php文件中的parserSearchLabel方法。当系统处理搜索请求时，会通过request方法接收用户输入的参数。这里有个关键细节：当第二个参数为'vars'时，系统会启用严格过滤，只允许中文、字母、数字、横线、点、逗号、空格这些字符。
我通过代码调试发现，过滤后的参数最终会拼接到SQL查询的WHERE条件中。虽然系统对参数名($key)做了严格限制，但对参数值($value)的处理存在缺陷——当参数名是数字时，其值会被直接拼接到SQL语句中，这就为注入创造了条件。
2.2 字符过滤的绕过技巧
常规的SQL注入需要使用单引号、括号等特殊字符，但在这种严格过滤环境下，这些字符都被禁止了。经过多次测试，我发现可以通过MySQL的LIKE语句结合十六进制编码来突破限制。比如0x6125表示'a%'，这样既避免了使用单引号，又能实现模糊匹配。
这里有个技术细节：MySQL支持在LIKE语句中使用十六进制表示法，而SQLite不支持这个特性。因此这个漏洞利用方法仅适用于使用MySQL数据库的PbootCMS站点。对于默认的SQLite数据库，目前尚未找到有效的绕过方法。
3. 实战漏洞利用步骤
3.1 布尔盲注的实施
布尔盲注的核心是通过真假条件的不同响应来判断数据内容。在PbootCMS这个漏洞中，可以构造如下Payload：
1=select 1 from ay_user where username like 0x6125 limit 1这个Payload的意思是：如果用户表中存在用户名以'a'开头的记录，就返回正常搜索结果；否则返回无结果。通过反复测试不同字符，可以逐步猜解出完整用户名。
我在实际测试中发现，系统默认的管理员表名是ay_user，第一个用户通常是admin。因此可以先测试字母'a'，如果返回有效结果，再继续测试'd'，逐步拼出完整的用户名。
3.2 多用户数据的获取技巧
由于不能使用逗号，无法通过limit 1,1这样的方式获取第二个用户。但可以通过增加排除条件来实现：
1=select 1 from ay_user where username like 0x25 and username not like 0x61646d696e25 limit 1这个Payload的意思是：查找用户名不是admin的其他用户。通过这种方式可以枚举系统中的所有用户账号。
4. 防御建议与修复方案
4.1 临时防护措施
对于暂时无法升级的系统，建议在Web应用防火墙(WAF)中添加以下规则：
- 拦截包含
select from等SQL关键字的请求 - 过滤十六进制编码的特殊字符串
- 限制搜索接口的访问频率
4.2 彻底修复方案
官方应该从三个方面进行修复：
- 修改参数处理逻辑，对数字键名的参数值也进行严格过滤
- 使用预编译语句(Prepared Statement)替代直接SQL拼接
- 增加对十六进制编码的检测机制
对于使用者来说，最安全的做法是升级到最新版本，并定期检查官方安全公告。我在维护企业网站时，会特别关注这类开源项目的安全动态，建议其他管理员也建立类似的监控机制。
5. 漏洞利用的注意事项
在实际渗透测试中，有几点需要特别注意：
- 注入过程会产生大量日志记录，建议在授权测试时控制请求频率
- 不同版本的PbootCMS可能使用不同的表前缀，需要先确认
ay_user的实际表名 - 部分WAF可能会拦截连续的十六进制字符串，需要适当调整Payload结构
- 该漏洞利用成功率与数据库类型密切相关，MySQL环境成功率较高
我在一次客户授权测试中，就遇到了表前缀被修改的情况。通过先猜解表名再实施注入，最终成功获取了管理员凭证。这个案例再次证明，即使存在字符过滤，只要处理不当，仍然可能造成严重的安全问题。