API越权风险检测方式浅谈

0x01 前言

越权漏洞相较于SQLInject、XSS、SSRF等漏洞，最大的不同点在于该漏洞和权限的架构设计具有强相关性，而权限的架构设计又强依赖业务属性，这就导致了几乎每个系统的权限架构都各不相同，自动化检测的难度非常之大，误报率非常高；内部的检测准确率无法有效提升，越权漏洞数量就很难有效的下降

关于越权漏洞的挖掘，从原理上来看并不复杂，甚至可以说是简单，最大的难点在于信息收集能力、细心程度、对业务的理解度，这个其实也没有什么好谈的

关于批量/自动化越权检测的文章在网路上寥寥无几，开源的工具更是少的可怜（某些大佬手里有牛逼工具除外），今天想要说的是在甲方，特别是应用数量三位数、四位数以上的甲方，在面对大量API时的越权漏洞检测思路探讨

0x02 越权风险类型

越权漏洞的分类及定义在[1]这个笔记里说的已经很详细了，在这里就不赘述了

• 未授权访问

• 水平越权

• 垂直越权

除了上边说的三类权限漏洞，结合业务场景，一般会将权限分为两类

• 功能性权限/菜单权限

• 用户有没有权限访问这个功能/菜单

• 数据性权限

• 用户有没有权限访问其它用户的数据

0x03 检测方式

一个应用，可能只需要一两个小时就可以测试完成；十个应用，顶多也就一周；那一百个呢？一千个呢？

每天又会有几百个应用产生迭代，新增的API呢？

实际上一家几千人的互联网公司，负责应用安全的同学往往只有两到三个，API会有几千几万个

所以这里我们从黑盒、白盒、自动化、半自动的思路来探讨一下越权漏洞的解法

主要分给两个关键部分

• 流量采集

• 服务器出口日志采集

• 测试环境日志采集

• 请求重放

• 多个账号重放请求

• 结果对比

• 排除误报

优点：在理想情况下，可以通过很少的人力去覆盖大量应用

缺点：大量的误报，安全产品死于误报；线上真实流量重放效果最好，却容易造成故障

这种方式一般会尝试和测试团队合作，在测试环境里进行，或者安全工程师进行单个系统测试时使用，像ZTO的authcheck、BurpSuit插件AuthMatrix等差不多都是类似的思路

• 流量采集

• 浏览器被动代理或爬虫方式采集

• 请求重放

• 多个账号重放请求

• 对response进行简化

• 人工确认

• 对简化后的response进行判断是否存在漏洞

优点：最后输出的漏洞结果准确度较高，适合针对单一系统进行安全测试

缺点：在面对大量应用及大量迭代新增API时，效率太低

这种方式有两种思路，一种是发现存在越权风险的接口，一种是发现不存在越权风险的接口，原理是差不多的

• 白盒扫描

• 入参是否包含可越权(可遍历)的参数

• 是否有从cookie或session中或获取用户标识

• 风险确认

• 是否包含authcheck(xxid, userid)的判断逻辑

• 是否包含@authcheck的注解

优点：仿佛看到了可以批量发现越权风险的方法，对于一些简单的水平越权可以有效发现，而且一般一个系统的权限缺陷都是相似的，发现一个，发现一片

缺点：误报率太高，不能发现复杂的越权风险

这种思路和上面提到的”黑盒+半自动化“的思路差不多

• 白盒扫描

• 扫描器应用的API list（可参考我上一篇文章[2]）

• 标明入参及用户标识、判断逻辑

• 人工确认

• 通过白盒扫描出来的入参、用户标识、判断逻辑来判断是否存在越权风险

优点：对一部分水平越权、未授权访问的风险可以有效发现

缺点：API数量一多就不灵光了，很难发现复杂的越权

0x04 简单思考

上边扯了这么一堆越权漏洞的检测方法，但其实并没有解决上边提出的问题

