写在前面
泛微OA sql注入，群里world师傅今天分析的文章，学习一下。
漏洞分析
首先在idea打开ecology这个文件，我们这里把漏洞分析分为4个部分，因为这个漏洞是未授权导致的sql注入
1.漏洞本身的sql注入部分2.未授权产生的部分3.漏洞本身的官方补丁修补部分4.未授权的官方补丁修补部分
第一部分我们这里先来看漏洞，根据在网上看到的文章，可以初步判定漏洞的存在位置在 ecology/mobile/plugin/browser.jsp 文件下面的keyword参数。首先我们来看一下这个文件
打开文件就可以看到 这里的keyword参数是直接用的request.getparmeter方法获取的参数
可以获取get或者post的传参，然后我们接着往下看
这两段代码就是对keyword传参的参数进行空值换成加号（+）
然后中间是对keyword进行了一次url解码
然后往下看就可以看到这段代码，我们来看一下 这段代码则是把isDIS参数跟1进行比较 而isDis参数则是直接通过get或者post传参进行获取（潜台词 我们能控制）。下面则是如果isDis参数等于1则不进入下面的if里面如果不等于1则进入if，然后这里if里面的getrequestdispatcher方法百度一下
这里通过里面的路径和百度到的内容，大致可以判定就是把这个请求跳转到dialog.jsp文件里面，我们打开看一下
这里面就这一段Java代码，下面有个if判定，如果user等于空，则返回空。我们跟进一下 getuser方法
这里进行就是一堆看不懂的代码，但是这个方法的返回值是一个user，应该是判定用户的，那我们就换种方式验证，直接尝试看看
传入0是这样的 至于为什么这里路径是这个访问，我后面会说
传1则是这样的，这跟网传的poc显示的差不多，那这里应该则是传入1不进入if
这里则是有个getuser方法也是在刚刚那个文件里的，但是这里他没有if判定是否，只是单纯的调用，所以我们不管，然后下面则是new了一个类，通过这个类设置了keyword值
注意上面的new里面传入了其他的参数，我们来看看这几个参数哪里来的
这里可以看到除了user是上面调用静态方法获取的，其他的值则都是直接通过get或post获取的
这些if判定没啥用，没有修改keyword的操作，也没有return的操作，我们不管接着往下看
来到下面，在一堆的set方法里面看到有一个get方法，我们进去看一下，这个braction则是上面new的类，而且还传入了keyword的值
一搜索有这么多，这里我们选择在mobile里面的，因为browser.jsp文件也在mobile里面
找到了对应的方法，这里则是很多if else这里则是通过我们传入的browserTypeId判定，我们来依次看一下这些方法，最终看到在等于269的时候调用的方法处存在一个注入
而这里的if判定的isNotEmpty方法
百度看就是判定是否为空，然后下面就executeSql方法，直接执行了sql语句了，而这里keyword的话则是通过三层url编码进行注入
为什么是三层呢，因为1.使用post传参有一层，2.在传入到browser.jsp文件的时候则又进行了一次url解码，在进入到这个listRemindType方法后再进行了一次url解码，因此是三层。
POC
POST /mobile/plugin/browser.jsp HTTP/1.1Host: x.x.x.xUpgrade-Insecure-Requests: 1User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.110 Safari/537.36Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9Accept-Encoding: gzip, deflateAccept-Language: zh-CN,zh;q=0.9x-forwarded-for: 127.0.0.1x-originating-ip: 127.0.0.1x-remote-ip: 127.0.0.1x-remote-addr: 127.0.0.1Connection: closeContent-Type: application/x-www-form-urlencodedContent-Length: 649isDis=1&browserTypeId=269&keyword=%2525%2536%2531%2525%2532%2537%2525%2532%2530%2525%2537%2535%2525%2536%2565%2525%2536%2539%2525%2536%2566%2525%2536%2565%2525%2532%2530%2525%2537%2533%2525%2536%2535%2525%2536%2563%2525%2536%2535%2525%2536%2533%2525%2537%2534%2525%2532%2530%2525%2533%2531%2525%2532%2563%2525%2532%2537%2525%2532%2537%2525%2532%2562%2525%2532%2538%2525%2535%2533%2525%2534%2535%2525%2534%2563%2525%2534%2535%2525%2534%2533%2525%2535%2534%2525%2532%2530%2525%2534%2530%2525%2534%2530%2525%2535%2536%2525%2534%2535%2525%2535%2532%2525%2535%2533%2525%2534%2539%2525%2534%2566%2525%2534%2565%2525%2532%2539%2525%2532%2562%2525%2532%2537
当然这是我的猜测，这里我们尝试一下，因为我这里安装的是mysql数据库，而网上传的poc是mssql的语句，因此我在网上找一个尝试
这里可以看到成功进行了sql注入，那么我们现在来第二部分，也就是这个目录未授权访问的部分，目录位置在 ecology/WEB-INF/myclasses/weaver/security/rules/ruleImp/SecurityRuleMobile29.class
具体的话就是validate方法了 应该是有某个地方调用了这个方法，然后这个方法返回true的话就能成功访问到对应目录，但是因为这洞不是我挖的，而且网上的文章，这一块是没有写具体的情况的，所以我这里也不了解，只知道这里面只要返回true就行（别问 问就是菜狗的悲伤）
那我们来看代码 这里进来就可以看到new了一个类然后通过getrequestURI获取对应的url路径
在结合变量名path这里可以得知应该是获取对应的路径，然后调用了父类的path方法
这里则是对路径进行了判定 路径里面不能有//和；号，然后进行返回
这条if判定则是路径里面不能有空不能有..和\ 然后进入if 下面一条if我们看不懂不用管，因为他里面反正返回true，看else
这里可以看到只要路径里面有.jsp或者/mobile/路径就可以进入if 那我们是满足条件的。然后下面则是两个列表一个是当我们传入的路径不登录也可以访问的，还有一个是需要登录才能访问的
一个叫mobile-need-login-users 这看名字就能猜出是需要登录才能访问的模块，然后这里具体的文件，我找不到在哪，但是根据网上的文章可以知道我们要访问的这个模块是在需要登录的里面的
但是这里问题不知道，因为下面有个return true 也就是说，只要我们访问的目录没在两个中，就还是会返回true也就是可以访问成功
我们这里可以通过在路径中间添加%20来绕过他的这个规则，从而成功访问到该目录，接着就是第三部分
对于目录访问的一个补丁部分也就是官方的修复部分，打开Ecology_security_20221014_v10.55.zip文件，进行解压缩。然后我们在里面同样找到这个文件 ecology/WEB-INF/myclasses/weaver/security/rules/ruleImp/SecurityRuleMobile29.class
然后我们可以看到这里有个else if 这里多了一个对路径的判断
对路径进行了正则匹配，不过我不太懂正则 这里就不知道啥作用了，但是这里有效隔绝了%20的空绕过
第四部分对于漏洞本身的补丁，还是打开10.55的补丁包文件，找到 ecology/WEB-INF/myclasses/weaver/security/rules/ruleImp/SecurityRuleForMobileBrowser.class文件 这个文件是补丁文件，在10.54里面是没有的是新添加用于修复sql注入漏洞的
这里先是获取了keyword参数，然后进行了url解码，判断是否有单引号（因为单引号为闭合符号） 如果有则返回false
在进行了url解码，然后再进行了if判断，第二个判断则是判断第二次url解码结果是否跟第一次一样，如果不一样则直接返回false，所以这个文件有了后就不可能再有多次编码进行sql注入的操作了
完结撒花，有错误欢迎纠正。
参考
https://mp.weixin.qq.com/s/17tc4ep83x4243lzr-brCg写在最后
本人坚决反对利用文章内容进行恶意攻击行为，一切错误行为必将受到惩罚，绿色网络需要靠我们共同维护，推荐大家在了解技术原理的前提下，更好的维护个人信息安全、企业安全、国家安全。
未经授权请勿利用文章中的技术资料对任何计算机系统进行入侵操作。利用此文所提供的信息而造成的直接或间接后果和损失，均由使用者本人负责。
