越权扫描器落地实践

前言

2025年H2 我用126.8小时，借助Cursor从0到1完成了这款越权扫描器，包括方案调研、产品设计、coding、扫描、存量漏洞治理。我很喜欢这个作品。

一、背景

1、我们公司只有我一个应用安全

2、在做越权扫描器之前，我已经完成了传统扫描器的存量治理以及如下自动化运营流程的建设，因此我开始考虑针对业务漏洞建设自动化检出能力，率先需要解决的就是越权漏洞。

二、目标

2.1 覆盖的风险场景：unauth、水平越权、垂直越权

2.2 覆盖的业务场景：所有外网核心的业务应用

2.3 动态持续扫描：周期性主动扫描（兜底）或者流水线被动扫描（期望）

2.4 漏洞可运营：漏洞管理、工单聚合

2.5 风险可观测：漏洞率、漏洞类型分布、漏洞应用分布

2.6 效果可衡量：API覆盖率、准确率、降噪率、漏洞数

三、打法思路

25年Q3季度我做了很多调研，业内对自动化识别越权漏洞的一些打法思路可以去我的知识星球看：https://wx.zsxq.com/tags/越权漏洞自动化识别/48811842128528

3.1 检测思路

在黑白灰三种核心检测思路中，最终我选择了黑盒，原因有三个：

1、黑盒的典型优点：黑盒检测可以不受编码习惯、跨服务调用、配置失效的影响，更接近真实；业内大部分方案介绍的都是使用SAST来识别水平越权，我待覆盖的业务场景中涉及多个开发团队、多种鉴权习惯、且大量使用RPC服务，使用SAST来检测会大量增加我的复杂度，我需要适配所有鉴权习惯并覆盖跨项目检测的能力，而我只有一个人，ROI较低。

2、黑盒的典型缺点：相比SAST，黑盒检测的缺点是召回率低，我的方案可以覆盖所有活跃接口，我认为这些活跃接口就是我当前的主要矛盾，所以黑盒的缺点我可以接受。

3、更容易覆盖垂直越权：公开的文章很少介绍垂直越权的识别，我们公司的接口鉴权可以基于角色也可以基于个人，鉴权数据都存在数据库中，如果使用SAST来做，需要想办法去读数据库、去适配这些授权数据，会额外增加复杂度。

3.2 业务流程

这部分不含API信息的收集，从领域划分角度我将API信息的收集跟管理拆分到API资产管理模块，你可以理解为在进行越权扫描之前，API的相关信息已经具备。详情可以看3.3系统架构部分。

3.3 系统架构

四、核心模块

4.1 目标过滤器

定位：通过API静态的基础信息来排除掉肯定没有漏洞的API，例如：

① 在网关层开启了登录认证，那么这个接口肯定不存在unauth漏洞

② 某个接口不存在入参时，那么肯定不存在水平越权漏洞

业务逻辑：根据待检测目标（API）跟场景（未授权/水平越权/垂直越权），先检查是否命中本地白名单，如果命中，则跳过后续的检测；未命中则去执行过滤器策略，如果命中则添加到本地白名单中，并跳过后续的检测。

策略清单：如下是当前规划的7条目标过滤器的策略：

设立目标过滤器的优点：

① 降噪：有些场景下需要投入人力评估每个API是否有漏洞，目标过滤器可以过滤掉大量肯定没漏洞的接口

② 节省AI研判的成本

③ 提升扫描的效率

4.2 HTTP请求

定位：构建越权请求并获得响应包。

业务逻辑： 调用网关的日志查询服务查询API的真实请求记录，获取到真实用户A的原始请求跟响应，根据待检测的风险场景选择测试账户B（水平）、或者C（垂直）、或者D（unauth），并且使用与业务相同加密跟签名算法构造越权请求，获取响应。

这个环节AI可以拿到下面这些信息：

{
// 微服务的名称
"servicename": "exmapleorderapi", 
// API的名称
"endpoint": "/example/order/detail",
// 账户A的入参
"original_request": {
"orderId": 17402113
},
// 账户A的响应包
"original_response": {
"orderInfo": {},
"goodsList": [{}]
}, 
// 测试账户越权请求的响应包
"new_response": {
"orderInfo": {},
"goodsList": [{}]
} 
}

4.3 漏洞判定
定位：识别出有漏洞的接口
4.3.1 认知对齐
将请求是否成功、请求是否应该成功拆分来看：
请求不应该成功（说明应该有鉴权），但实际却成功了，才说明有越权漏洞。
作为白帽子我如何判定一个接口存在越权漏洞：


unauth：找到应该存在登录校验的接口，删掉Cookie或者改为无效Cookie，重放请求，可以请求成功；


