API越权漏洞自动化检测：基于crAPI与Hadrian的完整实践

如果你也测过那种动辄几十个端点的后端 API你一定体会过越权漏洞测试的魔性登录两个账号来回换 ID盯响应里某个 id 字段放大看是不是别人的数据。一遍两遍还行接口一多人就开始眼花了而且这种重复劳动恰恰最容易漏——越权漏洞本来就是 OWASP API Security Top 10 里常年排第一的问题偏偏又是传统扫描器最不擅长的部分。这次我完整跑了一遍靶场 自动化编排的流程用 OWASP 维护的 crAPI 当靶子用 Hadrian 做扫描流水线编排用 Vespasian 做并行执行器目标是让 API 越权漏洞的检测从纯手工变成半自动化。整套东西从部署到出第一份能用的检测结果大概花了两天中间踩了不少坑这篇就当一份完整部署与使用文档来写顺便把原理也讲清楚。不管你是刚接触 API 安全测试还是已经在用各类扫描器的老手这套组合的思路都值得参考。1. 越权漏洞为什么这么难自动化先搞清楚你面对的问题是什么1.1 越权、IDOR、BOLA、BFLA 到底是啥关系很多人一提到越权脑子里就只有改个 ID 就能看别人数据这其实只是其中一种。安全圈里这几个词经常混着用但含义有区别IDORInsecure Direct Object Reference最早出自 OWASP Top 10 的概念指的是应用直接使用用户提供的对象 ID比如数据库主键去查询资源且没做归属校验。最典型的就是把请求里的 id 从 1 改成 2。BOLABroken Object Level AuthorizationOWASP API Security Top 10 里的 API1可以理解为 IDOR 在 API 场景下的正式名称强调对象级别的访问控制缺失。BFLABroken Function Level AuthorizationAPI 场景下的垂直越权普通用户能调用管理员功能比如直接访问/admin接口或给普通账号加权限。水平越权 vs 垂直越权前者是同一权限级别下的横向越权A 访问 B 的数据后者是低权限访问高权限功能。在 crAPI 这个靶场里这两种类型都有覆盖。理解这些分类不只是为了写报告而是为了设计自动化检测规则——水平越权需要两个平级账号做差分垂直越权则需要一个低权限账号去碰高权限端点检测逻辑完全不同。1.2 自动化工具处理不了业务身份这个上下文传统扫描器为什么拿越权漏洞没办法因为它们擅长的是特征匹配发一个恶意 payload看响应里有没有 SQL 报错、XSS 特征、版本指纹。但越权漏洞的特征藏在业务逻辑里——接口返回了 200数据也正常唯一的问题只是这份数据不属于当前登录用户。举个具体例子。对GET /api/coupon/123这个接口普通扫描器发请求收到 200 和一堆 JSON 字段它就认为正常。但真正的越权场景是用户 A 登录后把 123 换成 124收到的还是 200而 124 是用户 B 的优惠券。扫描器没有谁拥有这张券这个业务上下文它无法判断这个 200 到底是正常还是越权。这也是为什么我说纯自动化扫描在越权检测上必然有天花板。要让自动化真正起作用必须把业务判断规则喂给工具谁是对象所有者、哪些接口需要对象归属校验、哪些接口属于管理面。1.3 我采用的自动化检测策略接口发现 差分对比针对越权漏洞的特点我这次采用的策略分三个阶段这也是后面所有配置的逻辑基础接口发现先把目标应用有多少 API 端点、每个端点有哪些隐藏参数摸清楚。这一步完全可以交给 Hadrian 流水线里的内容发现和参数枚举工具去做。差分对比对每个业务接口用用户 A 的 token、用户 B 的 token、匿名 token三个身份分别请求并对 ID 类参数做遍历比较三组响应。如果 A 能拿到 B 的数据或者匿名能拿到登录用户的数据就是越权的强信号。人工复核自动化产出的是候选清单最终确认还需要人来看一眼业务逻辑判断是不是误报比如有些接口本来就是设计成公开的。这个策略里Hadrian 负责第 1 阶段的海量枚举自制的差分脚本负责第 2 阶段人负责第 3 阶段。后面第 5 节我会详细写怎么把差分脚本接进 Hadrian 的流水线。2. crAPI 靶场部署先把漏洞靶子立起来2.1 crAPI 是什么能测什么crAPI 全称 Completely Ridiculous API是 OWASP 维护的故意存在漏洞的 API 靶场。它模拟了一个真实的车辆服务场景注册用户、发帖子、绑定车辆、查车辆位置、领优惠券、找技师……这些业务对应着一整套 RESTful API 接口并且按照 OWASP API Security Top 10 埋了各种漏洞。为什么选它当靶子因为越权检测的验证离不开标准答案。crAPI 的漏洞是已知的我在上面做自动化检测每一项告警都能对照官方漏洞列表和已有 writeup 验证我的检测规则到底准不准。等规则验证可靠了再拿去测自己负责的真实项目心里才有底。它也是很多 API 安全课程和认证比如各类 API 渗透测试培训的标配靶场。和越权直接相关的靶点大概覆盖这几个方向社区帖子接口的对象级越权可以查看或操作其他用户的内容车辆位置接口的 BOLA通过遍历车辆 ID 获取他人车辆位置管理员功能接口的 BFLA普通 token 直接访问管理端点接口响应过度暴露明明只需要用户名却把邮箱、手机号等敏感字段一起返回了2.2 Docker Compose 一键部署与端口说明我用的部署方式是最省事的 Docker Compose 方案在 Linux 服务器上执行git clone https://github.com/OWASP/crAPI cd crAPI/deploy/docker docker compose up -d首次执行会拉取多个镜像耐心等一会儿。起完之后用docker compose ps查看容器状态正常情况下你会看到这几个服务服务作用对外端口web前端页面8888gatewayAPI 网关统一入口8085identity身份认证服务8080community社区帖子服务8081workshop车辆/技师业务服务8082mailhog邮件捕获服务8025 / 1025验证靶场是否正常最快的方式是直接请求网关curl http://localhost:8085/identity/api/v2/...能返回 JSON 说明网关和各个后端服务是通的。前端页面http://localhost:8888能打开的话整体就没问题了。2.3 准备两个用户和 Token自动化测试的燃料越权差分检测最少需要三个身份用户 A、用户 B、匿名。所以部署完 crAPI 之后第一件事就是用脚本批量注册两个账号并拿到 token这一步一定要自动化否则后面没法跑。注册接口长这样curl -X POST http://localhost:8085/identity/api/v2/auth/register \ -H Content-Type: application/json \ -d {email:user_aexample.com,password:Passw0rd!,nickname:usera,name:User A}crAPI 注册后会发一封验证邮件到注册邮箱邮件由 MailHog 捕获。自动化的接法是直接调用 MailHog 的 API 取信curl http://localhost:8025/api/v1/messages从返回内容里提取验证链接然后模拟浏览器访问它完成验证。验证完成后再调登录接口拿 access tokencurl -X POST http://localhost:8085/identity/api/v2/auth/login \ -H Content-Type: application/json \ -d {email:user_aexample.com,password:Passw0rth!}这里有个小技巧crAPI 的邮件验证本质上是带 token 的重定向脚本里可以直接拼接验证接口也可以干脆在环境里控制 MailHog 自动放行。怎么方便怎么来关键是注册-验证-登录这个流程要能一键跑完。2.4 部署 crAPI 常见的三个坑端口被占用8888、8025、8080 这些都是常见服务的默认端口本地环境很容易冲突。改端口时要注意改docker-compose.yml里的端口映射同时前端页面里写死的后端地址可能也要跟着调整建议直接换一台干净的机器或用独立的云主机部署。内存不足crAPI 全量启动需要不少内存我实测 4G 内存的机器会明显卡顿甚至 OOM。如果资源紧张可以只起必需服务identity、community、workshop、gateway、mailhog前端 web 可以不起因为自动化测试根本不依赖页面。版本漂移crAPI 一直在更新不同版本的服务名、端口、接口路径都有差异。建议git log看一下当前版本或者直接固定到你验证过的那个 commit不然照着老教程写脚本很容易踩接口 404 的坑。3. Hadrian 和 Vespasian 的架构拆解调度器与执行器3.1 Hadrian 的 Signal / Trigger / Action 流水线模型Hadrian 是一个把多个开源安全工具组织成自动化流水线的编排框架核心模型是信号Signal、触发器Trigger、动作Action。Signal信号扫描过程中产生的某种事实。比如发现 80 端口开放确认目标运行 Nginx枚举到一个新的 API 路径发现响应里有关键字。信号是流水线的燃料。Trigger触发器定义什么情况下要启动什么动作。比如当发现 HTTP 服务时触发指纹识别。触发器本质上是信号的条件判断。Action动作真正干活的工具调用比如跑一遍 whatweb、跑一遍 arjun、跑一遍 sqlmap。这套模型的价值在于工具之间不再是各扫各的孤岛而是前一个工具的结果决定后一个工具跑不跑。传统思路是拿一个大而全的扫描器对目标一通狂扫Hadrian 的思路是先发现服务再针对服务类型精准调用对应工具。扫描资源被用在刀刃上结果也更结构化。对越权检测来说Hadrian 最有价值的部分不是它内置的某个扫描器而是它的编排能力我可以把接口发现和差分检测串成一条链路让枚举出来的每个 API 端点自动进入越权检测流程。3.2 Vespasian 的并行容器执行模型Vespasian 解决的问题很实际Hadrian 动辄要跑十几个工具如果串行执行一个扫描跑一晚上都不稀奇如果手动并行管理容器状态、超时、资源回收全是麻烦。Vespasian 就是那个并行执行引擎。它的工作方式是通过 REST API 接收任务每个任务被封装在一个隔离环境里运行支持并发调度、超时回收、失败自动重试。任务跑完以后再通过 API 把状态和日志交还给调用方。Hadrian 通过环境变量VESPA_API连接到 Vespasian所有 Action 都被提交成一个个独立任务。打个比方Hadrian 是项目经理按图纸安排工序Vespasian 是施工队长一声令下让各班组并行开工哪个班组的活干砸了就重新派人。项目经理不用关心工人怎么调配施工队长也不用关心整个工程的设计图。3.3 为什么拆成两个组件而不是一个大单体我第一次看这个架构的时候也在想为什么不干脆做成一个工具实际跑完以后就明白了拆开的好处非常实际职责分离编排逻辑什么时候跑什么工具和资源调度逻辑怎么并发、怎么重试是完全不同的两类复杂度拆开以后各自可以独立演进。可扩展性想接入一个新工具只需要在 Hadrian 侧加一个 Action在 Vespasian 侧准备一个工具镜像其他事情都不用动。这比往大单体里加功能安全得多。容错隔离某个工具镜像崩溃最坏情况就是 Vespasian 重试几次后放弃不会影响整个扫描流程。理解这个架构你才能知道部署时每一步是在干什么出了问题也知道去哪查。4. Hadrian Vespasian 部署与首次扫描完整操作记录4.1 环境准备该装的东西一个都不能少我这次用的是一台 Ubuntu 22.04 服务器内存 16G磁盘还剩 40G。除了常规的 git、curl、jq核心依赖还有两个DockerVespasian 支持 Docker 后端和 Firecracker 微虚拟机后端。Firecracker 隔离性更强、开销更小但配置复杂需要准备专门的微 VM 镜像本地测试用 Docker 后端就够了稳定也好排错。Node.js 16Hadrian 用 TypeScript 写的需要 Node 环境来编译和运行。建议先把这些环境变量规划好后面所有步骤都会用到export VESPA_APIhttp://localhost:9001 export REPORT_NAMEcrapi-idor-scan4.2 Vespasian 启动与验证Vespasian 来自 Novarese 团队和 Hadrian 是同一个项目体系。部署方式看官方 README我当时走的是Docker 镜像 宿主机运行的路子git clone https://github.com/novarese/vespasian cd vespasian make docker-image docker run -d --name vespasian \ -v /var/run/docker.sock:/var/run/docker.sock \ -p 9001:9001 \ vespasian:latest启动后验证一下 API 是否响应。Vespasian 的端口和接口路径在不同版本里会有差异以你拉到的 README 为准我当时是直接 curl 根路径能返回版本信息就算起来了。4.3 Hadrian 编译、配置与工具镜像准备Hadrian 这边先把代码拉下来编译git clone https://github.com/novarese/hadrian cd hadrian npm install npm run build编译成功后Hadrian 的运行入口在build/src/index.js。这里有一个非常容易被忽略的步骤工具镜像准备。Hadrian 本身不打包工具它只是编排真正跑的 arjun、sqlmap、whatweb、ffuf 全靠 Vespasian 去拉取或加载镜像。我第一次就是漏了这一步扫描卡在等待 Vespasian 执行半天不动日志里全是镜像拉取失败。工具镜像的准备方式同样是看 README确认哪些工具镜像需要先构建哪些能从仓库直接拉。建议在正式扫描前先用一个最简单的工具镜像比如 whatweb手动提交一个任务到 Vespasian验证整条链路是通的再上 Hadrian 全量扫描。4.4 跑通第一次扫描目标选对范围收紧首次扫描建议只针对 crAPI 的网关端口别把 MailHog 的 SMTP、各服务的内部端口都扫进去否则噪声会淹死你。我执行的命令大致是node build/src/index.js scan -t http://localhost:8085 -p 8085-t指定目标地址-p指定端口列表。Hadrian 的具体参数名和默认值在不同版本会有差异跑之前先node build/src/index.js scan --help确认一下。这里有个网络细节要特别注意crAPI 和 Hadrian/Vespasian 如果跑在同一台机器上Vespasian 里启动的工具容器访问目标是按容器视角去理解的。也就是说工具容器里的localhost:8085指的是容器自己不是宿主机。这时候目标地址要么填宿主机在 docker 网络里的 IP要么填host.docker.internal:8085否则所有探测都会失败。这个坑我一开始没意识到浪费了不少时间。4.5 首次扫描结果长什么样扫描跑完后报告会在report/目录下生成通常是 JUnit XML 和 JSON 格式。里面记录的是整条流水线发现的事实目标开放了哪些端口、跑了什么 Web 服务、指纹识别结果、枚举出了哪些路径和参数、某些工具是否发现了可疑输入点。需要注意的是这份报告对越权检测的意义是线索不是结论。比如它可能告诉你发现了/workshop/api/v2/vehicle/这个路径你得自己意识到这个路径带着对象 ID 参数然后把它送进差分检测流程。把 Hadrian 当API 接口清单生成器来用才是这套流水线的正确打开方式。5. 把越权检测接进流水线在 crAPI 上的实战配置5.1 默认流水线里哪些结果对越权检测有用Hadrian 默认跑的很多工具表面上看和越权无关实际上都在为越权检测铺路。我在 crAPI 上实测下来最有用的三类结果内容发现结果ffuf/dirsearch/gobuster 这类帮我找到了容易漏掉的 API 路由包括管理端点。crAPI 里有些功能级越权端点就是藏在路径枚举里的。参数发现结果arjunarjun 能猜测 URL 里的隐藏参数。对越权检测来说发现id、vehicle_id、order_id这种对象引用参数就等于锁定了差分测试的注入点。响应中的敏感字段响应体里如果出现了邮箱、电话、内部 ID自动化脚本可以据此判断该接口是否存在过度暴露问题。所以我的建议是先让默认流水线完整跑一遍把 crAPI 的接口面摸清楚再进入下一步的定制检测。不要一上来就跳过默认流程。5.2 自制一个 IDOR 差分检测脚本并挂成 Action这是整套方案里最关键的一步。我用 Python 写了一个差分检测脚本核心逻辑是输入目标路由模板比如/workshop/api/v2/vehicle/{id}/location准备三份身份凭据用户 A 的 token、用户 B 的 token、匿名把{id}从有效值范围比如 1 到 50遍历对每个 ID分别用三个身份请求记录状态码和响应体判定规则用户 A 拿到了属于用户 B 的对象数据 → 疑似水平越权匿名请求拿到了登录用户才能看的数据 → 疑似认证缺失响应体里出现了非当前用户的所有者字段 → 疑似过度暴露写完脚本后把它接进 Hadrian。做法是在 Hadrian 里注册一个自定义 Action触发器绑定到发现新的 API 路径这类信号上这样 Hadrian 每枚举出一个新端点都会自动把它提交给差分脚本检测。这里必须强调一个合规前提这套差分脚本只能打在你有授权的目标上。我是在本地 crAPI 靶场验证的crAPI 官方也鼓励安全测试者在靶场上练习。对不在授权范围内的系统做这种检测性质就完全不一样了这一点务必守住。5.3 crAPI 越权靶点的验证结果示例我在 crAPI 上实际验证到的几个越权场景全部来自真实请求你可以拿自己的靶场环境复测对照接口越权类型现象GET /workshop/api/v2/vehicle/{id}/locationBOLA用户 A 遍历车辆 ID能拿到其他用户车辆的 GPS 坐标GET /community/api/v2/posts过度暴露帖子里包含作者邮箱等多余敏感字段且可按帖子 ID 定向访问他人数据GET /identity/api/v2/xxx/admin一类管理端点BFLA普通用户 token 直接访问管理接口未做功能级鉴权每条候选结果我都做了人工复核确认请求用了哪个 token、返回的数据确实属于另一个用户、业务上没有本来就该公开的合理性。只有这三条都满足才敢把它定为越权漏洞。自动化负责找到可疑的点人负责确认它是不是真的洞。5.4 结果去重与误报治理让报告能交得出手自动化检测最容易产出一堆重复告警。同一个vehicle接口遍历 50 个 ID 就可能爆出 50 条疑似越权如果直接交出去报告没法看。我的经验是按路由 HTTP 方法做聚合把同一端点的所有实例合成一条告警详细信息用表格附在后面。误报治理我更看重两个方向区分 401 和 403有些接口匿名访问返回 401说明它至少做了身份校验只是授权逻辑有问题有些接口匿名直接返回 200 数据这是完全不同的严重级别。我会在脚本里区分未认证可访问和认证后横向越权分别上报。关联业务语义自动化报出来以后必须抽查原始请求和响应。有的越权其实是接口设计上允许的共享功能比如好友位置共享不能按越权报。这一关只能人来把关自动化做不了。6. 踩坑清单与落地建议两天实测的经验沉淀6.1 环境与网络类故障我踩的第一个坑是 Vespasian 里的工具容器访问不到宿主机上的 crAPI。原因前面说过容器里的localhost不是宿主机。换成host.docker.internal以后所有探测立刻正常。如果你也一样把靶场和测试工具放在同一台机器上建议第一时间确认这一点。第二个坑是 crAPI 和 Hadrian 抢资源。两个系统加起来十几个容器小内存机器直接卡死。我的解决办法是分开部署crAPI 放一台轻量服务器Hadrian Vespasian 放另一台或者干脆给宿主机加内存。别小看这个问题资源不足会导致 Vespasian 任务超时而你很难区分是工具执行失败还是容器被 OOM 杀掉。6.2 工具链路与版本类故障Hadrian 的信号名、Action 配置格式在不同版本里改过多次。我一开始照着旧文配 Action跑起来完全没反应后来直接去源码里翻config/目录下的实际配置才解决。建议以你 clone 下来的源码为准GitHub 上的 README 和源码永远比二手教程靠谱。另一个容易踩的是 arjun、sqlmap 这类工具镜像的问题。有的镜像缺少运行时依赖有的工具参数和 Hadrian 默认配置不一致导致 Action 报错。我的做法是先手动 docker run 一次目标镜像确认工具本身能跑通再交给 Hadrian 编排。这个习惯帮我省掉了大量排错时间。6.3 自动化越权检测的正确预期两天的实测让我对自动化越权检测有了更清醒的认识。自动化能高效解决的是机械劳动接口发现、参数枚举、ID 遍历、响应对比。它很难解决的是业务理解这个对象是不是该共享这个字段是不是该暴露这个管理端点是不是本来就该对特定角色开放所以我的结论是不要把 Hadrian Vespasian crAPI 这套组合当成一键找越权的黑盒工具它真正的定位是接口面发现引擎 差分检测执行平台。它帮你把候选清单压缩到人能审得过来的规模最终的判断还是要人来下。自动化越权的价值在于广覆盖、快筛排而不是零误报、全自动。6.4 我的最终配置建议最后整理几条我自己验证过、比较稳的配置习惯crAPI 固定版本clone 之后记下 commit或者用镜像 tag 固定版本避免上游更新导致文档和脚本失效。扫描范围收紧只扫网关端口把 MailHog、SMTP、内部服务端口排除在外报告噪声会小很多。先验证最小链路先用一个简单工具镜像验证 Vespasian 能跑任务再上 Hadrian 全量编排出现问题能快速定位是编排层还是执行层。给 Action 设超时和重试避免某个工具卡死把整个流水线拖住。Vespasian 本身支持重试在 Hadrian 侧也建议显式配置。所有结果统一出 JSON把差分脚本的原始输出、Hadrian 的报告、人工复核结论汇总到一个 JSON 文件里方便后续生成高参考价值的阶段性测试报告也方便下一次回归测试时做差异对比。这套环境跑通以后我的日常流程变成了新项目接入时先用默认流水线扫一遍接口面再把接口清单喂给差分脚本做越权快筛最后人看疑似清单。比起以前纯手工换 token、换 ID 的时代效率提升是非常明显的。如果你正在头疼 API 越权测试怎么提效这个组合值得照着搭一遍crAPI 这种标准靶场也确实是最好的练手场地。