★ FEATURED ARTICLE UI 刚迭代完某后台系统的接口权限验证又漏了新加的导出接口这种场景干安全的同行应该都熟。API 安全测试最尴尬的处境不是漏洞多而是测完一轮之后下个版本一来之前的结论全部作废。我自己的解法是用 Kiterunner 和 Postman 把流程串成一个攻防闭环一个负责把隐藏端点捞出来一个负责把安全约束钉死在回归用例里两边一接安全测试就不只是一次性的活而是能跟着系统版本持续转的流程。这篇文章就来拆解这个闭环怎么落地。内容包括工具选型逻辑、Kiterunner 的扫描实战、Postman 安全回归集如何设计、两者怎么联动进 CI以及我在实操里踩过的高频坑。适合正在做 API 安全测试的工程师、想自己补安全网的开发以及对接口自动化有基础、想往安全方向扩展测试面的 QA 同学。会尽量把命令、脚本、判断思路都摊开写照着搭一套出来不是问题。1. 攻防闭环的整体思路与工具选型逻辑1.1 先想清楚为什么 API 安全测试需要闭环API 和传统 Web 页面最大的区别在于API 是机器之间的契约直接暴露在 HTTP 层。没有浏览器、没有渲染层所有攻击面都是平铺直叙的路由。更麻烦的是前后端分离和微服务架构让 API 端点数以百计有些接口走网关有些接口是开发图省事绕过的测试环境的路径和生产环境还可能不一致。靠人工一个个记接口、测权限不仅累而且永远追不上开发迭代的速度。我见过很多团队做 API 安全测试的方式是找扫描器扫一轮整理一份高危清单发给开发修修完就归档。这个流程看起来没问题但本质上是一个开环。开发修好一个漏洞下一轮迭代可能引入三个新接口权限判断可能从公共中间件挪到了单个控制器里之前的测试结论全部失效。攻击者会持续跟着你的版本走你却只在固定的时间点看一眼这个时间差就是漏洞存活的空间。闭环的意思就是把每一次扫描结果转化为下一步动作发现可疑端点 → 人工验证 → 修复 → 回归 → 再发现。每个环节的产出都喂给下一个环节循环往复。我用一个生活化的例子解释你家里装了智能门锁装完那一刻只是确认了门锁存在接下来要测试指纹能不能开、陌生人会不会被拦、固件升级后逻辑有没有被改坏这些动作合在一起才是完整的安防流程。API 安全测试的闭环本质上就是给系统持续做体检复查而不是装个门锁就再也不管。1.2 两个工具的分工Kiterunner 当矛Postman 当盾选 Kiterunner 和 Postman 这个组合不是因为我偏好某个工具而是因为它们的能力恰好互补几乎没有重叠。工具角色核心能力主要产出物Kiterunner攻击侧/探索侧基于 API 路由字典快速探测发现未知端点、隐藏调试接口、敏感路径可疑端点清单、扫描报告Postman防守侧/固化侧把已知安全约束固化为可重复执行的集合与断言脚本回归测试报告、CI 拦截结果Kiterunner 的核心思路像淘金。它不关心业务逻辑只带着一份巨大的 API 路径字典不依赖浏览器去把目标上所有可能存在的路由翻一遍。这份字典不是普通目录爆破那种一条条单词的清单而是专门针对 API 命名习惯整理的比如/api/users/export、/internal/debug、/swagger-ui.html还包含了 HTTP 方法和路径参数信息能覆盖/api/user/{id}这种动态路由。它最擅长的事是把开发自己都快忘了的调试接口、旧版本接口、遗留路由挖出来。Postman 的核心思路是守门。它不管你系统里藏着多少未知端点只管把已知的安全约束变成自动化断言未登录访问所有用户接口必须返回 401订单详情接口不能因为改个 ID 就返回别人的订单敏感接口响应体里不允许出现手机号明文这些规则写成 Postman 测试脚本之后跑一遍集合几分钟就能知道当前版本有没有破坏这些基线。这种分工很像轻量版的红蓝对抗一个负责用攻击者思维不断找新入口一个负责用工程化手段把历史经验沉淀下来防止旧问题复发。两边缺了谁闭环都转不起来。1.3 闭环的四阶段模型整个攻防闭环我拆成四个阶段各管一段Discover发现用 Kiterunner 扫描目标 API从返回结果里筛选可疑端点。关键词是全和快先把 API 资产面摸清楚。Verify验证把可疑端点放到 Postman 里构造真实的业务请求确认是不是真漏洞、危害等级有多大。这个阶段必须有人参与不能拿扫描结果直接吓开发。Fix修复开发针对确认的问题修复通常是补鉴权、修越权、加限速、做脱敏这几类动作。Regression回归用 Postman 集合跑一遍全量安全用例确认修复动作没有引入新问题同时把修复结果更新回资产清单。这四个阶段跑完一圈下一轮 Discover 又会发现新端点于是再进 Verify、Fix、Regression形成一个螺旋上升的循环。后面几章我会把这四步分别用什么命令、怎么写脚本、怎么串起来全部展开。2. Kiterunner 实战把隐藏 API 端点照出来2.1 安装与环境准备Kiterunner 是 Go 语言写的命令行工具不需要依赖运行时单二进制扔到服务器上就能跑。我自己是在 Linux x64 环境里用的直接从官方 Releases 页面下载对应平台的压缩包解压后丢到/usr/local/bin就完事了# 从官方 Releases 页面复制最新版本的下载链接 wget release下载地址 -O kiterunner.tar.gz tar -xzf kiterunner.tar.gz chmod x kr mv kr /usr/local/bin/ kr version如果服务器上没有外网下载条件也可以在本地构建前提是装了 Go 环境git clone 仓库地址 cd kiterunner go build -o kr ./cmd/kiterunner我不太建议新手折腾编译直接下二进制最省事。工具就绪之后还需要一份路由字典后缀是.kite。这个格式跟普通字典不一样里面除了路径本身还带上方法GET/POST/PUT/DELETE和路径参数扫描时能覆盖/api/user/{id}这种动态路由。通常有两份常用字典一份小、一份大。小的适合快速摸底大的路径条目多到离谱适合深度挖掘。我的习惯是都下载快速摸底时用小的每周或者每月深度扫描时用大的。无论用什么工具都必须强调一点Kiterunner 只能扫描有授权的目标。我所有测试要么在客户授权的范围里做要么在自己搭的靶场环境里跑。这是行业红线没有任何商量余地。2.2 扫描命令与参数选型基础扫描命令长这样kr scan https://api.target.com \ --wordlist routes-large.kite \ --threads 50 \ --json--wordlist指定字典--threads控制并发我给 50 起步太高容易被 WAF 拦截太低则太慢--json让结果以 JSON 格式输出方便后续写脚本解析、入库、做 diff。如果目标系统有网关或者扫描流量容易被识别可以带上请求头模拟真实客户端kr scan https://api.target.com \ --wordlist routes-large.kite \ --threads 50 \ --header User-Agent: Mozilla/5.0 \ --header X-Forwarded-For: 127.0.0.1带User-Agent的原因是很多 WAF 会优先拦掉没有浏览器特征的流量带X-Forwarded-For是因为部分网关的访问控制会基于这个头判断来源测试时模拟一下能减少误伤。这里要提醒一句不同版本的 Kiterunner 参数名可能有细微差异上面命令里的参数以当前版本kr scan --help输出为准。我遇到过一次升级后递归参数失效的情况所以每次换版本第一件事就是把--help完整看一遍。第一次扫描我建议不要开递归直接扫根路径。先把目标 API 家族谱系摸出来确认没有基础问题之后再考虑深挖子路径。递归一旦开起来URL 数量会指数膨胀解析结果的时间比扫描时间还长。2.3 结果怎么看状态码与内容长度是核心信号Kiterunner 的扫描结果有点像 HTTP 响应摘要每一行能看到请求的 URL、方法、状态码、响应内容长度。我拿到输出之后第一反应不是找 200而是把结果按状态码分组处理200 组接口大概率存在。逐个确认是不是业务接口重点看内容长度。如果某个响应的长度明显大于同类接口很可能返回了列表数据属于潜在的数据泄露面。401/403 组接口存在但受保护。这类要记录到资产清单后续验证授权校验是否真的有效。这个分组经常被忽略但它才是越权漏洞的高发区。301/302 组有跳转。可能是路径变更也可能是网关在做统一跳转。大量 301 出现时先怀疑网关配置不要急着当端点。500 组接口存在但报错。不要直接跳过报错响应体可能把堆栈信息、数据库类型、中间件版本暴露出来这本身就是信息泄露问题。误报最集中的场景是 CDN 或者 API 网关的默认响应。某些网关对不存在的路由统一返回一个欢迎页状态码 200内容长度固定。这种情况下观察完噪音之后可以使用 Kiterunner 的跳过长度参数把固定长度过滤掉。比如已知默认响应长度是 1580那就加上--skip-len 1580重新跑。我习惯先不带过滤跑一遍统计出哪些长度高频出现再过滤而不是上来就猜因为不同网关的默认响应长度差异很大。2.4 把扫描结果沉淀成资产清单扫完不等于结束。我每一轮 Kiterunner 跑完都会整理一份资产清单字段包括URL、HTTP 方法、状态码、响应长度、是否疑似漏洞、是否需要人工复核。这个清单有两个用途第一作为下一轮 Postman 用例的原始素材第二留作历史记录做增量对比。增量对比是这段经历里最值钱的一个习惯。把上一轮的合法端点保存下来下一轮扫描只 diff 新增的部分。新路径往往是安全漏洞高发区因为开发在迭代压力下写新接口时第一优先级永远是功能能通权限校验经常补在最后甚至忘掉。我做过一次统计我经手的项目里新接口出权限问题的概率是老接口的三倍左右。所以盯着增量看这个动作比任何扩大字典的投入都更划算。3. Postman把攻防成果固化成防守基线3.1 用集合结构承载安全用例Postman 的集合对我来说不只是一个调试工具面板而是一个测试套件容器。一个合格的 API 安全回归集合至少要两级目录顶层按业务模块分比如订单、用户、支付、后台管理每个模块里再按风险类型分文件夹比如未授权访问越权访问敏感信息泄露。这样组织之后跑完 Runner 一眼就能看到哪个模块哪类风险出了问题。我见过有人把所有安全用例平铺在一个文件夹里短期省事用例一多排查效率非常低。另外一个很容易踩的坑是环境变量。BaseURL、Token、测试账号这些动态值一定要全部放进环境变量不要写死在请求里。我通常维护两套环境一套local指本地服务一套test指测试环境。跑回归的时候切换环境只是点一下的事如果写死在请求里换个环境就得改一堆请求还要承担改错的成本。3.2 安全断言脚本怎么写Postman 的 Tests 区域里能写pm.*断言。安全用例里最常见的断言有三类。第一类是未授权接口必须被拒绝。例如未登录访问用户列表预期应该被拦截pm.test(未登录访问用户列表应被拒绝, function () { pm.response.to.have.status(401); pm.expect(pm.response.text()).to.not.include(userId); });第二类是越权访问不能返回他人数据。假设正常用户 A 构造请求访问用户 B 的订单详单ID 参数改成 B 的 ID响应不应该包含 B 的数据pm.test(不应返回其他用户数据, function () { const jsonData pm.response.json(); // 假设B用户的ID是10086实际换成被测目标值 pm.expect(jsonData.data).to.not.have.property(userId, 10086); });第三类是敏感字段不应出现在响应体里。手机号、身份证号、内部 token 这些匿名接口不允许回传明文pm.test(响应中不应包含手机号明文, function () { const body pm.response.text(); pm.expect(body).to.not.include(phone); });断言脚本不是越复杂越好而是越贴近业务语义越好。我刚开始写安全用例时只判断响应码不等于 200后来发现很多接口返回 200 但响应体里是个空壳真正的安全问题藏在不该返回的数据却出现了里。所以安全断言的关注点要放在不该出现的没有出现而自动化测试里常用的正向断言该出现的都出现了只是辅助。3.3 Runner 批量执行与结果分析集合里攒了几十个用例之后手动一个个点发送没有意义要用 Collection Runner 批量执行。Runner 里可以勾选要跑的文件夹、指定环境、配置迭代次数和请求延迟。我一般设置 1 秒延迟避免连环请求触发限流让结果失真。跑完的结果页会列出每个用例的通过/失败状态和断言详情。这里有一个很值得注意的经验不要看到全绿就觉得安全了重点要看失败用例的失败原因。比如某个接口预期返回 401实际却返回 500。表面上断言也失败了但失败原因是服务端异常不是权限逻辑生效。这种假失败往往说明接口内部没有兜底逻辑一旦权限组件出问题接口会直接把内部错误抛给客户端信息泄露风险并不低。我会把这类情况单独记一份问题单而不是简单标记为用例失败。3.4 用 Newman 把 Postman 用例拖进自动化流程Postman 图形界面在本地跑很方便但要接 CI 或定时任务必须用 Newman 这个命令行工具。用法非常简单newman run api-security.collection.json \ -e test.environment.json \ --reporters cli,json \ --reporter-json-export api-security-report.json跑完自动生成 JSON 报告CI 拿到报告就能判断安全基线是否通过。Newman 最实用的特性是支持非零退出码只要有一个断言失败命令返回码就不是 0可以自然地中断 CI 流水线里的后续阶段。我把这一步称为把安全回归变成一道闸门。凡是涉及 API 的版本发布发布前先跑一遍 Newman 安全集合失败就不允许上线通过才放行。一开始团队成员会嫌慢但当它真的拦截住一次权限回退问题之后所有人都会意识到这几分钟花得值。毕竟线上出一个越权漏洞后果可比发布延迟几分钟严重得多。4. 联动编排让发现和回归形成双向飞轮4.1 从 Kiterunner 告警到 Postman 用例的转换流程Kiterunner 扫出可疑端点后是不是马上建 Postman 用例别急中间一定要有一个人工核验步骤。我的标准流程是Kiterunner 扫描结果 → 人工确认端点与漏洞特征 → 在 Postman 里构造请求复现 → 确认成立后编写断言 → 加入安全回归集合。举个例子Kiterunner 报告GET /api/v2/user/export返回 200敏感词触发了告警。我在 Postman 里建一个 GET 请求预期断言写成未授权访问应该被拦截不允许导出用户数据。如果系统当前确实没有鉴权这个用例初始跑出来是红的正好把它标记为待修复漏洞。开发修复后这个用例再跑就变绿。它就从一次性攻击发现彻底转化成了长期防守基线里的一个正式成员。字段映射关系大致是这样Kiterunner 里的 URL、Method、StatusCode对应 Postman 请求里的 URL、Method、预期 StatusKiterunner 里可疑的原因对应断言注释或用例描述。这个映射关系要写在用例描述里方便三个月后的自己回来看一眼就懂当时为什么建这个用例。4.2 增量扫描与定时调度的节奏闭环能持续运转执行节奏比工具重要。我目前跑三条线每日跑 Postman 安全回归集合Newman确认上次修复没有把安全逻辑改坏。这个过程几分钟适合放在每天早晨的定时任务里。每周跑一次 Kiterunner 快速扫描用较小的字典覆盖全量域名重点看有没有新路径冒出来。做 diff 用的资产清单就是 2.4 节里说的那份。每月跑一次 Kiterunner 深度扫描用大字典配合人工 Review把整个 API 资产面翻一遍检查历史漏洞是否被彻底修复以及有没有出现新版本的调试接口。这个节奏不是拍脑袋定的。每日回归解决的是版本迭代引入的安全回归每周扫描解决的是开发新加的接口没走安全评审每月深度扫描解决的是历史遗留路由和隐蔽接口。三条线覆盖的时间维度不同合在一起才是完整的闭环。4.3 在 CI 流水线里拦截两类风险有了 Kiterunner 和 Newman两类安全动作都可以自动化。我习惯在流水线里放两个阶段。第一个阶段是API 资产变化检测。代码合并到主干后如果有 API 路由变更用 Kiterunner 快速扫描结果和上一轮结果做 diff发现新增高危路径就立刻告警。这个阶段用的字典可以小一些只覆盖全量常见路径跑完通常只需要几十秒到几分钟。第二个阶段是API 安全回归。用 Newman 跑整个安全用例集合几十个用例跑完也就几分钟。这个阶段放在发布前失败就中断发布。有人担心安全测试拖慢发布速度我的看法是安全测试本来就不是追求零耗时的环节它是用来买保险的。几分钟的扫描换一个不在线上出安全事故的可能性这笔账怎么算都划算。如果要做得更细一点还可以在流水线里同时生成两个报告并做一个汇总页。开发在工单里看到的不是一条安全检查失败的抽象提示而是哪个端点、哪个断言、返回了什么样的响应体。信息越具体修复效率越高这个闭环的阻力就越小。4.4 多团队协作时的信息闭环API 安全测试如果只有安全工程师一个人在看闭环永远转不动。开发迭代快安全验证慢信息在中间断层最后的结果就是扫描报告躺在仓库里积灰。我现在会在缺陷管理工具里给每个确认的漏洞建单标签里写明API 安全关联 Kiterunner 扫描报告和 Postman 复现脚本指派给对应模块负责人。漏洞修复后对应的 Postman 用例自动变绿我在单上把回归结果贴回去整个追溯链条才算完整。这里有个很实用的细节建单时一定把请求地址、请求头、请求体、预期行为写得清清楚楚不要让开发去猜这个漏洞是怎么触发的。我有一次偷懒只写了接口存在越权可以查看他人订单结果开发顺着代码查了两天最后发现是一个测试账号做的越权不是生产问题。如果一开始就把 Postman 的请求导出发过去这个话题十分钟就能结束。把复现路径写全开发修复的效率完全不一样。5. 高频踩坑与排查速查表5.1 Kiterunner 扫不出任何东西大多数情况下不是目标没有漏洞而是扫描流量没到达业务后端。常见原因有三个目标网关或 WAF 把扫描流量识别并拦截了字典和 API 命名风格不匹配例如业务路径全部带/gateway/前缀但字典里没有目标服务需要登录态扫描裸路径全返回 401看起来像没有发现但其实是发现了一批受保护接口。排查顺序是先用curl手动访问几个目标地址确认网络连通再带上常见浏览器 UA 头重扫最后确认是不是要先在请求里注入认证信息。大多数情况下前两步就能解决问题。如果确认是字典不匹配那就用自定义字典叠加扫描提取业务里最常见的路径前缀拼进去。5.2 Postman 环境变量明明选了却不生效跑 Runner 时URL 还是{{baseUrl}}占位符或者断言引用的变量是空的。这个坑我见过太多次。大概率是环境变量根本没被正确应用到请求上具体原因有几个方向请求变量或预请求脚本里设置了同名变量覆盖了环境变量环境变量里保存的和当前选中的不是同一套还有可能是变量名拼写不一致。Postman 的变量作用域从底到顶依次是数据变量、环境变量、集合变量、全局变量同一个名字在低层会覆盖高层。排查时先看请求的 Pre-request Script 里有没有设置同名变量再看环境变量有没有保存成功。很多人改完环境配置后忘了点 Save看起来换到了新环境实际跑的还是旧值。5.3 告警太多没人跟进Kiterunner 扫出来的可疑端点一大片看不过来更不用说让开发修了。我的策略是分级处理凡是涉及敏感数据的端点比如用户、订单、支付、后台管理标记 P0/P1当天必须有人工复核不涉及敏感数据的端点和静态资源、健康检查、文档页这类先攒着每周批量确认一次。同时给 Kiterunner 的扫描配置一个排除名单把已知的静态资源目录、固定网关响应、Swagger 页面等高频误报点提前排除掉从源头上减少噪音。告警如果永远处理不完团队就会对告警产生免疫这是安全平台失效的第一步所以管告警频率和管告警内容同样重要。5.4 速查表典型现象可能原因处理方法Kiterunner 扫描始终无输出WAF 拦截/网络不通/字典不匹配手动 curl 确认连通换 UA 头叠加自定义字典大量 200 状态码但响应体为空网关默认响应/CDN 页面观察内容长度用 --skip-len 过滤已知噪音Postman 变量显示为占位符环境未选择/变量名拼错/变量未保存检查环境选择和变量名保存环境配置断言一直失败但接口看起来正常断言逻辑写错/响应结构变更先打印响应体确认字段层级再调断言修复后回归通过上线又出问题测试环境与生产环境配置不一致回归用例增加生产基线数据敏感信息脱敏处理每周扫描 diff 出大量新路径正常迭代/存在隐藏接口按敏感度分级确认高敏感立即复核5.5 几个容易被忽略的 API 安全测试点最后一个部分写几个 Kiterunner 加 Postman 组合容易遗漏的测试点这些都是实际操作中确认过价值的方向。第一是 BOLA对象级越权。URL 里带个 ID 就能访问别人的资源这是 API 领域最高发的漏洞。Kiterunner 扫不出来因为它只发现路由不感知业务语义。需要用 Postman 显式构造两个不同身份的请求主动比对这个用例没法从扫描结果自动生成必须靠测试设计补位。第二是 BFLA功能级越权。普通用户能不能直接调用管理员接口页面上隐藏按钮不等于接口不可调。同样需要在 Postman 里切换角色比对返回码和数据结构。第三是批量数据导出接口。/export、/download、/backup这类路径在 Kiterunner 字典里常见但只有登录后用 Postman 实际拖一把数据才能确认有没有按照当前用户的权限做行级过滤。批量导出接口一旦越权数据量级就不是一条记录泄露的事了。第四是调试接口残留。/debug、/swagger、/actuator、/console这些路径是 Kiterunner 的重点捕获对象扫出来之后一定要跟进。这些接口常常把源码信息、配置信息甚至在线调试能力暴露出来属于低投入高回报的修复项。第五是限速缺失。API 没有限流的话攻击者可以用脚本长时间循环请求导致数据被批量拖走或者业务被刷爆。Kiterunner 不会告诉你限速是否存在在 Postman 里写一个循环发送的脚本就能验证。验证完之后把这个用例也固化成回归项防止中间件配置被误删。以上这些测试点实操时最好让开发把接口的权限矩阵列出来一条接口对着一条核对比临时构造请求猜预期要高效得多。我在做项目测试的时候会把权限矩阵打印出来贴在显示器边上一张纸解决几十个用例的预期来源问题。我个人实际操作下来的体会是工具组合不是越复杂越好Kiterunner 加 Postman 这套方案胜在简单、免费、容易落地。真正决定闭环能不能转起来的不是扫描器发现了多少漏洞而是发现之后有没有人验证、有没有人修、修完有没有跑回归、回归结果有没有喂回下一轮扫描。踩过几次坑之后我现在最看重的习惯是保存每一轮扫描的 JSON 和 diff 记录把 API 资产清单从几十条维护到几百条增量扫描一眼就能看出新路径。这个习惯养成了攻防闭环才真正从工具层面转到了团队层面的常态运转。
阅读完成 · 觉得有帮助？
