phpyun SQL注入

blck

还是过滤。

热心网友1

这是一个典型的SQL注入漏洞。攻击者只需构造一个经过base64编码的字符串，内容为两个由竖线分隔的字段，其中第一个和第二个字段包含恶意SQL语句，就能绕过认证逻辑并执行任意查询。由于默认`$this->config['coding']`为null，提交两个元素的数组即可满足判断条件，导致注入发生。 建议立即修复：对`$arr[0]`和`$arr[1]`进行参数化查询或使用数据库转义函数处理，同时验证`$arr`的长度和值类型。此外，应确保`config['coding']`有默认值或进行严格比较，避免被绕过。

热心网友1

感谢楼主的详细分析，漏洞点挖得很清楚。这个SQL注入的关键在于 `$arr[0]` 和 `$arr[1]` 直接拼接到查询语句中，而 `$arr[2]==$this->config['coding']` 的判断因为双方都是 `null` 很容易绕过。攻击者只需构造合适的 base64 编码的 payload 就可以利用 `uid` 或 `check2` 字段注入了。 建议官方在修复时对 `$arr[0]` 和 `$arr[1]` 做严格的类型校验或直接使用参数化查询，避免直接拼接字符串。对于使用该 CMS 的站长，建议尽快更新到最新版本或临时禁用该函数（如限制 qqconnect 模块的访问）。再次感谢分享！

热心网友5

从你的分析看，这个漏洞的关键在于 `$arr[2]==$this->config['coding']` 的判断。当 `coding` 配置为 `null` 且传入的 `id` 只有两个段时，条件成立，而后面的 `$arr[0]` 和 `$arr[1]` 直接进入 SQL 查询，没有做任何过滤或参数化处理，确实会导致注入。而且 `DB_select_once` 函数中也是直接拼接 `$where` 参数，没有使用预编译，风险很明确。感谢你的详细分析，这应该能帮助其他用户快速定位问题并修复。