首发：先知社区 https://xz.aliyun.com/t/10198前段时间属实是有点整的太难了。这几天静下心来继续弄点简单的。就直接进行审计把。不说那么多，环境部署好了，开干。说一下我审计的前提准备。过滤器是一定要看的。当然才开始审计的时候可能会看的比较恼火，看不懂当我没说。简单的还是要看一下。涉及到一些函数处理的可以等到实际挖洞的时候再跟也行。然后就是cms的整个架构，哪个模块对应什么功能都是需要了解的比较透彻。涉及框架的，框架的漏洞涉及的组件要清楚，框架的配置文件再看看，就开冲。才开始代码审计，还是每个接口都看一下。老规矩。

注册流程分析（1）判断是否登录，登录以后就跳出注册页面
（2）判断是否验证码为空或者错误则返回并告知验证码出错（验证码为刷新可暴力破解用户名枚举）（3）邮箱格式判断（4）判断用户名，密码格式是否正确（5）判断邮箱用户id是否存在，存在就返回已存在。否则就进行注册（6）预编译进行sql插入。这样子分析下来，也只能做个用户名和注册邮箱枚举了，放两个个sql处理的关键的图，主要是看这里拼接出了预编译。

这种要养成习惯，这种权限相关的要做个笔记，万一有机会绕过呢。usertype=1是登录后台的权限设置。

文件重命名分析（1）判断文件是否存在
（2）判断新的路径的文件是否存在，不存在就创建（注意到这里我们的文件路径都是不可控的）(因为这里是先上传保存，再进行处理删除，所以说这里存在竞争，但是实际是利用不了的，后续可以看。)（3）获取源文件名。（未对源文件名做处理）（4）判断并截取了文件的后缀。{后缀名：fileExt 文件名originalFileName}（5）对文件名做了时间+随机数处理（6）重新生成了一个文件对象，并返回。

看一下这里 先创建了临时路径，然后再上传了我们的传入文件，此时还是没有改名的。也就是说如果我们可以访问，那么就存在竞争了。（当然前面也很体贴的帮我们看了能不能有写权限）(最后发现这个目录下如果访问jsp,jspx就直接404了)

保存的时候还是不出意外的做了预编译。跟到这里流程差不多了，但是我们好像没有发现对后缀进行了处理。试一试直接上传jsp

出现了问题,跟一下看看，是在 ((MultipartRequest)request).getFiles();未获取到。限制了jsp和jspx不能上传。

先看第一处，因为才开始顺手一点，发现这里确实是直接拼接的，但是因为获取的整数类型，传入payload类型不对所以直接报错了。（这里也要注意，不要看到直接拼接就下断定有。推荐一个工具 seay的mysql监控工具，可以看的很直观）

看一下模块这里，这里现在是继承者全村大半人的希望了，如果没有出东西，最后还是要去看看有没有注入啥的能不能getshell。这里的路径表面看起来是直接传的

所以这里不能做路径穿越穿出去，但是好像没有对路径做限制，只限制了不能读取config和几个路径。所以这里应该是有问题的。并且他默认是往根目录去读取。

尝试看看读取文件，说实话这里有点服气，只给了文件的信息，没有给内容。那也就是说没有太大的卵用。

然后高潮就来了，他这个模块的功能有点多。还能进行下载，重命名等。放在根目录，岂不是看到了希望的曙光，要是能读个数据库密码啥的也是不需此行，试一下。只能说不负众望。

payloadhttp://10.70.40.114:8080/xxx/admin/filemanager?mode=download&path=/web-inf/classes/conf/db.properties&config=filemanager.config.js不要急，一般这种造成的都会有连坐，比如任意文件删除（只限制再web目录）。（这里怕把系统整完了，就新建一个文件然后删除）

成功了。其他的替代这一种不是很想尝试，因为他限制了不能直接访问jsp,jspx也就是直接写马不行的。传配置文件的方式我们上传就能直接解决不需要这么麻烦。

系统都是一些配置编辑的功能，没有特别的新的。这次只出了一个文件读取和文件删除，能够读取数据库配置文件还是有一定的危害。因为还有sql哪些没有审计，所以说不一定拿不到通用shell（apache的话上传配置文件可以拿）。主要是审计思路的多多练习，和审计习惯的锻炼