yapisql注入到RCE

mongoose sql injection

注入看修复的commit就可以看出来在哪：

这里对token增加了限制很容易想到token为其它类型的的情况，比如json，再结合注入就基本确定是mongoose的sql注入了

接着看下面的逻辑，注意两点

parseToken，看下代码的话会发现功能是解密token，获得原始的token，默认情况下salt是abcde和uid的拼接

这段逻辑是没什么问题，但是在下面parseToken失败了之后mssql 注入，代码又尝试把这个token当作原始的token进行查询和校验，这里就有点奇怪了。

一直跟踪getProjectIdByToken到最终调用mongoose的api都没有对token做任何过滤，所以这里存在注入。

mongoose的注入可以参考，

最终的效果就是可以通过注入真实的token，然而这里token并不是用户登录的token等等，而是项目的token

所以还要看看什么接口可用，来获取加密后的token以及RCE

可以通过 /api/open/plugin/export-full 这个接口uid然后推出加密后的token，然后就是分析怎么RCE了

mock sandbox

因为yapi之前有开放注册导致mock处可以RCE，所以我也先看了这个，相关接口是全部可以通过token访问的。不过因为之前的洞导致这里的沙箱增强了很多，所以之前的sandbox bypass也无法使用了

所以这里研究了下mock sandbox，发现之前的VM沙箱换成了safeify:

可以参考 了解这个沙箱：

发现safeify直接调用了vm2 , 在安全上没有增加很多限制

那问题就是bypass vm2 了，vm2是一个相对安全的NodeJS沙箱，绕过这个难度就会大很多，只能寄希望于目标站点搭建时间比较早，用的vm2版本相对低一点，这样就可以用vm2的bypass方法来绕过

pre_script

再去看了一下漏洞预警，发现这次似乎RCE的点是pre_script, 所以又看了一下pre_script是怎么处理的：

在runAutoTest pre_script被处理,runAutoTest 是 /api/open/run_auto_test的处理函数，也是可用token调用的

然后是handleTest调用crossRequest，crossRequest通过sandbox运行preScript，

然后就发现pre_script处的沙箱居然是vm.., 那就可以直接用vm沙箱bypass的方法来命令执行了，

默认也是用sandboxByNode来执行script，不过还是可以看看else里面的sandboxByBrowser

发现沙箱都省了。。不过不会走到这就是了。

总结这个漏洞产生的根本原因是在处理token的时候parse失败了都不返回，多此一举，既然会有直接校验原始token这一步那么花这么多功夫加密解密token干什么呢？

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!