实际做了两轮完整的安全测试之后我对自动化 API 越权检测这件事的看法变化很大。过去一年我在不少项目里碰到过对象级越权IDOR、批量赋值Mass Assignment、功能级越权这类问题痛点始终是同一个接口太多、业务上下文太杂纯手工测效率低到让人绝望。后来我接触到 Hadrian、Vespasian 这两个开源工具配合 crAPI 靶场搭出了一条能自动发现攻击面、自动跑越权验证的检测链路。这篇东西就是我完整部署与使用的实战记录包含踩坑过程、配置细节和结果判读思路想直接拿来复现的同学可以照着走。先说结论这套方案并不是“扫描器一键出报告”的花架子而是把攻击面发现、越权检测、结果验证三个环节串起来的完整工作流。crAPI 提供了一堆故意埋好的漏洞接口Hadrian 负责把 API 端点和暴露资产摸清楚Vespasian 则基于请求模板自动做越权比对。三者的组合非常贴合真实安全测试的流程也适合拿来给团队做内部培训演示。1. 为什么是越权漏洞为什么是这套工具组合1.1 API 越权漏洞的核心场景与检测难点越权漏洞说白了就两类水平越权和垂直越权。水平越权指的是两个同级别用户之间互相访问对方数据比如用普通账号 A 的令牌直接请求账号 B 订单详情接口结果返回了 B 的收货地址、手机号。垂直越权则是低权限用户执行了高权限操作比如普通用户调用管理员删除接口。这两类问题的根源都是“只验证了身份没验证权限”这在 RESTful API 里太常见了因为很多开发者的习惯是“有登录态就放行”。为什么越权漏洞这么难检测因为它不是靠特征签名就能匹配出来的问题。SQL 注入可以靠报错信息、时间延迟来判断XSS 可以靠 payload 回显来识别越权完全是业务逻辑层面的漏洞——同一个接口对不同用户返回的数据不同这才是正常现象问题在于“返回了本不该返回的数据”。自动化工具要做的事情是判断“当前请求是否访问了超出当前用户权限范围的资源”这需要大量的上下文信息比如资源归属关系、用户角色边界、业务对象之间的关联。纯手工测试当然能准确判断但接口一多人力根本扛不住。还有一个现实问题很多团队的 API 文档不完整甚至没有。你在测试的时候得先摸清楚系统到底有哪些接口、哪些资源最容易出现越权。没有攻击面清单越权检测就是无源之水。所以一个完整的自动化检测方案必须包含“找接口”和“测越权”两个环节这也是我选择 Hadrian Vespasian 组合的根本原因。1.2 Hadrian Vespasian crAPI 的组合逻辑为什么要同时用三个项目因为它们解决的问题完全不同。crAPI 是 OWASP 维护的漏洞靶场全称是 Completely Ridiculous API里面故意埋了大量真实的 API 漏洞包括 IDOR、批量赋值、SSRF 等专门用来训练和验证安全工具的检测能力。它的存在意义是你不需要在未经授权的真实系统上测试工具先在靶场上把链路跑通再去实际项目中复用这套流程。Hadrian 是 Datadog 开源的自动攻击面发现平台它的设计目标是从多个维度收集目标系统的资产信息包括子域名枚举、DNS 记录分析、源码仓库扫描、开放接口识别最终产出一份可视化的攻击面地图。我们需要的就是它的“API 端点发现能力”——把 crAPI 的全部接口都收集起来形成待测清单。Vespasian 同样是 Datadog 开源的自动化越权检测工具专注于验证三种授权漏洞IDOR、Mass Assignment、Broken Function Level Authorization。它不靠漏洞库匹配而是通过构造关联请求、对比响应差异来判定越权是否成立这是非常实用的设计思路。从工作流上看三者的链条是这样的先部署 crAPI 作为目标靶场再用 Hadrian 对 crAPI 做攻击面发现拿到接口清单然后把请求模板导入 VespasianVespasian 自动遍历关联资源判断越权。整个过程只需要少量人工介入就能得到一份有据可查的越权检测结果。2. 环境准备与 crAPI 靶场部署2.1 运行环境与资源要求在搭建这套环境之前先确认机器配置。我的测试机是一台 8 核 16G 内存的 Ubuntu 22.04 服务器纯测试环境不跑其他业务。如果你的配置低一些至少保证 4 核 8G因为光是一套 crAPI 就有 8 个左右的微服务容器在跑Hadrian 和 Vespasian 也要各自起一组容器内存不够会出现容器反复重启、日志疯狂刷屏的情况。依赖项方面需要提前装好 Docker 和 Docker Compose 插件。我用的是 Docker 24.x 和 Compose v2 的独立二进制国内网络环境下拉取镜像可能会慢建议提前配置好镜像加速器。另外Hadrian 的部署依赖 PostgreSQLVespasian 依赖 RabbitMQ这些在它的 docker-compose 文件里已经定义好了不需要你单独去装。提示三套系统占用端口比较多crAPI 默认使用 8888 端口MailHog 使用 8025 和 1025Hadrian 的 UI 默认在 8000Vespasian 的 Cloud Console 默认在 3000 左右。正式部署前最好先检查端口占用情况避免冲突。2.2 crAPI 完整部署步骤crAPI 的部署方式很友好官方提供了打包好的 docker-compose 文件。我可以在这里贴上基于我实际操作整理的步骤这个流程对照官方 README 做了一些调整主要是补上了邮箱配置和 hosts 映射。# 1. 拉取代码 git clone https://github.com/owasp/crAPI.git cd crAPI # 2. 部署前先看一眼 docker-compose.yml确认服务定义 # 特别关注 web、identity、community、workshop、mailhog 这几个服务 # 3. 后台启动全部服务 docker compose up -d # 4. 查看服务状态确保所有容器处于 Up 状态 docker compose ps启动完成后crAPI 的前端页面就是 http://localhost:8888。正常情况下你会在页面上看到注册和登录界面。注册一个账号比如testexample.com密码按页面要求填crAPI 会发送一封激活邮件这封邮件发到了 MailHog 里而不会真的发到你的邮箱。MailHog 的界面在 http://localhost:8025打开就能看到所有发出的邮件。找到 crAPI 发来的激活邮件点里面的激活链接账号就激活了然后用这个账号登录。注意这一步非常关键不少新手在部署 crAPI 时先注册再激活流程顺序错了就登录不进去其实不是系统坏了是账号没激活。登录之后随便点几个页面发几个请求让系统产生一些业务数据。比如创建一个新的社区帖子、添加一辆车、发个评论这些都是后面 Vespasian 检测时需要用到的“关联资源”。我建议至少创建两三个不同用户的数据这样后面测试越权时才有足够的对比样本。2.3 验证靶场可用性的几个信号我通常用三个信号来判断 crAPI 是否部署成功。第一是容器状态8 个服务全部处于 healthy 状态第二是页面能正常注册登录并激活第三是接口能返回数据比如用浏览器开发者工具访问一个查询接口能看到 JSON 数据结构。如果发现接口返回 500 或者空白优先看两个地方一是 MailHog 的日志确认邮件发送服务是否正常二是数据库容器是否完成了初始化迁移crAPI 首次启动时 postgres 容器会执行数据库初始化这个过程可能需要几分钟期间访问页面会报错等初始化完成再刷新就好。3. Hadrian 部署与配置实战3.1 Hadrian 的架构与工作流程Hadrian 的设计思路是从攻击者的角度出发自动收集目标的所有暴露面并形成一条时间线。它内部有几个核心组件调度器、侦察器、扫描器、来源处理器和 UI。调度器负责任务编排侦察器执行各类信息收集任务扫描器对发现的资源做进一步探测来源处理器则分析代码仓库中的信息泄露。从安全测试的角度来看我觉得 Hadrian 最有价值的能力有两个。第一它能自动识别 API 接口并梳理请求方法、路径参数、认证方式第二它能分析目标应用的源码仓库发现硬编码的密钥和泄露的凭据。这在真实项目中非常实用因为不少越权漏洞背后的突破口恰恰是代码仓库里泄露的认证信息。Hadrian 整体同样通过 Docker Compose 部署依赖 PostgreSQL 做数据存储。整个系统部署完成后你只需要配置好目标它就会自动跑完侦察和扫描流程最终的发现结果汇总在 UI 上。3.2 部署 Hadrian 并接入 crAPI 目标先拉代码然后编辑配置文件把 crAPI 添加为扫描目标。我这里给一个简化版配置以实际项目仓库的说明为准git clone https://github.com/DataDog/hadrian.git cd hadrian # 复制环境变量模板 cp .env.example .env # 编辑 .env设置数据库密码、应用密钥等字段 # 编辑配置文件添加入口 URL 和目标标识 # 配置文件的格式依据项目 README 填写配置完成后启动服务。Hadrian 首次启动同样需要等数据库初始化然后 UI 会自动监听在配置的端口上。进入 UI 后把需要扫描的域名和目标标识添加进去。这里我们添加的是 crAPI 的地址。添加完目标Hadrian 的调度器会自动开始跑侦察和扫描流程。这个过程我实际观察下来大概需要十几分钟到半小时取决于目标系统的复杂程度和网络情况。同时候可以手动触发一些任务比如跑 TruffleHog 去扫描源码仓库里的密钥或者对已知的 API 接口做进一步探测。跑完后在 UI 的 Discovered Findings 页面就能看到结果了。以 crAPI 为例你会看到一系列被自动发现的 API 端点包括/identity/api/v2/user/me、/community/api/v2/post、/workshop/api/v2/vehicle这样的路径还会显示这些端点需要的认证方式和可能存在的资源变量。到这个阶段攻击面清单已经有了。3.3 从 Hadrian 结果中筛选越权候选接口拿到了接口清单不意味着全部接口都需要测越权你需要做一次初筛。我的筛选思路是三个维度接口是否涉及用户私有数据、是否包含资源标识符参数、是否需要认证。凡是符合这三个维度的接口都优先进入 Vespasian 的检测列表。举个例子crAPI 里有这样一个接口/identity/api/v2/vehicle/ownership/{id}路径里的{id}是车辆所有权记录的编号返回的数据包含车辆信息和车主的联系方式。这种接口就是典型的越权候选。而像/identity/api/v2/user/login这种登录接口没有资源标识符也不涉及私有数据就没必要浪费检测资源。4. Vespasian 越权检测原理与部署4.1 Vespasian 的三种检测模式Vespasian 的检测原理和传统的 Web 漏洞扫描器完全不同。它不依赖攻击载荷库而是采用了一种“对照验证”的思路为系统定义一组测试请求然后让工具自动生成“平行”请求把关联资源替换成其他用户的数据观察响应的变化。具体来说Vespasian 支持三种检测模式。IDOR 检测是最核心的它会自动选取目标请求中的某个参数作为资源标识符将其替换为另一个用户的资源标识符然后向服务器发起请求对比响应内容。如果响应中出现了本不该出现的其他用户数据就意味着存在 IDOR 漏洞。Mass Assignment 检测关注的是批量赋值场景。很多框架会自动把请求体中的字段映射到对象属性攻击者如果多传一个roleadmin字段就可能覆盖服务端的权限控制。Vespasian 会向目标请求中添加额外的字段并观察这些字段是否影响了响应的数据。Broken Function Level Authorization 检测则聚焦于功能级权限。它通过调用那些本应仅限于特定角色使用的接口看服务端是否做了正确的权限校验。比如普通用户是否能够调用管理员的删除接口或者未认证用户是否能够访问需要认证的接口。4.2 Vespasian 部署与请求导入Vespasian 的部署方式依然是 Docker Compose这里只记录关键步骤git clone https://github.com/DataDog/vespasian.git cd vespasian # 按 README 说明复制并修改环境变量文件 # 设置数据库、RabbitMQ、Cloud Console 等服务的初始化参数 # 启动全部服务 docker compose up -d服务启动后访问 Cloud Console 的 Web 界面首次使用需要初始化管理员账号。之后需要导入请求数据Vespasian 支持多种导入方式我实际用得比较多的是通过 Cloud Console 手动添加请求以及通过 API 批量导入请求。批量导入是真实项目里最常用的方式。如果你的目标系统有 OpenAPI/Swagger 文档可以直接转换成 Vespasian 支持的测试请求模板如果没有现成文档就从浏览器开发者工具里导出 HAR 文件再写个小脚本转换成 Vespasian 格式。4.3 配置目标主机与认证会话导入请求后还需要做两件事才能进行有效检测。第一是配置目标主机让 Vespasian 知道请求应该发到哪里第二是配置认证会话让它能够使用合法账号发起测试请求。我的操作方式是在 Vespasian 的配置里添加一条目标主机记录指向 crAPI 的地址。同时在请求模板中加入一个合法的认证令牌。crAPI 的认证机制比较简单登录后会返回一个 JWT把这个 JWT 放入请求头即可。这里有一个很重要的注意点测试时使用的认证令牌必须来自一个真实的测试账号而且这个账号的数据状态要可预期。你可以在 crAPI 里事先创建两个测试用户分别生成各自的 JWT这样在检测时有充分的对比基础。5. 联合实操完整检测链路跑通5.1 从 Hadrian 到 Vespasian 的数据流转当我把 Hadrian 和 Vespasian 都部署好以后就开始实际操作完整的链路。第一步是从 Hadrian 的发现结果中导出 API 端点清单其实不用真的“导出文件”直接在 UI 上对照把选中的接口整理成结构化清单就行。第二步把接口清单转换成 Vespasian 可识别的请求模板。这里我踩过一个小坑Vespasian 的请求模板虽然支持 HTTP 方法和 URL 路径但每个请求必须明确标注哪些参数是资源标识符否则它只能做基础的功能级权限检测无法做 IDOR 替换。在模板配置里要给{id}参数打上resource_id标签。整个准备过程大概花了 30 分钟主要是整理请求模板和配置认证信息的时间。如果你对目标系统的接口已经很熟悉这个过程会更快。5.2 执行检测与结果解读配置完成后在 Vespasian 中启动一次检测任务。它会自动执行一系列测试请求原始请求、替换资源标识符后的请求、添加额外字段后的请求等。整个任务在 crAPI 上跑完只用了两三分钟因为接口数量不算多而且 Vespasian 的执行速度很快。查看检测结果时Vespasian 会给每个测试用例标记状态有漏洞、可能有漏洞、无漏洞。重点看“有漏洞”的条目结合请求响应的具体内容来判断漏洞类型和危害程度。我在 crAPI 上跑出来的典型结果包括通过修改车辆所有权接口的资源标识符成功查看了其他用户的车辆信息在创建车辆接口的请求体中添加id字段成功覆盖了服务端分配的编号。这些都是越权问题的直观体现。我建议把检测结果整理成一份表格列清楚接口路径、漏洞类型、请求示例、影响范围。这份表格可以直接作为安全测试报告的附录也可以作为复测验证的基线。5.3 误报排查与人工验证方法自动化工具偶尔会有误报这一点必须接受尤其是越权检测这种强业务逻辑相关的场景。遇到 Vespasian 报“有漏洞”的条目我的处理方法是先看响应内容再手工重放一遍请求确认漏洞是否真实存在。排查思路是这样的如果替换资源标识符后的响应状态码是 200且响应体中包含其他用户的数据基本可以确认为真实 IDOR 漏洞如果状态码是 200 但响应体为空或返回了正常的空白资源通常是业务逻辑“返回了空对象”不构成越权如果状态码变成 403 或 401说明服务端做了权限校验这就是误报。另外要注意数据的脏影响。Vespasian 做批量赋值测试时会额外发送一些字段有些字段可能会改变服务端的数据比如覆盖数据库记录。测试前要确认目标环境是隔离的测试环境而且数据可恢复否则检测本身就成了一种破坏性的操作。6. 常见问题与避坑指南6.1 部署与联动问题速查表部署过程中遇到的问题大概有一半是端口冲突剩下的是环境变量配置和容器初始化顺序问题。我把这段时间遇到的典型问题整理成一张表方便大家对照排查问题现象可能原因解决办法crAPI 容器反复重启内存不足或数据库初始化未完成增大内存分配等待数据库迁移完成后再访问页面crAPI 注册后无法登录账号未激活在 MailHod 中查看激活邮件并点击激活链接Hadrian UI 无法访问端口映射配置错误或数据库未就绪检查 docker compose 的端口映射确认 postgres 容器状态Hadrian 扫描不产生结果目标地址配置错误或网络不通检查目标配置确认 crAPI 可从 Hadrian 容器内访问Vespasian 请求导入失败请求模板格式不符合要求对照 README 中模板格式逐项检查尤其注意请求头字段检测结果全部为误报认证令牌过期或未正确配置重新生成登录令牌确认令牌已正确填入请求模板检测时请求超时目标系统并发连接限制降低测试并发数或延长请求超时时间6.2 个人实操心得与几点建议整套流程跑下来我最大的体会是自动化越权检测工具不能替代安全测试人员的判断能力但能大幅提升效率。一个中等规模的 API 应用可能有上百个接口纯手工测 IDOR 至少要一两天而 Vespasian 配合一份请求模板十几分钟就能跑完第一轮之后人工只需要聚焦在少量可疑结果上效率提升非常明显。另外建议团队把 crAPI 作为“工具验收场”。任何新的安全测试工具、新的检测脚本先在 crAPI 上跑一遍看看它能不能识别已知漏洞。这样既不会在真实系统上误操作也能快速评估工具的实际检测能力。我在验证多个工具时都用了这个方法可以避免不少“纸面强大、实际鸡肋”的工具。最后再分享一个小技巧做越权检测时请求模板的质量直接决定结果质量。不要只导入正常业务请求还要加入一些边界场景的请求比如删除操作、权限变更操作、批量查询操作。这些操作往往是最容易出现越权的。在 crAPI 这种靶场上多试几种模板设计方式再迁移到真实系统你的检测覆盖率会高很多。