免责声明：

由于传播、利用本公众号所提供的信息而造成的任何直接或者间接的后果及损失，均由使用者本人负责，公众号及作者不为此承担任何责任，一旦造成后果请自行承担！如有侵权烦请告知，我们会立即删除并致歉。谢谢！

曲折的web打点

拿到目标后的首要任务就是打点，按照常规手段对目标的域名，子域名，目录，端口，ip，ip段进行信息收集，之后进行指纹识别，发现目标单位在互联网上的暴露的业务并不多，由于单位对外的http业务很少，也没有登录、注册接口，后来对25端口暴破了一些邮箱，也没有进展，马上要准备放弃web打点了，但是在一个子域名下的敏感目录发现不太对劲，我们立刻开始对这个前端js审计。

代码审计

拿到这个站点的部分源码，开始进行常规的java代码审计，通过对常见的RCE sink点进行定位，作者心中默念readobject，ProcessBuilder，Runtime，ScriptEngine，parseObject，MultipartFile，果然幸运女神降临，突然发现了在一处代码块里使用了InputStream类，并且这个方法的输入并没有设置过滤，貌似可控，任意文件读取！！！于是我们马上构建请求包验证漏洞。

日志分析

之后的思路是利用之前的文件读取漏洞，读取分析中间件的日志看下有没有一些敏感信息泄漏，这个中间件部署了不只这一个应用，还有一些其他应用的接口，把日志保存下来，用脚本自动化的去提取出这些接口，探测，有一个接口比较可疑。

文件上传白名单绕过getshell

发现一个疑似上传的接口，访问一下,是个遗留的上传图片的接口，感觉可以shell，先试了下上传一个正常的图片可以上传成功，测试之后发现使用了白名单机制，只允许JPEG、JPG、PNG、BMP等文件格式的，没有对文件头进行限制，能getshell的几率瞬间直线下滑，突然想起来之前的一种文件上传白名单绕过的思路，假如上传的代码没有加锁，这时候可以利用上传时候的代码执行的需要一定的时间，加大客户端请求时候的并发，造成文件上传时候条件竞争。准备好webshell，这个webshell的功能要能写一个大马到webapp根目录下，然后我们访问这个大马。先开两个intruder，然后请求上传的文件的并发开到100。

在经历了半个小时左右的404之后，发现了一个200,访问一下，果然可以了！之后就可以直接写jsp的webshell或者注入内存马。