这篇文章将为大家详细讲解有关怎么利用文件上传功能构造实现针对后端验证机制的RCE漏洞，文章内容质量较高，因此小编分享给大家做个参考，希望大家阅读完这篇文章后对相关知识有一定的了解。

创新互联坚持“要么做到，要么别承诺”的工作理念，服务领域包括：成都网站设计、网站建设、企业官网、英文网站、手机端网站、网站推广等服务，满足客户于互联网时代的永仁网站设计、移动媒体设计的需求，帮助企业找到有效的互联网解决方案。努力成为您成熟可靠的网络建设合作伙伴！

针对身份验证功能的目标Web应用，对其文件上传功能点进行利用，绕过了其客户端校验方式，以Web应用后端文件核实人员为目标，构造上传了可执行Payload的文件，结合XSS Hunter实现了远程代码执行（RCE）。这种漏洞测试姿势算是常见，但怎么一个绕过招式就变成了高危的RCE了呢？下面一起来看看测试思路。

分析目标

在参与厂商的众测项目之前，我会先去了解该项目的一些运行数据信息，如赏金范围和项目持续时间等，如果你觉得这样毫无必要的话，那么盲目地参与可能会与一些好项目擦肩而过。我参与这个项目就是个例子，我大约于2019年5月收到测试邀请，该项目自2016年就运行至今，有效漏洞提交量总共150多个。但不管怎样，我还是对其做了一番了解。之后，我又从其在HackerOne上的项目更新中看到，有一些新的服务端被陆续添加进入测试范围，并在测试策略（Policy）中具体描述了厂商对哪些漏洞比较感兴趣。

经验1：漏洞总是有的。前期的测试目标可能和新增测试目标一样存在很多漏洞。

了解目标

从HackerOne上的项目更新策略中可知，厂商对第三方合作伙伴Web应用网站partner.program.com的某子域名站点存在的漏洞较为关注。访问该子域名网站后，我发现它是一个允许用户注册成为厂商合作伙伴或附属机构的Web应用。通常我喜欢关注Web应用的访问授权功能，一般我会在Web应用中注册至少两个账户以备测试。因为两个账户可以方便地进行越权（IDOR）测试。在注册登录之后，我发现了其中一个有意思的地方：身份验证文件上传。

这就是使用该Web应用的第一步。由于目标厂商是一家商贸公司，合作伙伴和用户需要通过上传他们的**/***等证明来通过身份验证，才能开始使用Web应用。终于遇到对手了，我非常喜欢捣鼓文件上传功能了。

经验2：不要忽视一些看似正常的功能。比如搜索栏位置可能会存在一些“致命”的XSS或SQL注入漏洞，而1337名白帽都会把它忽视。

漏洞发现

以前我曾发现过一些文件上传功能漏洞，总结来说：需要认真分析其具体的上传机制，比如其限制属性有什么、规定上传文件格式有哪些，等等，一般这些都是问题所在。由于这是一个身份验证证明的上传功能点，所以通常会存在两种证明文件验证机制：要么其后台有一个自动程序来验证用户上传的证明文件，要么其后端有一个实际的工作人员来通过用户上传证明文件核对用户身份。该上传功能如下：

上图显示，Web应用后端只接收PNG、JPG、PDF或BMP格式文件，因此，我尝试上传了一些非可接受格式文件，看看后端服务的反应如何。但很遗憾，后端服务完全没反应。即使从Burp的请求历史中，也没有发现任何文件限制响应消息或相应的请求记录，我有点懵了。只是，如果上传有效的JPG文件（foobar.jpg）后，会产生以下样式的上传请求：

这是什么意思？

这貌似表示其中还有一种客户端校验措施，如果用Burp来拦截上传请求然后改包，很容易绕过这种客户端检查。比如，我们拦截上传请求，然后把请求修改如下，其中上传的JPG文件名被修改为了foorbar.foo：

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

{"file_id":16xxxxx1}

这看似非常不错。但是我们上传的文件去了哪呢？回到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如 ">植入目标应用中待受害者点击，如果该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等系统基本信息。

关于怎么利用文件上传功能构造实现针对后端验证机制的RCE漏洞就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。

当前题目：怎么利用文件上传功能构造实现针对后端验证机制的RCE漏洞
转载来于：http://kswjz.com/article/pojohs.html