越权类漏洞检测总结

平时遇到的一些零星的安全问题，总结一下：

在SDL中，越权类漏洞如何检测？

在应用安全实践中，目前已知的OWASP TOP10 很多都是可以通过框架或者一些组件解决的，再加上DAST/IAST/SAST这些产品的集成，一般的漏洞类型都是可以检测出来的并处理掉的，但是业务逻辑类漏洞是个例外，以至于现在很多的SRC上爆出来的都是越权这类的业务逻辑类漏洞，越权类漏洞分3种，未授权访问/平行越权/垂直越权。接下来总结一下这类漏洞的解决方案
1.框架层面上解决:
很多类型的漏洞都是可以在框架上解决的，一方面确实方便，推广起来也容易。所以有些公司也想着在框架上面来解决越权类漏洞，以此来达到方便快捷解决这类漏洞，其实不然，我们细细会想一下，在框架上解决这类漏洞它的实现机制是框架上要求用户输入的内容时要求校验用户是否登陆，也就是拿到用户的token去访问。
举个例子，不一定普适。之前遇到一类漏洞，就是改了cookie里面的uin，结果可以在某个业务上越权，原因是该业务没有去校验cookie中的uin与skey的对应关系，下放到各个业务去做这个事，有的开发就不检查，后头我们把框架改了，不让开发自己检查，而已必须把uin和skey传到SSO服务来检查，否则就没法通过认证。大概这样子，然后这类问题就解决了
这个例子是别人的，但在我经历过的公司是真实发生过的案例
缺点：
1.业务和框架耦合度过高，框架变复杂
2.解决的其实是未授权的问题，并没有解决平行越权的问题
3.uin一般是app端生成的随机🈯️，一般就算修改也是碰撞，很难碰到，但是app端被逆向后就会发生严重的问题
2.数据库前面加一层校验
这个方案请参考美团职业欠缺在知乎的帖子吧。这里大概说一下重点，把业务直接访问数据库给拆开来，弄个中间层，业务只能请求中间层要数据，而且每次请求都要带上用户的身份票据，中间层根据身份票据来判断返回数据与否。
微信的全程票据和google的gmail都是类似的思想(这2个我各种查找资料没找到)
缺点
1.和方案一雷同，其实不能解决平行越权的问题
2.实现成本同样很高
3.和业务配合
这个方案其实别人也有讲，只是听的云里雾里的没搞明白细节，后来又咨询类很多大佬明白了。
第一步是业务方配合，先和研发配合，要求研发在写借口的时候必须加上越权类的测试用例
第二步:安全定期检查gitlab上的代码，发现有接口没有越权测试用例就发通知告警让加上。这个越权类自然包括类平行和垂直以及未授权
第三步：业务测试人员测试代码必须测试研发的测试用例。这是个要求，其实也是业务测试人员必备的，因为他们测试业务接口肯定是都得挨个测试的。这一步也就没法再检测业务测试人员到底测试了没有。
缺点
1.无法约束业务测试人员到底测试了没有
4.渗透测试
这个地方的渗透测试包括上面提到的所有吧，逻辑类漏洞代码审计也不擅长，主流的解决方案还是DAST
DAST 实现思路是用多个账号对同一个URL进行测试，交换订单ID等操作思路，判断返回包是否相同，进一步判断是否存在越权类漏洞，目前是有中通开源的越权类漏洞扫描器。这个方案有个难点也是误报很高，URL量很大，需要做成平台化去检测。未授权访问的业务比较多的时候人工检测也是很大的工作量，其次URL去重过程中也会遇到很多问题，需要逐个去细化，有些业务的URL写法非常的不规范会导致去重艰难，做过的都知道这一步是个体力活
IAST 交互式扫描器最近这几年大火，主流的openRAST是典型的代表。不过看官方文档截止目前还没有这方面检测的功能。但是一定是可以实现的。
人工渗透测试：有耐心的白帽子很愿意挖掘这类漏洞，优惠卷各种骚姿势便利，思路要多广有多广。看SRC能学到不少骚姿势

总结
说这么多，在甲方落地的化其实还是方案3加上方案4是最佳方案。IAST的痛点太大，业务接受agent方案有些难，目前看到一些新奇的思路实现的也都非常棒，这个方案检测越权类也是可以的，旁路部署不影响业务
详见：https://mp.weixin.qq.com/s/y2EWoAGByaQ1eNyKmUoP7A