企业级API越权扫描器设计与实践：基于黑盒测试与AI研判的自动化安全方案

2025年下半年，我投入了126.8小时，借助AI编程工具从零到一完整落地了一套越权扫描器。整个过程涵盖了方案调研、产品设计、编码实现、扫描执行以及存量漏洞的初步治理。我对这个作品非常满意。

一、背景

1. 团队现状：当时公司只有我一名应用安全工程师。
2. 项目基础：在启动越权扫描器项目之前，我已经完成了对传统漏洞扫描器（DAST/SAST/SCA）存量漏洞的治理，并搭建了基础的自动化运营流程。基于此，我开始考虑针对业务逻辑漏洞构建自动化检测能力，而越权漏洞因其普遍性和高风险性，成为了我首要攻克的目标。

二、目标

在项目启动时，我设定了清晰且可衡量的目标：

1. 覆盖的风险场景：未授权访问（unauth）、水平越权、垂直越权。
2. 覆盖的业务场景：所有暴露在互联网上的核心业务应用。
3. 动态持续扫描：支持周期性主动扫描作为兜底，并期望未来能集成到CI/CD流水线中进行被动扫描。
4. 漏洞可运营：建立漏洞管理流程，支持将多个漏洞聚合成安全工单，便于跟踪修复。
5. 风险可观测：通过仪表盘展示漏洞率、漏洞类型分布、漏洞应用分布等关键指标。
6. 效果可衡量：量化API覆盖率、准确率、降噪率及检出漏洞总数。

三、打法思路

在2025年第三季度，我进行了大量调研。关于业内自动化识别越权漏洞的多种思路，可以参考我的相关分享。

3.1 检测思路

在黑白灰三种核心检测思路中，我最终选择了黑盒测试（DAST），原因主要有三点：

1. 黑盒的优点：黑盒检测更贴近真实攻击效果，不受编码习惯、跨服务调用或配置临时失效的影响。尽管业内很多方案介绍使用SAST检测水平越权，但我面临的应用由多个团队开发，鉴权习惯各异，且大量使用RPC服务。如果采用SAST，我需要适配所有鉴权逻辑并解决跨项目调用链分析的难题，这对单人团队而言投入产出比（ROI）太低。
2. 黑盒的缺点与权衡：相比SAST，黑盒的缺点在于召回率可能较低。但我的方案旨在覆盖所有活跃接口，我认为这些活跃接口是当前安全风险的主要矛盾，因此可以接受这一缺点。
3. 垂直越权的覆盖：公开资料中很少涉及垂直越权的自动化识别。在我们公司，接口鉴权可能基于角色或个人，相关数据存储在数据库中。使用SAST方案需要额外读取和适配这些授权数据，复杂度会显著增加。

3.2 业务流程

以下业务流程不包含API信息的收集。从领域划分角度，我将API信息的收集与管理拆分到了独立的“API资产管理模块”。你可以理解为，在进行越权扫描之前，目标API的相关元数据（如描述、参数说明）已经准备就绪。具体可参考下一节的系统架构图。

3.3 系统架构

四、核心模块

4.1 目标过滤器

定位：通过API的静态元数据，提前排除掉肯定不存在漏洞的接口，从而大幅提升扫描效率和研判准确率。例如：

• 某个接口在网关层已明确开启了登录认证，那么它就不可能存在未授权访问（unauth）漏洞。
• 某个接口没有任何入参，那么它就不可能存在水平越权漏洞。

业务逻辑：根据待检测的目标API和风险场景（unauth/水平/垂直），首先检查是否命中本地缓存的白名单。如果命中，则跳过该API在该场景下的所有后续检测。如果未命中，则依次执行预定义的过滤器策略。若命中任何一条策略，则将该API-场景对加入本地白名单，并跳过后续检测。

策略清单：以下是我规划并已部分实现的7条目标过滤器策略。

设立目标过滤器的价值：

1. 显著降噪：过滤掉大量明显无风险的接口，减少需要人工或AI研判的目标数量。
2. 节约成本：降低调用大模型进行AI研判的次数，从而节约运营成本。
3. 提升效率：让扫描和研判资源集中在更有可能存在漏洞的接口上。

4.2 HTTP请求模块

定位：核心执行模块，负责构造越权请求并获取响应数据包。

业务逻辑：首先，调用网关的日志查询服务，获取目标API在真实业务中的一次请求记录（包括用户A的原始请求和响应）。然后，根据待检测的风险场景选择合适的测试账户（B账户用于水平越权，C账户用于垂直越权，或直接构造未授权请求）。最后，使用与业务完全一致的加密和签名算法，将测试账户的凭据与会话信息替换到请求中，发起“越权”请求并记录新的响应。

传递给AI研判的数据结构：这个模块会整理出如下格式的JSON数据，作为后续漏洞判定的输入。

