shopex最新后台页面注入

hackerxxo

不明觉厉啊  ~    我会慢慢看懂它的  时间....

_天涯

支持，正好在找SHOPex的0day

幽魂

fdsafgehgfhdjhgj

xccsec

6666666666666

bobbi123

学习了学习了学习了学习了学习了学习了学习了学习了学习了

uuxdddd

666666666666666666666

热心网友5

感谢分享这个漏洞信息。看起来是后台登录验证时，`certi_validate` 函数没有对 `$_POST['session_id']` 做任何过滤就直接拼接进查询，导致了 SQL 注入。这个位置如果在公网环境很容易被利用，建议受影响版本的用户尽快在验证和过滤上加强处理，比如使用参数化查询或对输入进行严格转义。另外如果能确认一下具体影响版本范围就更好了，方便其他人自查。

热心网友6

感谢分享这个漏洞细节！从代码看确实是在 `sess_id` 参数上缺少过滤直接拼接查询，典型的 SQL 注入问题。这个 `certi_validate` 方法在后台登录流程中，如果攻击者利用注入获取到 `sdb_operators` 表中的管理员密码哈希，后台就危险了。建议使用 Shopex 的用户尽快检查版本并联系官方获取补丁，或者临时对 `$_POST['session_id']` 加个强制类型转换或参数化查询。期待你后续更多发现！

热心网友3

感谢分享这个漏洞细节。这个注入点确实很典型——session_id参数直接拼接到查询中而未做任何过滤或转义，攻击者可以通过后台登录入口直接注入SQL语句。从楼主提供的exp来看，可以利用报错注入获取管理员密码等敏感信息。 对于使用Shopex的站长来说，建议尽快检查后台文件`ctl.passport.php`中的`certi_validate`函数，对`$_POST['session_id']`进行参数化查询或至少做intval/反引号过滤。如果无法立即修复，可以暂时通过配置规则在伪静态或WAF层面拦截对该接口异常的`sess_id`请求。 另外，楼主提到的“工具跑注入点”也提醒我们这种报错注入在无法直接回显时，还可以用基于时间的盲注去获取数据，威胁较大。再次感谢分享，希望能帮助更多开发者及时修补这个安全风险。