环境搭建
漏洞审计
路由分析：
在index.php文件中包含 coreframe 框架下core.php文件并调用load_class加载
然后在application.class.php 文件、core.php 框架核心文件
调用了load_class加载类。然后通过load_class()类实例化wuzhi_application类
通过 load_class() 类实例化 WUZHI_application 类。
实例化 WUZHI_application 类调用下面构造方法
调用 WUZHI_application 类下 run() 方法获取路由信息
抓包查看他的路由访问规律
1.sql注入
漏洞路径/coreframe/app/member/admin/group.php
下的 del() 函数
在代码133行判断是否传入groupid参数且参数是否为空，条件满足在134行代码中判断传入的groupid是否为数组。
跟进delete()函数，在db.class.php中找到对应函数。
而下面223行的delete()函数才是真正去操作数据库的函数，我们跟进这个delete()
在这个过程中我们传入的sql语句并没有进行任何过滤就直接拼接到$sql并通过query()执行，所以这里存在SQL注入漏洞。
在query()函数中如果出现SQL语句错误会直接爆出SQL语句，所以这里存在报错注入。
漏洞复现：
2.任意文件写入
使用工具或者全局搜索file_put_contents函数
通过Seay的审计结果，翻找到一处可能存在任意文件写入的地方。
通过翻找发现一处可以直接控制 $data 的文件：
oreframe/app/attachment/admin/index.php
这里的 ueditor() 函数调用了 set_cache() 并且这里的 $GLOBALS['setting'] 参数可控。
假如不设置submit，则会通过 get_cache() 读取缓存文件内容。
漏洞复现：
通过前面路由分析以及上面SQL注入的路由，我们可以构造出调用ueditor()的路由：
/index.php?
m=attachment&f=index&v=ueditor&_su=wuzhicms&submit=XXX&setting=payload
文件已被成功写入到缓存文件中
读取缓存中文件内容
