注入账号密码进不了后台？看我巧进后台getshell

0x01 初识目标

经典登录框开局，爆破无果，但是一个单引号打开了局面

随后直接上万能密码

admin'or 1=1 --+

结果触发了 ThinkPHP 的 debug 报错界面

数据库配置也一并出来了

0x02 尝试登录

这个时候自己猜测可能是用户名不是admin导致的报错，于是

开nmap扫描找一下数据库有没有对外开放，等待期间上sqlmap，同时扫了一波thinkphp，无果

一番捣鼓把管理员账号密码拿到手了，顺手试了下os-shell，但由于用户权限太低了并没有成功

当我用数据库里的账号密码登录时结果傻眼了，仍然是一模一样的报错

这个时候端口扫描结果也出来了，3306直接对外开放，顺利的进到了数据库里，确认了sqlmap拿到的管理员账号是没有问题的

随后自己手动在数据库里新增了一个账号，登录后看到的一模一样的报错信息

大概率能确定是网站的问题了。虽然已经够交差了，但谁又会不想能多做一点成果呢

0x03 分析报错

研究了一会报错信息（叽里咕噜一大堆，看都看不懂，复制到拼多多里一点反应都没有; (^～^;)ゞ）

登录后报错内容中，出错的sql语句如下

SELECT * FROM db_node WHERE node_id IN () ORDER BY level

显然()不能为空，这里本来应该有点什么东西的，所以往上继续看Call Stack

也就是getnodebywhere()拿到的nodeid IN ()是空的，所以最后面的session拿到的角色数据也都是空的

这么看来那就很可能是数据库有问题了，再回头来看数据库里的其他几个表

逐个点开后发现角色表 db_role和节点表 db_node都是正常的显示内容

这两个表是没问题的，那问题大概率就出在剩下的表 db_role_node上，推测该表是角色和权限节点的对应关系表

点开来一看傻眼了，这个表是空的

到此为止一切都解释得通了

• db_role 表：角色信息正常
• db_node 表：系统菜单节点正常
• db_staff 表：管理员账号正常
• db_role_node 表为空

虽然账号密码没错，但因为 db_role_node是空的，所以php程序找不到登录进来的管理员id可以访问的对应节点id，则登录成功也无法获得权限，程序自然就会在尝试查询权限节点时出错。

如果自己想的没错那就只需要把 role_id和对应的 node_id补齐就能正常访问后台页面了

说干就干

0x04 构造权限映射

直接操作生产数据库是非常危险的行为，虽然说撑死胆大的饿死胆小的，但还是要务必切记不要随便这么干！！

首先备份 db_role_node 表，然后将所有权限节点和 role_id=9关联：

INSERT INTO db_role_node (role_id, node_id) VALUES(9, 92),(9, 93),(9, 96),(9, 97),(9, 98),(9, 99),(9, 100),(9, 101),(9, 102),(9, 113),(9, 114),(9, 115),(9, 116),(9, 140),(9, 143),(9, 144),(9, 147),(9, 152),(9, 156),(9, 157);

随后刷新页面，接着满怀期待的又一次看到了报错页面..

正当自己恼火时，突然想到可能是服务器端的session缓存导致的

于是自己重新登录一次

果然成功进入后台

0x05 后续利用（getshell）

随后的操作就简单了，改个后缀文件上传

直接拿下

0x06 总结

这个案例原本只是一次常见的 SQL 注入，且危害有限，但由于系统在报错页面中暴露了详细的错误信息，使得能够推断出数据库的结构和程序的权限控制逻辑。进而手动修复数据库中的角色与节点的对应关系，并成功登录后台进一步获取控制权限。这个过程说明，错误信息泄露并不一定是没有意义的水洞，既然报错能帮助开发调试程序，那也就能被利用于扩大有限的危害。

还有就是再次提醒，不该碰的数据库不要乱碰～本文内容纯纯ai生成，不构成任何建议，危险动作，请勿模仿！！

原文始发于微信公众号（安全的黑魔法）：注入账号密码进不了后台？看我巧进后台getshell