{
  // 微服务名称
  "servicename": "exmapleorderapi",
  // API端点
  "endpoint": "/example/order/detail",
  // 账户A的原始请求参数
  "original_request": {
    "orderId": 17402113
  },
  // 账户A的原始响应
  "original_response": {
    "orderInfo": {},
    "goodsList": [{}]
  },
  // 测试账户（如账户B）越权请求后的新响应
  "new_response": {
    "orderInfo": {},
    "goodsList": [{}]
  }
}

4.3 漏洞判定

定位：系统的“大脑”，负责分析请求与响应数据，最终识别出存在漏洞的接口。我选择引入大模型服务来实现这一复杂的逻辑判断。

4.3.1 核心认知对齐

首先，我们需要明确两个关键概念：

• 请求是否成功（技术结果）
• 请求是否应该成功（业务预期）

漏洞的本质是：一个请求不应该成功（业务上应有鉴权拦截），但实际上却成功了。

从白帽子视角理解漏洞判定：

• 未授权访问 (Unauth)：找到一个业务上应要求登录的接口，删除或篡改其Cookie后重放请求，若成功则存在漏洞。
• 水平越权：找到一个应对数据进行权限校验的接口（如查询个人订单），使用同角色但不同身份的账户B，重放账户A的请求（如相同的订单ID），若B能获取到A的数据，则存在漏洞。
• 垂直越权：找到一个应进行功能权限校验的接口（如管理员操作），使用低权限角色的账户（如普通用户）重放高权限账户的请求，若低权限账户操作成功，则存在漏洞。

判定所需的关键信息：

• 业务场景：这是ToC应用还是ToB后台？
• 接口信息：接口名称、功能描述。
• 参数信息：入参和出参的清单及其业务含义。
• 账户信息：测试账户的角色及其明确的权限边界。

核心原则：在进行自动化漏洞判定时，必须为判定引擎（如AI）提供足够丰富的上下文信息。

4.3.2 API资产管理模块

定位：为整个扫描器提供数据基础。它负责从API网关、API文档平台、网关日志等数据源拉取和整合API的元信息，包括接口描述、参数说明、是否开启登录认证等。

这个模块是因越权扫描器的需求而新建的，属于应用安全平台的基础能力之一。

它为AI判定提供的关键信息如下所示：

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

4.3.3 配置管理模块

定位：以平台化方式配置扫描器所需的补充信息，使得运营更加灵活。

层级关系说明：一个应用程序（APP）对应多个微服务，一个微服务包含多个API。

• 在应用维度配置：业务描述、环境Base URL、加解密密钥、以及用于测试水平/垂直越权的账户凭据及其权限边界描述。
• 在微服务维度配置：服务名称（用于联动CMDB）、API文档平台中的服务名称映射（解决命名不一致问题）。

它为AI判定提供的关键信息示例如下：

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

4.3.4 AI漏洞判定引擎

我为三种风险场景分别创建了专属的AI判定助手。以下是“水平越权判定助手”的提示词（Prompt）示例：

<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>

AI判定助手会接收到如下格式的完整数据包：

AI将输出结构化的判定结果和依据：

4.4 漏洞管理

定位：提供人机交互界面，供安全运营人员对AI检出的漏洞进行人工复核、状态管理，并将确认为有效的漏洞聚合成安全工单分发给研发团队。

人工研判界面：

工单聚合功能：（支持按微服务和漏洞类型对漏洞进行聚合）

4.5 指标大盘

建立可量化的指标对于评估工具效果和指导运营方向至关重要。

4.5.1 风险可观测指标

• API漏洞率：用于展示越权问题的整体现状，并衡量安全左移后的改进效果。需支持全局、按应用、按微服务多维度下钻。

  计算公式：分子 = 存在越权漏洞的API数量，分母 = 已覆盖扫描的API总数。

• 越权漏洞类型分布：用于识别高风险场景和问题集中的微服务。需区分未授权、水平越权、垂直越权等类型。

  计算公式：分子 = 某类风险场景的漏洞数量，分母 = 所有风险场景的漏洞总数。

4.5.2 运营可衡量指标

• 漏洞检出提升率：2025年，通过该扫描器实现的漏洞检出提升率为11.73%。此指标衡量扫描器对整体安全漏洞检出能力的贡献。

  注：2025年我们还建设了其他多项检测能力，因此越权扫描器的贡献比例看起来不高，但其绝对价值和专项效果显著。

• API覆盖率：衡量扫描器对目标资产的覆盖程度，理想目标是100%。需区分全局覆盖率和单个应用的覆盖率。
• 准确率：当前整体准确率为75.74%，用于衡量漏洞判定模块（AI研判）的效果。
  • 未授权访问 (Unauth) 准确率：56.76%
  • 水平越权准确率：85.50%
  • 垂直越权准确率：67.16%
