某景人力系统文件上传分析

admin

138635
文章

114
评论

2024年11月21日10:39:17评论13 views字数 2083阅读6分56秒阅读模式

某景人力系统

文件上传分析

起因是微信上刷到了如下文章，作为为数不多看过源码的系统，好奇心瞬间拉满，去年也发过一篇关于这个系统的文章，但都是些价值不大的漏洞，详情见公众号之前的文章《鸡肋文件上传到RCE》，所以抱着学习的心态想研究研究：

点进去看了下，三个步骤，先调用了个接口获取cookie：

再调用个接口获取物理路径，可以发现这里获取到的物理路径有些符号经过了编码，同时这里码没打全，框起来的物理路径下面有个接口sys/cms/uploadLogo.do，很明显就是上传接口了：

最后调用上传接口上传文件，值得注意的是这里上传的文件名是直接拼接在物理路径后的，其实观察上下两个请求包，虽然打了马，但大概率就是一个请求包，也就是说sys/cms/uploadLogo.do即是上传接口也是获取物理路径的接口：

上面都是基于猜测从打了码的图中获取到的信息，下面就利用这些信息分析一下，首先是获取cookie的接口，这里再仔细看下服务端返回的信息，就是一个html页面，而在接口都有鉴权的情况下，大概率就是一个jsp文件：

所以直接全局搜下html页面里加载的js文件就行了，可搜到如下文件：

module/system/qrcard/mobilewrite/qrcardmain.jsp

看一下前面的代码，实例化了一个用户名为“二维码进入”的userView，然后set了一些属性，包括从请求中获取tab_id参数，这些都不太重要，最关键的是在最后设置其session的islogon为true，很明显就是使其session生效：

所以直接访问该jsp文件就能获取到一个有效的cookie：

然后可使用获取到的cookie成功访问上传接口，同时可以从服务端返回中找到系统的物理路径：

接着就是分析下上传接口了，直接全局搜uploadlogo，可以找到对应的类，注意这里的b_upload，请求时需要带上才能进入上传流程：

找到如下类，流程很简单，先获取type参数，这里type传不传都行，接着从请求体里获取logofile、twoFile、oneFIle三个上传的文件，然后获取path参数，调用SafeCode.decode对path解码，在之前那篇文章也讲过，简单说编码就是URL编码后把%替换成了～，解码反之，然后三个if语句分别调用uploadFile上传文件，传入的参数分别是请求包中的文件体和解码后的path，这里三个上传都完全相同，所以利用时传入三个中的一个即可：

com.hjsj.hrms.transaction.sys.cms.UploadLogoTrans

继续跟进uploadFile，实例化一个File对象后就直接写入内容了，这里实例化时传入了绝对路径path和请求体里上传的文件名filename，其实可以发现这里全程没有对上传文件的类型进行限制，那之前看到的那个payload里为什么要多此一举的把文件名拼在path后面呢：

其实是因为这里有个全局的servlet，会对所有的*.do的请求进行处理，可以在web.xml找到对应的配置：

对应的类中可以找到对上传文件进行的处理，先是获取上传文件的文件名filename赋值给str，如果str不为空，就进行四个判断，也就是四个校验，先是文件名里不允许有~/和../，接着就截取文件名中的后缀进行判断，不允许后缀为空，然后检验文件内容和后缀是否匹配，这里是设置好了常用文件的前几个字节进行比对校验，最后就是判断后缀名是否在白名单里，看到这里就知道无法绕过白名单了：

com.hrms.struts.action.MainServlet