上千个应用、几万个接口，每天新增上百个，如何去解？存量呢？新增呢？

在以前，我还经常会去给开发们做一些安全培训，但是效果呢？只有少数开发能真正认识到越权的严重性，效果并不乐观，该出现的漏洞一个都没少，并且效果无法衡量

做应用安全也有几年的时间了，现在所谓的"安全运营"也越来越多人提了，那我们是运营吗？是也不是，我更喜欢称自己为“技术运营”，用技术来解决运营的困境，这个愿望是好的，扯皮的事情总是少不了的

回到越权漏洞的问题，每次做安全众测，都会爆出来一堆越权的问题，不乏之前出现类似漏洞的应用，然后就会有人跳出来问，你们之前复盘的action落实了吗？为什么还会出现？balabala，这些问题我又何尝不是经常问自己，到底是为什么？这段时间和教父也经常在讨论这些问题，那么问题出在哪里了呢？

先说一下我的思考结论，越权漏洞的解法是”流程+工具(监控)+覆盖度+蛮力”

• 流程

• 举个例子，当SRC上报了一个越权漏洞过来，开发完成修复，然后进行复盘(出现这个问题的根本原因是什么？其它API会存在吗)，开发领了排查同类API的action回去，排查完成后，安全工程师核查开发同学的排查结果，形成闭环

• 工具(监控)

• 工具这个范围就很广了，在我看来，无论是开源的还是自己开发的工具都像是一块块积木，将它们通过合适的方式组合起来，才能发挥出最大的效果；而不是为了kpi而不停的造轮子，造完一个来年再造一个

• 针对增量的API，建立完善的监控体系

• 覆盖度

• 这个点是最关键的一个点，你会发现，每次出事的点都是你没有覆盖到的，对资产的熟悉程度，对API的监控完整度都非常重要

但这个也不是我真正想表达的点，因为按照上边的说法，还是要搞一套类SDL的东西出来，API那么多，人就这么两三个，到年底又变成PPT上代码了，第二年问题照旧

虽说在这类风险的解决上没有一招鲜的讨论，但是我觉得真正需要去做的是逐个点打穿，一步步的去收敛风险；将一个个点打穿，才能真正的解决问题，而不是浮于表面，看起来大而全，实则只不过是徒有其表；没有流程、技术支撑的东西我是不信的，不要再提什么宣导啥的，没什么用处

例如这个阶段就只做”复盘--开发自查--安全复查--安全挖掘漏洞--复盘”这个闭环，相信用不了半年，就可以对高危应用的风险进行有效收敛

上边没有提“蛮力”这个点，有时候要解决风险，地毯式排查往往是最有效的方法；为什么这么说了，假设现在开始治理越权，那几千几万个存量API怎么处理呢，等扫描器开发完成？这时候可以对API进行分级，识别出其中包含敏感信息的API，这时候就剩几千个了(也是非常庞大的工作量，但是只能硬着头皮上)，对这部分API进行地毯式排查，没有敏感信息的越权，危害还是相对可控的；方式low了点，但效果是有的，同时建立完善的新增接口监控体系，对增量API及时的进行处理;在评审了大量的接口后，归纳总结，对每个业务域的权限架构进行优化(当然这非常困难)，安全接入进去，从根本解决问题（这种方案是笔者现在正在实践的，效果半年后再来写一篇）

现实有时候是骨感的，干活的人没啥增加，每年的kpi都是不断的增长，很难专门拿出一段时间来做存量的攻坚，存量不解决，漏洞永不休

//说了这么多，下班回家脑阔疼，不想调整逻辑了，大家将就着看一下，想表达的观点就一个“找到问题，打穿它，无论用什么方法，有些苦是一定要吃的”。

//还有就是教父说招人一起来搞事情

参考：

[1]https://g.yuque.com/evilm/yuequan/gmqet8?language=en-us

[2]https://mp.weixin.qq.com/s/ATpoEN9QI-D5vkxDimQ8FQ