• 降噪率：当前整体降噪率为42.75%，用于衡量目标过滤器模块的效果。
  • 未授权访问 (Unauth) 降噪率：67.48%
  • 水平越权降噪率：36.37%
  • 垂直越权降噪率：24.41%

    计算公式：分子 = 被加入各场景白名单的API数量，分母 = API总量 × 风险场景数（3）。

五、其他关键经验

5.1 善于利用现有能力（站在巨人肩膀上）

这里的“巨人”指的是公司内部其他团队已建设好的基础设施和能力。充分调研并集成这些能力，能让安全方案的落地事半功倍。

1. API网关：公司标准业务都接入统一网关，使我能够轻松获取全量API清单。
2. 统一鉴权配置：通过网关SDK可配置接口是否开启登录校验，使我能够直接获取API的认证状态。
3. API文档平台：效能团队的流水线插件能自动收集代码中的API文档（类、方法、参数说明），使我获得了丰富的接口语义信息。
4. 全量请求日志：网关记录了所有请求的入参和出参，使我能够获取真实的业务数据流用于测试。

衍生风险与应对：需意识到“网关的校验配置可能存在失效风险”。因此，我建立了周期性健康检查机制，对已知应开启认证的接口发送测试请求，验证其鉴权是否仍然有效。

5.2 业务环境梳理耗时较长

这是无法跳过的重要准备阶段：

1. 梳理资产：明确需要覆盖哪些应用程序，以及每个应用程序包含哪些微服务。
2. 梳理业务场景：理解每个应用的核心模块与功能。
3. 梳理权限角色：识别系统中的核心角色（特别是存在接口鉴权的应用）。
4. 梳理权限边界：明确每个核心角色的操作权限范围。目的有二：一是为水平、垂直越权测试选择合适的测试账户（原则是在覆盖核心API的同时尽量简化）；二是为AI判定提供清晰的规则，使其能判断测试账户“是否应该有权限”访问某个API。

5.3 测试账户的选择技巧

1. 角色选择：对于一个有多种角色的应用，应选择能覆盖最多需测试接口的角色作为测试账户，以平衡测试复杂度和安全覆盖。
   • 示例：某应用有223个接口，涉及5种角色。合伙人可访问197个接口，店长96个，店员9个，运营经理117个。最终，我选择一个店员账户测试垂直越权（因其权限最小），选择一个合伙人账户测试水平越权（因其数据权限最广）。
2. 账户新旧选择：
   • 测试水平越权：选择高权限角色（如“店长”）时，最好使用一个全新的、专用于安全测试的账户。避免与QA共用账户导致A、B两账户因历史数据而产生意外的相同权限。
   • 测试垂直越权：选择低权限角色（如“店员”）时，最好使用一个旧的、已有一定测试数据的账户。因为如果目标接口存在垂直越权漏洞，但测试账户在该接口下没有任何数据，可能会导致误判。

5.4 存量漏洞的运营策略

对于扫描器初期检出的大量历史漏洞，运营策略需有弹性：

• 从微服务视角评估：漏洞数量少的，走标准安全工单流程，设定修复期限；漏洞数量非常多的，启动专项治理项目，与业务团队共同规划分期修复。
• 价值转化：这部分漏洞是极佳的“坏案例”样本，可以帮助我们持续优化漏洞判定逻辑，通过分析误报和漏报，不断提升AI研判的准确率。

六、2026年的规划

1. 理想态左移：期望能在测试（Test）阶段就检出越权漏洞，并将其融入QA的测试用例中，由QA在功能测试环节关注并推动修复，实现更彻底的安全左移。
2. 扩大覆盖与智能构造：计划覆盖更多API和应用。构思了一种新机制：不完全依赖网关的实时日志，额外查询本地存储的历史请求参数库。并设计两种参数构造方案：一是支持人工录入关键参数；二是根据同一微服务下已知API的参数值，智能推理和构造未知API的入参。
3. 动态白名单管理：当前目标过滤器的白名单机制存在“时效性”衍生风险。例如，一个未开启登录认证的接口被加入了水平/垂直越权的白名单，但如果后续该接口开启了认证，它就需要被移出白名单。需要设计一个定期巡检和清理的流程。
4. 完善过滤器策略：目标过滤器中规划的后3条（更依赖AI的）策略尚未实现。一方面因为现有方案已基本可行，另一方面由于时间限制。计划在2026年上半年完成这些策略的开发和上线。

---

这篇文章分享了一套完整的越权漏洞自动化扫描方案从设计到落地的全过程，涉及架构设计、模块拆分、AI应用及运营思考，希望对从事应用安全、自动化测试或DevSecOps的同行有所启发。我们后续也会在云栈社区的安全技术板块分享更多关于自动化安全测试与漏洞运营的实践细节。