先说结论这套组合拳打下来API越权漏洞的检测效率确实比手动测高出一个数量级但前提是你得先搞明白工具背后到底在做什么。如果你对API安全测试还停留在“拿Burp点点点、手工改ID”的阶段那这篇文章就是为你准备的。1. 内容整体设计与思路拆解1.1 为什么选这三个东西组合在一起先聊个真实的痛点现在前后端分离架构普及之后API接口数量动辄上百个很多企业还存在版本迭代混乱、接口命名不规范的问题。越权漏洞IDOR/BOLA又是所有漏洞类型里最容易出现、也最容易被忽略的一类因为它不需要什么高深的技术就是“把A用户的ID换成B用户的ID”而已。但问题在于靠手工一个个接口去测效率低到让人怀疑人生。你得先注册两个账号再抓包分析每个接口的参数再逐个替换身份标识去验证。如果接口数量到了三位数这项工作基本就是噩梦。后来我在实际项目里把 Hadrian、Vespasian 和 crAPI 这套组合用起来发现它们正好各管一段crAPI提供一个有完整业务逻辑的靶场环境Hadrian负责把API机器人一样暴走地翻出来Vespasian负责验证哪些接口存在越权。三个工具拼起来正好覆盖了“有靶场 - 找接口 - 测越权”的完整链路。1.2 理解越权检测的核心逻辑越权检测说白了就两步第一步用低权限用户A的凭证去请求某个需要权限的接口第二步替换成高权限或另一个用户B的凭证看看返回结果有没有差异。如果不一样说明接口做了权限控制如果一样那恭喜你中奖了。但是这里有个容易被忽略的细节真正的越权检测不是简单的“返回状态码不同”而是要关心数据是否泄露、操作是否被成功执行。Vespasian在设计上考虑到了这点它会把请求结果做对比分析而不是简单看HTTP状态码。这个思路很重要因为实际业务场景里很多系统对越权请求会统一返回401或403但如果有其他路径可以绕过或者存在数据被静默写入的情况光看状态码根本发现不了。1.3 工具链的边界与适用场景说明任何工具的组合都有能力边界。Hadrian的核心能力是API资产发现和攻击面测绘它不是万能的扫描器不负责直接告诉你哪个接口存在漏洞。Vespasian做的是越权漏洞的辅助验证但它依赖你提供有效的身份凭证和请求模板。crAPI则是OWASP维护的一个开源API靶场模拟了真实的车联网业务逻辑专为练习API攻击设计。所以这套组合最适合的场景是你有一个API系统的访问权限拿到了普通账号和特权账号的凭证想自动化地、系统地排查一遍越权问题。它不太适合什么都不提供、只给一个URL就要求出结果的场景工具不是神前提条件还是要有的。把这三者的边界搞清楚后面用起来才不会觉得“工具不好用”而是知道每个环节该对工具抱有什么样的预期。2. 环境准备与部署细节2.1 靶场环境crAPI的搭建要点crAPICrellys API是OWASP维护的API安全靶场部署方式很简单但有几个坑要注意。推荐直接用Docker方式部署git clone https://github.com/OWASP/crAPI.git cd crAPI/deploy docker-compose pull docker-compose -f docker-compose.yml --compatibility up -d这里有个容易踩的坑新版Docker Compose命令和旧版有差异直接用docker-compose up -d可能会报版本不兼容建议加上--compatibility参数。部署完成后crAPI会启动一组容器包括Web前端、后端API、邮件服务和数据库。访问http://localhost:8888就能看到Web界面API基础地址在http://localhost:8888/api。crAPI最实用的地方在于它内置了完整的业务逻辑注册、登录、车辆管理、社区论坛、优惠券、机械师预约等模块一应俱全。这意味着你在练习越权测试时可以找到非常真实的业务场景而不是那种为了演示漏洞而造的假接口。还有个细节建议crAPI容器启动需要等一会儿尤其是邮件服务因为注册用户后需要去邮件服务里拿验证码。邮件服务默认在http://localhost:8025通过Web界面就能读取邮件不需要单独配置什么。2.2 Hadrian部署与配置全流程Hadrian是一个API攻击面发现工具它的核心能力是从各种来源提取API端点信息把它们汇总成结构化的清单。部署方式支持多种最省事的是用pipxpipx install hadrian-cli hadrian --help如果pipx方式失败也可以直接用Dockerdocker pull ghcr.io/securefoundation/hadrian:latest docker run -it ghcr.io/securefoundation/hadrian:latest --helpHadrian的原理是自动从Web流量、JavaScript文件、OpenAPI规范等来源中提取API端点然后整合输出。它有一个很重要的概念叫“API仓库”所有收集到的端点会统一存储并支持通过YAML文件手动补充。实际使用中最推荐的方式是先用浏览器正常访问crAPI的所有功能把流量保存成HAR文件然后用Hadrian解析这个HAR文件hadrian analyze -i traffic.har -o output_dirHadrian会识别出所有API请求的URL路径、方法类型、请求参数并输出为结构化的文档。这一步做完你手里就有一份比较完整的“接口地图”了不用再手动去翻浏览器开发者工具。2.3 Vespasian部署及与Hadrian的对接方式Vespasian是专门做越权检测的工具它和Hadrian是同一生态体系下的产品。它的工作方式是把API端点和两个不同权限的账户凭证喂给它它会自动生成测试用例发起请求并对比响应结果最后汇总成报告。安装Vespasian同样支持pipxpipx install vespasian-cli vespasian --helpVespasian需要用到Hadrian生成的API清单所以顺序是先跑Hadrian再跑Vespasian。如果你手里有现成的OpenAPISwagger文件也能直接导入VespasianAPI定义文件格式它也是支持的。值得注意的是Vespasian在初始化时需要指定两种凭证来源它会在检测过程中交替使用这两组凭证来发送相同的请求从而判断接口是否存在越权。这个过程不需要人工介入比较适合“挂机式”地批量检测。2.4 部署过程的避坑清单我整理了部署过程中最常遇到的几个问题问题原因解决方法crAPI启动后Web页面打不开容器未完全启动或端口冲突检查docker ps查看容器状态确认8888端口未被占用crAPI发邮件失败邮件服务容器异常重启mailhog容器确认8025端口可访问Hadrian解析HAR文件报错HAR格式不规范或字段缺失用浏览器开发者工具重新导出不要手动修改HAR文件Vespasian连接不上API仓库两个工具版本不匹配统一升级到最新版本避免API格式变化导致的兼容问题pipx安装失败依赖冲突或Python版本过低建议使用Python 3.10以上版本创建独立虚拟环境安装部署这块看起来简单但零碎的问题不少。我的建议是每一步都用命令验证一下结果别急着往下走否则后面出问题排查起来会很痛苦。3. 核心检测流程与实操过程详解3.1 先摸清crAPI的业务结构在真正开始跑工具之前我强烈建议你先手动过一遍crAPI的业务流程这不是浪费时间而是给后面自动化检测提供“业务视角”。crAPI的典型业务链路大概是这样的用户注册登录后可以创建自己的车辆每个车辆有对应的车辆ID用户能在社区发帖、评论可以领取优惠券可以预约机械师服务。熟悉这些业务之后你就能猜到哪些接口可能存在越权。比如车辆信息接口如果你在请求里把自己的vehicle ID换成别人的ID系统有没有校验当前登录用户和车辆归属是否一致再比如优惠券模块有些优惠券是系统发给特定用户的你能不能冒充别人领取这些逻辑问题手工测也能发现但用工具自动化去跑覆盖面会更广。3.2 使用Hadrian进行API资产梳理Hadrian的核心理念是“知道敌人在哪才能精准打击”。用它的方式有两种第一种是从流量文件提取。你需要先登录crAPI把Web界面上的所有功能点都点一遍确保请求覆盖到大部分API。然后通过浏览器开发者工具的“导出HAR”功能把整个浏览会话保存下来。拿到HAR文件后用Hadrian处理hadrian analyze -i capture.har -o crAPI_apis执行完成后Hadrian会在目录下生成多个文件包括API端点的清单列表、参数信息、认证头信息等。你可以直接查看它识别出了多少端点并检查哪些是带认证的、哪些是公用的。第二种是从OpenAPI规范文件导入。crAPI本身提供了Swagger文档入口你可以在浏览器里打开http://localhost:8888/api/docs导出OpenAPI JSON文件然后交给Hadrian解析。两种方式各有利弊HAR文件更接近真实使用状态但可能会漏掉没被触发过的接口OpenAPI文件更全面但某些内部接口可能没暴露在文档里。我的实际做法是两者都跑再把结果合并这样覆盖面最完整。3.3 配置Vespasian的身份认证信息Vespasian要正常工作必须知道“两个不同权限身份”的凭证。我通常这样操作首先在crAPI上注册两个账号一个叫user_a一个叫user_b两个账号都在系统里创建车辆、发帖、领取优惠券保证它们的业务数据都存在。然后分别获取两个账号的认证凭证通常是Bearer Token或JWT。在你执行Vespasian命令时它会提示你输入两个身份的凭证信息。这里的核心要点是两个账号的权限应当一样都是普通用户但持有不同的业务数据。越权检测的本质就是“普通用户A能不能访问到普通用户B的数据”而不是“普通用户能不能访问管理员功能”。如果你想连垂直越权普通用户访问管理员接口也一起测那就需要准备一个管理员账号和一个普通用户账号Vespasian同样支持这种模式。不过实际操作中垂直越权经常涉及业务逻辑漏洞工具能发现的概率相对低一些还需要结合手动测试。3.4 实战执行从检测到报告输出我现在把完整的执行命令串一遍方便你对照着操作。第一步确保crAPI环境正常运行。第二步准备好HAR文件或OpenAPI文件。第三步跑Hadrian生成API清单hadrian analyze -i capture.har -o apis执行过程中Hadrian会输出进度信息。第四步运行Vespasian执行越权检测vespasian run --repo ./apis --user-a-token token_A --user-b-token token_B运行期间Vespasian会遍历API清单中的所有端点用两个身份的凭证各发送一遍请求并对比响应的状态码、数据内容和关键字段。检测完成后它会输出一份报告标记出疑似越权的接口。需要注意Vespasian的检测不一定百分之百准确它可能会产生误报也可能漏报。看报告时不要直接认定“标记了就是漏洞”而是要根据报告里的请求和响应数据去实际手动复现验证。3.5 验证结果手动复现是必要的兜底自动化工具的价值在于帮你把“可疑范围”缩小但“定罪”还是得靠人工。我见过不少测试人员跑完工具后直接把报告截图交差这是很危险的。正确的做法是拿报告里标记的接口登录crAPI的Web控制台手动用两个账号重放请求。比如报告说某个车辆信息接口可能存在越权你就用自己的账号拿到一个车ID换个账号去访问这个ID对应的URL看能不能返回别人的车辆信息。只有手动复现确认过了这个漏洞才能在你的报告里作为“已确认”的发现。如果复现不出来那多半是工具出现了误判可能是请求参数格式不对、认证头没带上或者响应对比逻辑不适合这个接口的返回形态。4. 常见问题与排查技巧实录4.1 高频报错与对应解法我自己在实际部署和使用中遇到过不少问题这里挑几个典型的说一下问题1Hadrian解析HAR时提示文件格式错误。这个情况最常见的原因是HAR文件里包含了一些不完整的请求记录或者文件是从代理工具如Burp导出的而Burp导出的HAR有时会缺字段。解决办法是尽量从浏览器开发者工具导出并且导出前清理一下无用的请求记录只保留跟目标API相关的请求。问题2Vespasian检测过程中大量请求超时。crAPI部署在本机时一般不会超时但如果你的环境是远程部署的网络延迟会导致很多请求失败。建议在Vespasian的配置里适当调大超时时间同时确认网络稳定。另外并发请求数不要设置太高否则可能触发目标系统的限流机制。问题3两个账号的Token容易混淆。因为Vespasian需要同时使用两个凭证如果Token的格式长得像很容易弄混。建议在终端窗口里先用环境变量存好比如export TOKEN_AeyJhbGciOi... export TOKEN_BeyJhbGciOi...这样在命令行里引用时不容易出错也方便检查当前使用的是哪个身份。问题4检测报告中的接口路径和实际crAPI接口不一致。这种情况通常是HAR文件里记录了外部资源请求比如CDN、统计分析服务这些不是crAPI自身的API但也被Hadrian收录进去了。解决办法是在生成HAR文件时在浏览器开发者工具的Network面板里设置过滤条件只保留localhost:8888域名的请求。4.2 实操中的独家心得用这套工具体系跑了多个项目之后我总结了一些常规文档里不会写的经验经验1先手动画业务流程图再跑工具。虽然这个流程听起来很“传统”但实际上价值巨大。你只有清楚知道crAPI有哪些业务模块、模块之间怎么关联才能在工具生成报告后迅速判断哪些越权点是真的威胁哪些只是业务设计如此比如某些信息本身就是公开的。经验2Vespasian跑完不是终点OCR级别的重放验证才是。这句话的意思是工具告诉你“这两个接口可疑”你就要用最笨的方法去确认。我通常是开着浏览器的开发者工具把两个账号的Token放在两个不同的浏览器Profile里来回切换着测。这种做法虽然慢但确认出来的漏洞每一个都能直接写进渗透测试报告。经验3日志要留全。检测过程中产生的所有请求日志、响应日志、中间文件都建议保留下来。一方面是为了给别人复现你的测试过程另一方面是如果事后发现误报或漏报还有原始数据可以回溯。千万不要跑完就把临时文件删了等到写报告时才追悔莫及。4.3 对工具局限性的清醒认知这套组合虽然好用但它解决不了所有问题。它对付的是“越权访问数据”这类问题但有些越权场景它很难覆盖基于业务逻辑的越权比如“先购物再改价”的支付逻辑问题工具无法理解这种业务规则。需要多步骤串联的越权比如一个操作要经过三步请求才能完成工具只对单次请求做对比抓不住这种链路。高度自定义的API返回格式如果接口的响应内容是加密的或者动态的Vespasian的响应对比逻辑可能会失效。所以我的最终建议是把Hadrian和Vespasian当成“侦察兵”把人工测试当成“主攻手”。侦察兵探明地形、缩小范围主攻手集中火力突破关键目标这样搭配的效率和准确率才是最高的。5. 从检测到报告输出一份有价值的越权测试结论5.1 报告里应该包含哪些内容跑完整个流程、手动验证完可疑点之后就该整理报告了。我见过很多测试同学的报告写得特别简单就一张截图加一句“存在越权漏洞”这种报告不管是给开发还是给安全负责人看价值都不高。一份合格的越权测试报告至少应该包含漏洞接口的完整URL和HTTP方法、请求参数和认证方式、两个账号的凭证信息、复现步骤包括关键请求和响应、越权的影响范围能读到什么数据、能执行什么操作、修复建议比如在服务端校验资源归属。这些信息如果都写清楚了开发拿到报告就能直接定位问题代码不用来回找你追问细节。这也是专业测试工程师和脚本小子的一个重要区别。5.2 修复验证的闭环思路提交报告不等于工作结束。很多团队在开发修复完漏洞后测试人员还需要做回归验证确认修复措施真正生效了。这时候Hadrian和Vespasian又能派上用场把修复后的API重新跑一遍越权检测对比之前的报告看可疑接口是否已经被处理。如果同样的测试用例已经测不出越权那就说明修复有效如果还能测出来说明修复不彻底需要打回重新处理。我实测下来这套工具组合在回归验证阶段确实能给测试人员省不少力。因为整个流程都是可复现、可重复的参数一改就能重跑不需要手工重新造一遍轮子。5.3 我个人的一些实践体会最后分享一点非常个人的感受。在API安全这个领域工具永远是辅助真正的核心能力是“看懂业务、理解权限模型、知道数据怎么流转”。Hadrian和Vespasian是帮你提高效率的但它们不能替代你的判断。我最初刚接触这套工具时也以为装好环境、跑完命令就能躺平等报告了。但真正做到后面才发现工具体的产出仅仅是“线索”真正能叫“漏洞”的结论一定是你自己一步步验证出来的。这个过程没法偷懒也不需要偷懒因为越权漏洞的确认本来就该严谨一点多花点时间不会亏。把这套流程完整跑通一遍之后你不仅拥有了一个越权自动化检测的实战技能也会对API接口的权限控制设计有更深的理解。之后再面对真实系统的API测试心里就有底了先梳理攻击面再跑自动化检测最后人工确认按照这个节奏走基本不会漏掉严重的越权问题。