本次代码审计使用了白加黑的手法，用黑盒的视角测试功能点，用白盒的方式作为验证。

0x1 XSS

guestbook处，可以看到有一个留言板

idea搜索guestbook。发现代码如下，其中的getModel是获取数据的方法。Guestbook.class就是具体要获取的数据。

跟进Guestbook.class查看，发现GuestBook继承自BaseGuestbook

继续跟进BaseGuestbook可以发现http请求的数据，没有发现有过滤函数。

然后使用管理员登录后台查看留言，发现确实如我所想，存在xss漏洞。

ps:审计小技巧，开启sql日志然后一边打payload一边看记事本是否漏掉过滤哪些字符。这里是完全没有过滤，所以在出库的时候如果没有防护，基本上就是实锤xss了。

0x2 SQL注入

在产品中心发现有一个搜索框

看到源码，没有发现有过滤字符，这里采用之前开启的mysql日志，通过日志文件的sql语句判断是否有过滤。

直接输入单引号发现该cms返回500报错，很有可能存在sql注入。

于是使用两个单引号''使得系统不抛出异常，然后查看日志文件中发现sql语句没有过滤单引号，说明注入确实存在。

or 1 结果

or 0结果 注入确实存在

0x3 文件下载

/common/down路由中的file方法，直接获取http请求中的filekey参数，并且没有过滤../等关键字符。fileKey的值和PathKit.getWebRootPath()函数的返回值拼接。然后fileKey其实就是http中的参数。

ps：该路由不在前台，只能通过白盒的方式去进行，但是后续通过github上的fuzz字典发现也可以fuzz得到但是fuzz发包数量巨大不作为参考。但是日后如果实在挖不出洞，可以考虑多fuzz一下，也许就出货了也说不准。这里用的字典较大，其实可以考虑小一些的字典，算是个人的一些挖洞经验吧。

参数的fuzz

0x4 csrf

在系统管理-> 系统用户 -> 添加用户处，抓包然后使用burp生成csrf poc

保存至html后，点击submit request

可以看到用户被成功添加了

0x5 组合拳+sql备份getshell未果（条件较为苛刻）

这里是想getshell来着，毕竟都白盒了，当然能getshell就getshell，不能getshell就想办法getshell了。这里是发现后台上传接口，过滤了jsp，jspx文件名。

发现公司管理->基础内容->公司信息有上传图片

上传jsp文件,jspx文件均被拦截。

然后发现系统管理->数据库管理处发现可以进行数据库备份还原操作。在数据库还原抓包，发现是一个sql文件名字。这里想到之前的任意文件下载，那么岂不是可以通过上传一个sql文件，然后通过备份这个sql文件进行数据库备份getshell。

首先去下载备份好的sql文件，路径在static/back/文件名

然后添加getshell的payload

然后上传该sql文件，注意需要改后缀名为png

然后sql备份处填写上文件名，使用../让系统跨目录读取png图片

然后查看payload上的1.jsp是否成功生成。

访问的时候失败了，无法解析jsp，jspx等文件，但是服务器确实有写入了jsp文件

得到了两个前置条件

1. 需要知道系统的绝对路径

2. 系统下得开启其他能够解析的应用（如另外一个java系统在其他端口上，但是能够解析jsp，就可以通过该cms的漏洞在其他系统上写webshell，也算是一个任意文件写入，做到了"隔山打牛"）

0x6 默认密码

一个比较容易忽略的点，通常admin的默认密码管理员基本都会在部署网站之后马上修改，但是如果类似有几个账户的情况下，管理员可能会忽略掉其他用户的默认密码。这里可以直接看sql文件。在其sql文件下发现有两个默认账号一个是admin，一个是read。

read登录成功

0x7 总结

本次代码审计强化学习了白+黑的方式，更加简单的找出了漏洞，有些地方还欠缺一些思路，比如0x5rce那一块，想着是不是可以写一个class文件达到rce的效果。或者覆盖掉原本的xml文件之类的操作，不允许上传jsp，jspx文件是否可以通过上传war包来进行getshell。总之觉得还有诸多不足，篇幅关系记录到这。