记一次魔幻的上传之旅

        近日协助朋友在做审计一个门户。门户使用CI框架开发,所有的请求的带有CSRF-TOKEN,注入什么的也几乎没戏。好在这个每户还有一个会员系统,注册会员后可以上传头像。于是打开burp,发现数据包中有这样的内容: 

这个fileTypes看的人想入非非,把fileTypes改成 "*" ,直接上传php文件,获得webshell。

    对方效率也非常高,第二天就回报我们说漏洞已修复,让我们再复查一下。在经过了由于HSTS导致无法抓包,火狐无限崩溃n次之后,终于抓到了第一个数据包。


    可以看到数据包的大体结构并没有什么变化,只是在最后加了一个okCode参数,推测应该是类似CSRF-TOKEN的东西。再尝试用之前的方法修改fileTypes参数为 "*" ,会出现参数错误的报错,这个Code应该是对表单的内容做了校验。但是他既然是用来验证表单内容的,那应该就是由前端的javascript生成的,只要后端不修改,就应该还是可以进行上传操作。

    于是按照上面的思路,先去寻找负责生成Code代码。整个网站应该是用了双向绑定的框架,弄的我这个前端废半天都没找到对应的代码。破罐子破摔,一个一个文件看过去,终于找到生成code的相关代码。

        循环upHashParams.length次,先把upHashParams[j]的值拼接上一个冒号,然后再跟okCode进行拼接。这一步完成之后,判断upHashParams[j]的值是否为fileIndex,如果是就把_fileIndex跟","拼接,然后继续拼接到okCode上(_fileIndex在代码别的地方声明为0)。如果不是fileIndex,就通过internalObj.This[upHashParams[j]]来取出表单中的内容,按照上面的流程继续跟okCode拼接。最后通过windows.JSSHA256来生成最终的Code

    知道原理之后我们只需要照本宣科的再来一次就好了,反正就10个参数,我也懒得写脚本了,直接手动拼接一下,得到这样的结果。

    第一个Code是不是很眼熟?和之前数据包中的okCode一摸一样!这就证明这个方法没有错误了。紧接着就按照之前的方法,把  fileTypes:jpg|jpeg|png 改成 fileTypes:*,生成Code,将这个替换到数据包中,提交上传。


    由于网站是放在腾讯云上,上传php文件虽然会成功,但是会被秒删。所以就随便上传了一个html文件上去。


    后记:

            其实找js代码几乎花了半小时,实在是菜的抠脚啊。另外就是最后上传的时候,简直有种赌博的感觉,如果后端也加强了限制,那就gg了,前面的时间就都白费了,可以说是非常刺激了。

Last modification:September 1st, 2017 at 12:07 pm

Leave a Comment