水平越权：找到应该进行数据鉴权的接口，如订单信息、地址信息，使用相同角色的测试账户重放请求，可以请求成功；


垂直越权：找到应该进行接口鉴权的接口，如新建子账户，使用低水平角色的测试账户重放请求，可以请求成功。


作为白帽子我基于哪些信息判断一个接口应该鉴权：


业务场景，这是一个toC的二手交易平台，还是toB的商家管理平台


接口名称及描述信息


入参清单及描述信息


出参清单及描述信息


在垂直越权中，如何判断测试用户对应身份不应该请求成功：


接口信息：例如这是一个强制关店的接口，预期内店长、大区经理、总部运营人员才能操作。


测试用户的预期权限：例如这是一个店员账户，预期内只能看订单信息、个人信息，不能对门店进行操作。



原则：在漏洞判定时请给到AI足够多的上下文信息

4.3.2 API资产管理模块
定位：从网关、APIdoc平台、网关日志拉取API的相关信息，包括登录标识、描述、真实用户的请求日志。
这个模块之前没有，但是越权扫描器需要这些信息，因此在Appsec平台中，先开发了这个基础模块。

这个设计可以让AI在漏洞判定时拿到下面这些信息：


{
"endpoint_description": "余额明细",
    "param_description": {
    "balanceType": "余额明细类型（0 全部，1 充值记录，2 消费记录）",
    "pageNo": "页码",
    "pageSize": "每页多少条",
    },
}

4.3.3 配置管理模块
定位：填写越权扫描器所需的补充信息，支持平台化配置。

一个应用程序对应多个微服务，一个微服务对应多个API。


在应用程序维度配置：业务描述、base url、加解密的密钥、水平越权&垂直越权的测试账户的凭据跟权限边界。


在微服务配置配置：服务名（便于联动CMDB）、APIDoc平台的名称纠错（存在跟服务名不一致的情况）。





这个设计可以让AI在漏洞判定时拿到下面这些信息：


{
    "app_description": "门店员工管理端APP，用户群体是公司线下门店的员工，用于管理本门店的一些信息",
    "test_account_role": "店员",
    "test_account_role_description": "店员：店员角色允许操作：门店模块所有菜单、 健康证、平台资质、个人信息；其他模块均不应该有权限操作。"
}

4.4.4 漏洞判定
我为三种风险场景分别创建了AI助手，水平越权判定助手的提示词示例：

```xml
<instruction>

你是一名信息安全专家，你需要基于给你的测试数据研判是否存在"水平越权漏洞"；安全工程师先去日志中查询账户A的请求日志，然后将会话信息替换为账户B，重新发起请求，记录响应，最终得到一个JSON格式的数据包，包含的字段如下：

1. endpoint：请求的接口名
2. original_request：账户A跟账户B共同使用的接口入参
3. original_response：这是第一个请求，账户A请求时的返回包
4. new_response：这是第二个请求，账户B请求时的返回包
5. doc: 包含对应用程序、接口、参数、账户的描述信息，优先读这个信息
6. 在original_response和new_response内部有多个字段，其中的content字段是服务端真实返回的数据，其他字段都是中间件加上的字段

研判原则：如果账户B可以使用账户A的请求参数获取到账户A独有的数据，那么认为存在水平越权漏洞；

研判技巧：

1. 关注入参清单，入参为空、入参存在但缺少唯一标识都认为没有漏洞
2. 关注两次的响应包中的content字段
3. 关注接口名称对应的接口含义
4. 若缺少new_response则跳过水平越权漏洞的研判

<output>

输出为JSON格式，结构如下：

{
   "AI研判结论"：枚举类型：无漏洞，有漏洞
   "AI研判原因": 判定依据
}

</output>

</instruction>

```xml

AI判定助手会收到下方这种数据：

AI会输出判定结果跟判定依据：

4.4 漏洞管理
定位：运营人员在WEB控制台对漏洞进行人工研判，将有效漏洞聚合为安全工单。
人工研判：

工单聚合：（会按照微服务跟漏洞类型进行聚合）

4.5 指标大盘
4.5.1 风险可观测：
API漏洞率：用来体现越权问题现状以及后续左移后的效果；展示时需要区分全局、应用、微服务

分子：有越权漏洞的API总量，分母：覆盖的API总量

越权漏洞占比：用来体现高风险场景、微服务；展示时需要区分风险场景、应用、微服务

分子：每种风险场景的漏洞数量，分母：所有风险场景的漏洞数量

4.5.2 运营可衡量：
漏洞检出提升率：2025年检出提升率：11.73%，用来衡量整个扫描器的检出效果。

分子是越权扫描器检出的漏洞数量，分母是2025年所有的漏洞数量
2025年的一个重心是提升检出率，除了越权扫描器还做了很多检出能力，数量不方便说，所以这个比例较低。

API覆盖率：用来衡量扫描器的覆盖效果，理想状态是100%；区分全局跟单个应用。
准确率：75.74%，用来衡量结果过滤器的研判效果


unauth准确率：56.76%


水平越权准确率：85.50%


垂直越权准确率：67.16%


降噪率：42.75%，用来衡量目标过滤器的研判效果


unauth降噪率（67.48%）


水平越权降噪率（36.37%）


垂直越权降噪率（24.41%）



分子：白名单中特定场景的API数量，分母：API总量 * 场景数量

五、其他
5.1 一定要站在巨人的肩膀上设计方案
这里“巨人的肩膀”我指的是公司其他团队现有的能力，充分调研并利用公司现有的能力，这样在落地安全能力时可以事半功倍。
① 我们标准的业务应用都会经过架构团队的API网关，因此我可以在API网关中拿到全量的API清单；
② 这些接口通过API网关的SDK配置是否开启登录校验，因此我可以在API网关中轻易的拿到哪些API开启了登录校验；
③ 效能团队的二方包可以在流水线中收集API文档的信息，因此我可以在我们APIDocs平台拿到每个API的类说明、方法说明、参数说明；
④ 经过API网关的请求可以将入参跟出参记录到日志中，因此我可以在我们网关的日志中拿到业务请求的入参跟出参。
这些信息对于基于DAST的越权扫描器来说，都是最宝贵的信息。

衍生风险：“网关的校验存在失效的可能”，因此我需要取一个存在登录校验的接口周期性的发请求来校验有效性。

5.2 业务环境的梳理会占用较多的时间
梳理资产：① 先理清楚有哪些应用程序需要去覆盖 ② 再理清楚一个应用程序对应哪些微服务。
梳理业务场景：有哪些模块跟功能。
梳理权限角色：有哪些核心角色，我们存在接口鉴权的应用大部分都存在角色权限跟个人权限。
梳理权限边界：梳理每个核心角色的权限边界，目的有两个：一是找出水平越权、垂直越权要使用的角色，原则是覆盖核心API的同时保持简单；二是方便AI来判定当前测试账户是否应该有权限访问某个API。
5.3 测试账户的选择有技巧
① 选择哪种角色作为测试账户？
一个有接口鉴权的应用程序，可能涉及很多种角色，我们可以选择覆盖接口最多的角色作为测试账户，以平衡复杂度跟安全性。
例如有一个应用，有223个接口，涉及的其中5个角色包括：合作伙伴有197条接口的权限，店长：96条，店员：9条，运营经理：117条。最终我选择使用一个店员账户来测试垂直越权，使用一个合作伙伴账户来测试水平越权。
② 选择新旧哪种账户？
假设存在这么一个应用程序：同时存在数据鉴权跟接口鉴权，有两种角色店长、店员，店长只能管理自己的门店，店员只有部分模块的权限。
在测试水平越权时，选择一个“店长”角色，最好是一个全新的安全测试专用的账户；避免因为与QA共用而导致AB两个账户存在相同权限。
在测试垂直越权时，选择一个“店员”角色，最好是一个旧的有测试数据的账户；因为如果对应接口有垂直越权漏洞，但是没有数据，也影响判断。
5.4 这部分存量漏洞如何运营
从微服务视角评估，漏洞少的走安全工单走标准修复期限，漏洞多的走存量治理专项。
这部分漏洞可以帮助我们梳理bad case，优化漏洞判定逻辑，提升准确率。
六、26年的规划
1、我理想中的效果是可以在Test阶段检出越权漏洞、融入QA的测试用例，让QA来关注并推动解决。
2、覆盖更多的API跟应用，预想了一个机制（不完全依赖网关的当前日志，额外查询本地存储的历史入参），两个方案（一是支持人工录入入参，二是根据同一个微服务已知的参数值，自动构造入参）
3、目标过滤器当前的设计有一个衍生风险：这些例外具有时效性，需要设计一个流程及时清理。例如：未开启登录认证的接口会加入到了水平越权、接口越权的白名单中，但是当这个接口开启认证后，需要清除白名单。
4、目标过滤器中后面3个过滤策略还没有做，两方面原因一是已经可行，二是时间原因；计划H1做完这些。

我做了一个知识星球，用来记录我对企业安全努力的痕迹，欢迎大家加入！



本篇文章来源于微信公众号:                 楼兰学习网络安全