搞API漏洞挖掘这几年我最大的感受是这活儿跟传统Web渗透完全不是一个思路。传统Web你盯着页面找SQL注入、找XSS但API漏洞挖掘玩的是业务逻辑——你面对的是一堆无界面的JSON请求必须从“功能怎么流转”的角度去思考而不是从“页面长什么样”去思考。这篇内容我想把API漏洞挖掘这件事从头到尾捋一遍攻击面怎么梳理、哪些漏洞类型最高发、用什么工具链、实际踩过哪些坑。适合刚接触API安全、想系统入门的同学也适合做研发的朋友拿来自查接口设计问题。1. API漏洞挖掘的核心认知先搞懂攻击面在哪里1.1 为什么API成了漏洞重灾区现在几乎没有一个业务系统能离开API。前端页面要数据调API手机App所有功能调API就算你打开一个网页背后可能也藏着几十个接口在默默工作。前后端分离成了主流架构之后API层几乎承载了全部业务逻辑。接口数量一多问题就来了。很多研发同学把接口写出来能用就行没有人认真想过“这个接口是不是只能给管理员调”“用户A能不能通过接口看到用户B的数据”“批量导出接口有没有做频率限制”。我见过不少业务系统前端页面上权限控制做得挺细但接口本身完全不设防——你在页面里看不到某个功能按钮但直接拿工具调接口就能访问。这种割裂就是漏洞的温床。还有一个现实问题是传统Web防护设备对API流量的解析能力参差不齐。很多防护规则是按URL、参数名去匹配的但API的请求体是JSON结构同一套语义可以用完全不同的JSON表达出来。比如一个数组参数传[1,2,3]和传{ids:[1,2,3]}可能是同一个含义但防护规则只认其中一种写法另一种就放过去了。这类解析差异给API漏洞挖掘留了非常大的空间。1.2 与传统Web挖洞的思路差异我整理了一个对照表可以比较直观看懂两者区别维度传统Web测试API漏洞挖掘入口页面URL、表单、链接接口路径 请求方法 JSON/XML请求体数据格式表单参数、查询字符串结构化数据JSON为主、嵌套对象、数组鉴权方式多为Cookie会话Token、签名、API Key、刷新令牌等混合机制核心关注点注入、XSS等通用漏洞业务逻辑越权、对象级授权、批量赋值响应信息页面渲染结果JSON/XML数据结构、状态码、错误信息功能暴露方式页面可见接口无界面靠文档/抓包/猜测发现在传统Web里你更多是跟渲染层打交道在API测试里你直接跟业务逻辑层对话。同样的业务功能页面上一个按钮点到就只能走那一条路径但直接打接口你可以随意组合参数、篡改请求方法、伪造对象ID。这就是为什么API漏洞挖掘更考验人对业务的理解力——你得先看懂这个接口“本来该干嘛”才能知道“不该干嘛”的地方在哪。1.3 从三个维度梳理攻击面我自己在做API安全评估时习惯从三个维度去看攻击面第一鉴权边界。系统里哪些接口需要登录哪些接口匿名可访问登录后不同角色能调到哪些接口。这个边界一旦混乱垂直越权就来了。最典型的场景是研发写了个管理后台的接口忘记加权限校验或者只在前端路由做了判断。第二对象引用。几乎所有修改、查询类接口都会带上业务对象的标识参数比如订单ID、用户ID、文件ID。这些ID一旦是连续的、可预测的、或者能从其他接口枚举出来的水平越权的口子就开了。判断方法很简单当前用户操作的资源接口有没有验证“这玩意儿属于当前用户”。第三数据流。数据从哪个接口进、从哪个接口出、中间经过哪些处理。很多漏洞藏在数据流的“意外出口”里——比如一个用来更新用户昵称的接口竟然在响应里返回了完整的手机号和身份证信息再比如一个导入Excel的接口文件里的路径参数最后被拼进了文件系统操作那就有路径穿越的风险。把这三个维度的信息摸清楚API攻击面的轮廓就出来了。接下来才能谈具体的漏洞类型。2. 高发漏洞类型与底层原理拆解2.1 对象级授权失效API漏洞里的“街溜子”对象级授权失效也就是常说的IDOR或者水平越权是API漏洞里出现频率最高的类型。OWASP API Top 10常年把它排在第一位不是没有原因的——它太容易出现了。原理非常简单接口在操作一个业务对象订单、文件、消息时直接用客户端传过来的ID去数据库里查没有校验这个ID所代表的资源到底属于当前登录用户。我举一个案例。某业务系统有一个“查询订单详情”的接口正常请求长这样POST /api/order/detail Authorization: Bearer 用户Token { orderId: 20240001 }响应正常返回当前用户下单的详情。但如果我把orderId改成20240002接口照样把别人的订单返回了那就是典型IDOR。这个问题的坑在于很多研发会下意识觉得“接口要登录才能访问所以是安全的”——但登录只证明了“你是你”并没有证明“订单是你的”。实战中这类漏洞通常配合枚举思路来挖。订单号如果是日期加流水号连续且可预测那就一个接一个遍历如果是UUID这种不可预测的那就去别的接口留意有没有泄露订单号的点比如列表接口、通知接口拿到一个换一个。2.2 用户级授权失效普通用户调管理员接口如果说IDOR是“横向绕过”那用户级授权失效就是“纵向提权”也就是垂直越权。普通用户直接调用管理员专属接口接口本身不校验当前用户的角色。这类漏洞的形成原因非常离谱但非常常见开发觉得“这个接口反正只有管理员页面会调用所以不需要在服务端做校验”。结果就是管理员后台有一个“修改用户角色”的接口普通用户拿自己的Token也能直接调用把角色改成管理员。实际测试思路很简单先搞到管理员身份下某个接口的请求报文可以通过正常使用管理员功能、查看前端代码里暴露的接口地址、或者通过其他漏洞泄露的文档获得。把自己的普通用户Token替换上去。观察接口是否正常返回数据或者正常执行操作。如果接口对角色没有校验那它就老老实实响应了。垂直越权的修复门槛同样很低——服务端在接口入口处加一层角色鉴权即可但就是这层东西经常被漏掉。2.3 批量赋值与参数污染这俩可以放在一起说。批量赋值的意思是服务端把客户端提交的参数直接绑定到了内部对象上多传的那些字段也一并接受了。经典案例是注册接口。正常注册提交username和password两个字段但攻击者在JSON里额外加一个isAdmin: true或者role: admin服务端反序列化的时候因为字段名对得上就把角色值给覆盖了。POST /api/user/register { username: newuser, password: 123456, role: admin }这类问题的高发区在用了自动绑定功能的框架里。框架图省事直接把请求体绑定到数据库模型上结果客户端传什么字段它就更新什么字段。修复方式通常是用DTO只接收白名单字段但很多项目图快就不加这个层。参数污染则走的是另一个路子同一个参数名出现多次。比如?roleuserroleadmin后端框架解析的时候可能取了第一个值业务代码又取了第二个值两个环节取值不一致就可能跳过校验。这类问题在网关层和业务层使用不同解析方式的架构里尤其容易出现。2.4 认证机制缺陷与Token问题API的认证方式五花八门JWT、OAuth 2.0、自定义签名、API Key……每种都有自己的坑。先说JWT。这是目前最常见也最容易出问题的。常见缺陷有这几个算法混淆服务端验签时没指定固定算法攻击者把alg改成none或者用HS256配合服务端的公钥去签名如果服务端傻乎乎地用公钥当HMAC密钥去验签攻击就成立了。签名验签缺失部分接口只解析Token拿到了用户ID根本没验签随便拿个合法签发的Token改里面的用户ID就能冒充别人。敏感信息泄露JWT是Base64编码的不是加密的。把Token解出来payload里的手机号、邮箱甚至明文密码都直接暴露。整个验证过程在靶场或授权环境里如果碰到疑似JWT问题我会先解Token看payload字段再尝试修改payload后不签名或改算法观察接口是否接受。三个步骤就能快速定位问题。另一个容易被忽视的坑是刷新令牌。很多系统设计了长效的refresh token用来换取新的access token但接口逻辑里没有校验refresh token和用户会话是否绑定导致即使访问令牌过期了拿泄露的刷新令牌依然能无限续期长期占领账号。2.5 其他值得留意的类型除了上面几类还有几个类型在API场景里也经常出现-SSRF。很多接口接受URL参数比如头像上传、图片代理、webhook回调配置。如果服务端直接请求了这个URL且没有校验访问目标地址就可能让它去请求内网地址探测内网服务。注入类。SQL注入、表达式注入、NoSQL注入。API的查询接口如果有搜索、筛选功能尝试在参数里塞注入语句仍然是最基础的测试项。因为很多接口直接把查询参数拼接进查询。NoSQL数据库相对的测试方法就是传{$gt:}这类操作符。不安全反序列化。某些接口接受二进制或特定格式的序列化数据。这类问题利用门槛高一些但一旦存在危害是RCE级别的。3. 实操流程与工具链搭建3.1 信息收集接口从哪来API接口的收集很多时候决定了漏洞挖掘的天花板。接口找不全后面的技术再强也白搭。我自己常用的接口收集途径有这么几个第一前端JS文件。打开目标网站F12看网络面板过滤JS文件里面经常直接写着接口路径。尤其是用了某些前端框架打包出来的站点所有路由和接口都在一个巨大的JS文件里。我习惯把JS文件下载下来用正则批量提取里面/api/xxx这类路径。# 从JS中提取API路径示例 grep -oE /[a-zA-Z0-9_/-]{3,} app.js | sort -u | head -50第二抓包工具的HTTP历史。登录、浏览、操作一遍核心业务功能所有请求都会沉淀下来。这一轮收集到的接口是“能跑通的真实接口”比从JS里挖出来的更靠谱。需要考虑的是抓包工具的配置问题在电脑上监听端口之后把浏览器的请求指向这个监听端口就能看到完整的请求和响应内容。第三接口文档站点。很多系统会挂Swagger、Knife4j这类接口文档路径通常是/swagger-ui.html、/v2/api-docs、/v3/api-docs。这类文档简直是宝藏——直接列出了所有接口、参数、返回结构。有时候文档站点本身忘了加权限校验等于全量接口自助餐。第四移动端流量。大部分业务都配有AppApp里调的接口往往跟Web端不完全一样——可能包含一些老接口或者未在网页端使用的管理接口。手机和电脑连同一个局域网通过抓包工具在电脑上建立监听让手机的流量也经过这个监听端口就能收集到App的接口流量。收集到一个基础接口清单之后我习惯用表格整理字段接口路径、请求方法、是否需要认证、涉及的核心业务对象、参数类型。这个表格是后续测试的地图。3.2 请求凭证与参数理解抓到了接口下一个问题是怎么让它正常跑起来。API请求凭证一般分三类Header里的Token、Cookie、自定义签名参数。Token的处理方式各家不同有的放在Authorization: Bearer xxx有的放在自定义Header里有的是请求体里带token字段。签名参数是最费劲的——常见有timestamp nonce sign的组合sign是对参数按特定规则加密得到的。遇到这种先要搞清楚签名算法和参与签名的字段不然改一个参数签名就对不上了。我的实操建议是能用抓包工具改包重放就不手动拼请求抓包工具能把已经抓到的请求原样再发一次改参数方便还能做批量替换。复杂的业务逻辑靠脚本我用Python的requests库配合抓包工具导出的请求格式做了个小工具能够对一批ID做自动替换测试。参数理解是测试前的最后一环。拿到一个接口至少要弄清楚哪些参数是标识ID、编号、哪些参数是关联userId、shopId、哪些参数是控制逻辑的page、limit、sort、哪些参数会影响后端行为url、filePath、callback。标识参数是越权的关键url类参数是SSRF的关键这些都值得重点照顾。3.3 高价值接口的优先测试策略接口多到测不完是常态所以必须排优先级。我的策略是从业务影响面倒推涉及资金操作的接口转账、支付回调、订单修改、退款。涉及敏感数据读取的接口用户信息列表、订单全量查询、后台统计报表。涉及权限变更的接口角色修改、用户禁用/启用、审批流操作。涉及数据导入导出的接口Excel导入、批量导出、文件上传下载。涉及交互回调的接口webhook配置、消息推送。优先测这些接口的逻辑漏洞因为它们一旦出问题影响面是数据泄露或资金损失级别的。等这类接口测完了再回头扫一遍注入和配置类问题。工具的选型上我的常用组合是用途工具请求抓取与改包重放抓包工具社区版即可接口列表整理与脚本化测试Postman Python脚本接口路径模糊测试ffufJSON数据格式化查看jq历史接口对比浏览器的开发者工具的请求日志4. 典型场景的验证与利用过程实录以下内容均需在自建靶场或已获得书面授权的测试环境下进行。未授权测试违反法律法规这一点没有商量余地。4.1 场景实录一水平越权的完整验证假设某系统有一个“查看员工工资条”功能前端页面显示当前员工的工资条。整个操作会发起一个请求POST /api/payroll/detail Authorization: Bearer 普通员工Token { billId: P20240715001 }第一步正常访问拿到自己的工资条信息确认接口通路正常。第二步把billId改成一个相邻的编号比如P20240715002再次发送。观察响应如果返回了另一位员工的姓名、部门、工资明细漏洞确认。第三步关键点来了——不要只验证一次就收工。有些接口的越权是有条件的也许只能看到部分字段也许必须在特定时间窗口内才能访问也许只能在某个特定角色下才触发。多测几个ID、多试几个邻近编号把影响范围摸清楚这样写修复建议的时候才能说得准确。第四步检查是否存在批量获取的可能。把billId改成数组类型或者同时提交多个ID看看接口会不会一次性返回多条明细。如果支持批量返回影响面会被放大很多——本来一次越权只能看一条数据批量模式下一次能拖走整年的工资记录。4.2 场景实录二批量赋值拿到管理员角色一个注册接口的常规请求POST /api/user/register { username: test001, password: Passw0rd123 }注册成功响应如下{ code: 0, message: success, data: { userId: 10086, username: test001, role: normal_user } }注意到响应里存在role字段说明服务端对象模型里有这个属性。接下来尝试在注册请求中添加额外的字段POST /api/user/register { username: test002, password: Passw0rd123, role: admin }如果响应里的role变成了admin那服务端就是把请求体里的字段直接绑定到了用户对象上批量赋值漏洞成立。这类验证还要扩展一步——查看是否还有其他的敏感字段可以覆盖。比如把userId设置成别人的ID、balance设置成999999、email_verified设置成true。每个业务模型里都有自己独特的敏感字段能确认一个role就说明绑定机制有问题应该沿着这条思路继续深挖同一接口的其他字段。4.3 场景实录三JWT算法混淆验证目标系统的登录接口正常签发JWT解码后payload结构{ uid: 10001, role: normal, exp: 1721200000 }把Token复制出来在测试请求里用这个Token调用一个需要普通权限的接口确认能正常访问。接着尝试把alg字段改成nonepayload里的uid改成管理员ID签名部分删除直接发送请求。eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJ1aWQiOiIxMDAwMSIsInJvbGUiOiJhZG1pbiIsImV4cCI6MTcyMTIwMDAwMH0.如果服务端接受了这个无签名的Token并返回了管理员权限下的数据说明JWT库配置了允许none算法或验签流程缺失。把这个问题记下来修复方案是强制指定验签算法并拒绝none。JWT这类的验证还有个辅助手段把合法签发的Token内容做修改比如把uid改掉签名保持不变发送。如果服务端没有校验签名和Token内容是否匹配它同样会接受被篡改的Token。这两个小实验建议都做一遍。5. 常见问题与排查技巧实录5.1 测试中的五个常见“卡壳”现场卡壳一修改ID后返回的结果跟原来一模一样。这是IDOR测试中最容易混淆的情况。先说结论这不一定说明没有越权——很可能是参数名没找对或者服务端作了缓存。我遇到过一次改orderId没用但实际上接口真正使用的标识是Header里的X-Order-Id字段。所以排查路径是先确认改的是不是服务端实际使用的参数名再看请求里有没有其它同义字段最后确认响应是否有Cache-Control相关的缓存标记。此外响应相同也可能是接口对越权做了静默处理返回了一个通用的空对象。卡壳二请求返回401。多数情况是Token缺失或已过期但还有一种容易被忽略的情况接口要求的认证方式是自定义Header而测试工具里没有带上。再就是某些接口接受短期Token但不接受长期Token或反过来。排查顺序先确认Token有效性再看接口文档或正常请求里用的哪种认证字段最后确认是不是IP白名单限制。卡壳三返回200但data是空的。这个现象很值得警惕。它往往意味着请求已经进入业务逻辑处理环节但因为某个前置条件不满足被“软拒绝”了。常见原因当前账号确实不在可查询的范围内缺少某些必选参数导致查询结果为空后端的多租户隔离起了作用但接口没有明确返回错误。需要做的是对比正常请求和异常请求的报文差异逐字段排查。卡壳四批量赋值的字段不生效。问题通常不在于“要不要传字段”而在于服务端用了白名单方式只取预定义的字段。这时候单纯加字段没用需要找其他的赋值路径。比如有一个接口专门用来更新用户资料它绑定的是ProfileDTO这里的DTO如果包含role字段那往这个接口塞role就有机会生效。所以批量赋值的测试面不能只看注册和登录接口凡是能修改数据的接口都应该留意。卡壳五抓不到App的流量。现在的App普遍做了证书校验不信任抓包工具的证书导致流量抓不出来。实用的方案是找App里有没有相关的网络安全配置开关或者安装旧版本App部分历史版本没有强校验。如果这些都行不通那就换思路——把App的流量在系统层面做透明转发或者用动态调试手段绕过证书校验。注意这个环节非常依赖具体环境操作前先确认具备测试授权。5.2 测试中容易忽略的三个细节第一个细节旧版本接口未下线。研发迭代快接口路径经常换版本/v1/order换成了/v2/order。但如果/v1/order还继续在服务端运行且没有接入新版的安全校验逻辑那它就是一个泄漏点。我在测试时会特意用工具对相同功能的不同版本接口做一轮对比看是否存在旧接口鉴权更弱的问题。第二个细节错误信息过度详细。很多API在参数非法时会返回完整的堆栈信息、数据库表名、SQL片段。这些信息对定位漏洞和构造下一步攻击非常有价值。测试时遇到响应异常别急着跳过看一下返回体里的message和detail字段。第三个细节批量接口的频率限制。某系统提供了一个“批量查询用户信息”的接口传一组ID就返回一组数据。这种接口如果没有限制单次请求的ID数量就会成为数据拖库的通道。测试时要关注这类接口是否区分了单次上限和总量上限以及是否存在绕过限制的办法。写在最后我个人做API漏洞挖掘这几年最大的收获不是掌握了多少工具而是养成了“先理解业务逻辑再动手测试”的习惯。很多漏洞的钥匙不在Payload里而在你对业务模型的理解里——你得多思考“这个接口本来应该怎么用哪一步会出岔子”。另外想强调一点API漏洞挖掘的底线是授权。所有测试行为都应当在自己有权限的环境中进行。洞挖到了第一时间整理好复现步骤和修复建议提交这是负责任的做法。如果你刚开始接触API安全按照这篇内容里的思路先找一个靶场项目练手把接口收集、参数理解、越权测试各过一遍。踩几个坑之后你对API漏洞的感觉就会完全不一样了。
搞API漏洞挖掘这几年我最大的感受是这活儿跟传统Web渗透完全不是一个思路。传统Web你盯着页面找SQL注入、找XSS但API漏洞挖掘玩的是业务逻辑——你面对的是一堆无界面的JSON请求必须从“功能怎么流转”的角度去思考而不是从“页面长什么样”去思考。这篇内容我想把API漏洞挖掘这件事从头到尾捋一遍攻击面怎么梳理、哪些漏洞类型最高发、用什么工具链、实际踩过哪些坑。适合刚接触API安全、想系统入门的同学也适合做研发的朋友拿来自查接口设计问题。1. API漏洞挖掘的核心认知先搞懂攻击面在哪里1.1 为什么API成了漏洞重灾区现在几乎没有一个业务系统能离开API。前端页面要数据调API手机App所有功能调API就算你打开一个网页背后可能也藏着几十个接口在默默工作。前后端分离成了主流架构之后API层几乎承载了全部业务逻辑。接口数量一多问题就来了。很多研发同学把接口写出来能用就行没有人认真想过“这个接口是不是只能给管理员调”“用户A能不能通过接口看到用户B的数据”“批量导出接口有没有做频率限制”。我见过不少业务系统前端页面上权限控制做得挺细但接口本身完全不设防——你在页面里看不到某个功能按钮但直接拿工具调接口就能访问。这种割裂就是漏洞的温床。还有一个现实问题是传统Web防护设备对API流量的解析能力参差不齐。很多防护规则是按URL、参数名去匹配的但API的请求体是JSON结构同一套语义可以用完全不同的JSON表达出来。比如一个数组参数传[1,2,3]和传{ids:[1,2,3]}可能是同一个含义但防护规则只认其中一种写法另一种就放过去了。这类解析差异给API漏洞挖掘留了非常大的空间。1.2 与传统Web挖洞的思路差异我整理了一个对照表可以比较直观看懂两者区别维度传统Web测试API漏洞挖掘入口页面URL、表单、链接接口路径 请求方法 JSON/XML请求体数据格式表单参数、查询字符串结构化数据JSON为主、嵌套对象、数组鉴权方式多为Cookie会话Token、签名、API Key、刷新令牌等混合机制核心关注点注入、XSS等通用漏洞业务逻辑越权、对象级授权、批量赋值响应信息页面渲染结果JSON/XML数据结构、状态码、错误信息功能暴露方式页面可见接口无界面靠文档/抓包/猜测发现在传统Web里你更多是跟渲染层打交道在API测试里你直接跟业务逻辑层对话。同样的业务功能页面上一个按钮点到就只能走那一条路径但直接打接口你可以随意组合参数、篡改请求方法、伪造对象ID。这就是为什么API漏洞挖掘更考验人对业务的理解力——你得先看懂这个接口“本来该干嘛”才能知道“不该干嘛”的地方在哪。1.3 从三个维度梳理攻击面我自己在做API安全评估时习惯从三个维度去看攻击面第一鉴权边界。系统里哪些接口需要登录哪些接口匿名可访问登录后不同角色能调到哪些接口。这个边界一旦混乱垂直越权就来了。最典型的场景是研发写了个管理后台的接口忘记加权限校验或者只在前端路由做了判断。第二对象引用。几乎所有修改、查询类接口都会带上业务对象的标识参数比如订单ID、用户ID、文件ID。这些ID一旦是连续的、可预测的、或者能从其他接口枚举出来的水平越权的口子就开了。判断方法很简单当前用户操作的资源接口有没有验证“这玩意儿属于当前用户”。第三数据流。数据从哪个接口进、从哪个接口出、中间经过哪些处理。很多漏洞藏在数据流的“意外出口”里——比如一个用来更新用户昵称的接口竟然在响应里返回了完整的手机号和身份证信息再比如一个导入Excel的接口文件里的路径参数最后被拼进了文件系统操作那就有路径穿越的风险。把这三个维度的信息摸清楚API攻击面的轮廓就出来了。接下来才能谈具体的漏洞类型。2. 高发漏洞类型与底层原理拆解2.1 对象级授权失效API漏洞里的“街溜子”对象级授权失效也就是常说的IDOR或者水平越权是API漏洞里出现频率最高的类型。OWASP API Top 10常年把它排在第一位不是没有原因的——它太容易出现了。原理非常简单接口在操作一个业务对象订单、文件、消息时直接用客户端传过来的ID去数据库里查没有校验这个ID所代表的资源到底属于当前登录用户。我举一个案例。某业务系统有一个“查询订单详情”的接口正常请求长这样POST /api/order/detail Authorization: Bearer 用户Token { orderId: 20240001 }响应正常返回当前用户下单的详情。但如果我把orderId改成20240002接口照样把别人的订单返回了那就是典型IDOR。这个问题的坑在于很多研发会下意识觉得“接口要登录才能访问所以是安全的”——但登录只证明了“你是你”并没有证明“订单是你的”。实战中这类漏洞通常配合枚举思路来挖。订单号如果是日期加流水号连续且可预测那就一个接一个遍历如果是UUID这种不可预测的那就去别的接口留意有没有泄露订单号的点比如列表接口、通知接口拿到一个换一个。2.2 用户级授权失效普通用户调管理员接口如果说IDOR是“横向绕过”那用户级授权失效就是“纵向提权”也就是垂直越权。普通用户直接调用管理员专属接口接口本身不校验当前用户的角色。这类漏洞的形成原因非常离谱但非常常见开发觉得“这个接口反正只有管理员页面会调用所以不需要在服务端做校验”。结果就是管理员后台有一个“修改用户角色”的接口普通用户拿自己的Token也能直接调用把角色改成管理员。实际测试思路很简单先搞到管理员身份下某个接口的请求报文可以通过正常使用管理员功能、查看前端代码里暴露的接口地址、或者通过其他漏洞泄露的文档获得。把自己的普通用户Token替换上去。观察接口是否正常返回数据或者正常执行操作。如果接口对角色没有校验那它就老老实实响应了。垂直越权的修复门槛同样很低——服务端在接口入口处加一层角色鉴权即可但就是这层东西经常被漏掉。2.3 批量赋值与参数污染这俩可以放在一起说。批量赋值的意思是服务端把客户端提交的参数直接绑定到了内部对象上多传的那些字段也一并接受了。经典案例是注册接口。正常注册提交username和password两个字段但攻击者在JSON里额外加一个isAdmin: true或者role: admin服务端反序列化的时候因为字段名对得上就把角色值给覆盖了。POST /api/user/register { username: newuser, password: 123456, role: admin }这类问题的高发区在用了自动绑定功能的框架里。框架图省事直接把请求体绑定到数据库模型上结果客户端传什么字段它就更新什么字段。修复方式通常是用DTO只接收白名单字段但很多项目图快就不加这个层。参数污染则走的是另一个路子同一个参数名出现多次。比如?roleuserroleadmin后端框架解析的时候可能取了第一个值业务代码又取了第二个值两个环节取值不一致就可能跳过校验。这类问题在网关层和业务层使用不同解析方式的架构里尤其容易出现。2.4 认证机制缺陷与Token问题API的认证方式五花八门JWT、OAuth 2.0、自定义签名、API Key……每种都有自己的坑。先说JWT。这是目前最常见也最容易出问题的。常见缺陷有这几个算法混淆服务端验签时没指定固定算法攻击者把alg改成none或者用HS256配合服务端的公钥去签名如果服务端傻乎乎地用公钥当HMAC密钥去验签攻击就成立了。签名验签缺失部分接口只解析Token拿到了用户ID根本没验签随便拿个合法签发的Token改里面的用户ID就能冒充别人。敏感信息泄露JWT是Base64编码的不是加密的。把Token解出来payload里的手机号、邮箱甚至明文密码都直接暴露。整个验证过程在靶场或授权环境里如果碰到疑似JWT问题我会先解Token看payload字段再尝试修改payload后不签名或改算法观察接口是否接受。三个步骤就能快速定位问题。另一个容易被忽视的坑是刷新令牌。很多系统设计了长效的refresh token用来换取新的access token但接口逻辑里没有校验refresh token和用户会话是否绑定导致即使访问令牌过期了拿泄露的刷新令牌依然能无限续期长期占领账号。2.5 其他值得留意的类型除了上面几类还有几个类型在API场景里也经常出现-SSRF。很多接口接受URL参数比如头像上传、图片代理、webhook回调配置。如果服务端直接请求了这个URL且没有校验访问目标地址就可能让它去请求内网地址探测内网服务。注入类。SQL注入、表达式注入、NoSQL注入。API的查询接口如果有搜索、筛选功能尝试在参数里塞注入语句仍然是最基础的测试项。因为很多接口直接把查询参数拼接进查询。NoSQL数据库相对的测试方法就是传{$gt:}这类操作符。不安全反序列化。某些接口接受二进制或特定格式的序列化数据。这类问题利用门槛高一些但一旦存在危害是RCE级别的。3. 实操流程与工具链搭建3.1 信息收集接口从哪来API接口的收集很多时候决定了漏洞挖掘的天花板。接口找不全后面的技术再强也白搭。我自己常用的接口收集途径有这么几个第一前端JS文件。打开目标网站F12看网络面板过滤JS文件里面经常直接写着接口路径。尤其是用了某些前端框架打包出来的站点所有路由和接口都在一个巨大的JS文件里。我习惯把JS文件下载下来用正则批量提取里面/api/xxx这类路径。# 从JS中提取API路径示例 grep -oE /[a-zA-Z0-9_/-]{3,} app.js | sort -u | head -50第二抓包工具的HTTP历史。登录、浏览、操作一遍核心业务功能所有请求都会沉淀下来。这一轮收集到的接口是“能跑通的真实接口”比从JS里挖出来的更靠谱。需要考虑的是抓包工具的配置问题在电脑上监听端口之后把浏览器的请求指向这个监听端口就能看到完整的请求和响应内容。第三接口文档站点。很多系统会挂Swagger、Knife4j这类接口文档路径通常是/swagger-ui.html、/v2/api-docs、/v3/api-docs。这类文档简直是宝藏——直接列出了所有接口、参数、返回结构。有时候文档站点本身忘了加权限校验等于全量接口自助餐。第四移动端流量。大部分业务都配有AppApp里调的接口往往跟Web端不完全一样——可能包含一些老接口或者未在网页端使用的管理接口。手机和电脑连同一个局域网通过抓包工具在电脑上建立监听让手机的流量也经过这个监听端口就能收集到App的接口流量。收集到一个基础接口清单之后我习惯用表格整理字段接口路径、请求方法、是否需要认证、涉及的核心业务对象、参数类型。这个表格是后续测试的地图。3.2 请求凭证与参数理解抓到了接口下一个问题是怎么让它正常跑起来。API请求凭证一般分三类Header里的Token、Cookie、自定义签名参数。Token的处理方式各家不同有的放在Authorization: Bearer xxx有的放在自定义Header里有的是请求体里带token字段。签名参数是最费劲的——常见有timestamp nonce sign的组合sign是对参数按特定规则加密得到的。遇到这种先要搞清楚签名算法和参与签名的字段不然改一个参数签名就对不上了。我的实操建议是能用抓包工具改包重放就不手动拼请求抓包工具能把已经抓到的请求原样再发一次改参数方便还能做批量替换。复杂的业务逻辑靠脚本我用Python的requests库配合抓包工具导出的请求格式做了个小工具能够对一批ID做自动替换测试。参数理解是测试前的最后一环。拿到一个接口至少要弄清楚哪些参数是标识ID、编号、哪些参数是关联userId、shopId、哪些参数是控制逻辑的page、limit、sort、哪些参数会影响后端行为url、filePath、callback。标识参数是越权的关键url类参数是SSRF的关键这些都值得重点照顾。3.3 高价值接口的优先测试策略接口多到测不完是常态所以必须排优先级。我的策略是从业务影响面倒推涉及资金操作的接口转账、支付回调、订单修改、退款。涉及敏感数据读取的接口用户信息列表、订单全量查询、后台统计报表。涉及权限变更的接口角色修改、用户禁用/启用、审批流操作。涉及数据导入导出的接口Excel导入、批量导出、文件上传下载。涉及交互回调的接口webhook配置、消息推送。优先测这些接口的逻辑漏洞因为它们一旦出问题影响面是数据泄露或资金损失级别的。等这类接口测完了再回头扫一遍注入和配置类问题。工具的选型上我的常用组合是用途工具请求抓取与改包重放抓包工具社区版即可接口列表整理与脚本化测试Postman Python脚本接口路径模糊测试ffufJSON数据格式化查看jq历史接口对比浏览器的开发者工具的请求日志4. 典型场景的验证与利用过程实录以下内容均需在自建靶场或已获得书面授权的测试环境下进行。未授权测试违反法律法规这一点没有商量余地。4.1 场景实录一水平越权的完整验证假设某系统有一个“查看员工工资条”功能前端页面显示当前员工的工资条。整个操作会发起一个请求POST /api/payroll/detail Authorization: Bearer 普通员工Token { billId: P20240715001 }第一步正常访问拿到自己的工资条信息确认接口通路正常。第二步把billId改成一个相邻的编号比如P20240715002再次发送。观察响应如果返回了另一位员工的姓名、部门、工资明细漏洞确认。第三步关键点来了——不要只验证一次就收工。有些接口的越权是有条件的也许只能看到部分字段也许必须在特定时间窗口内才能访问也许只能在某个特定角色下才触发。多测几个ID、多试几个邻近编号把影响范围摸清楚这样写修复建议的时候才能说得准确。第四步检查是否存在批量获取的可能。把billId改成数组类型或者同时提交多个ID看看接口会不会一次性返回多条明细。如果支持批量返回影响面会被放大很多——本来一次越权只能看一条数据批量模式下一次能拖走整年的工资记录。4.2 场景实录二批量赋值拿到管理员角色一个注册接口的常规请求POST /api/user/register { username: test001, password: Passw0rd123 }注册成功响应如下{ code: 0, message: success, data: { userId: 10086, username: test001, role: normal_user } }注意到响应里存在role字段说明服务端对象模型里有这个属性。接下来尝试在注册请求中添加额外的字段POST /api/user/register { username: test002, password: Passw0rd123, role: admin }如果响应里的role变成了admin那服务端就是把请求体里的字段直接绑定到了用户对象上批量赋值漏洞成立。这类验证还要扩展一步——查看是否还有其他的敏感字段可以覆盖。比如把userId设置成别人的ID、balance设置成999999、email_verified设置成true。每个业务模型里都有自己独特的敏感字段能确认一个role就说明绑定机制有问题应该沿着这条思路继续深挖同一接口的其他字段。4.3 场景实录三JWT算法混淆验证目标系统的登录接口正常签发JWT解码后payload结构{ uid: 10001, role: normal, exp: 1721200000 }把Token复制出来在测试请求里用这个Token调用一个需要普通权限的接口确认能正常访问。接着尝试把alg字段改成nonepayload里的uid改成管理员ID签名部分删除直接发送请求。eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJ1aWQiOiIxMDAwMSIsInJvbGUiOiJhZG1pbiIsImV4cCI6MTcyMTIwMDAwMH0.如果服务端接受了这个无签名的Token并返回了管理员权限下的数据说明JWT库配置了允许none算法或验签流程缺失。把这个问题记下来修复方案是强制指定验签算法并拒绝none。JWT这类的验证还有个辅助手段把合法签发的Token内容做修改比如把uid改掉签名保持不变发送。如果服务端没有校验签名和Token内容是否匹配它同样会接受被篡改的Token。这两个小实验建议都做一遍。5. 常见问题与排查技巧实录5.1 测试中的五个常见“卡壳”现场卡壳一修改ID后返回的结果跟原来一模一样。这是IDOR测试中最容易混淆的情况。先说结论这不一定说明没有越权——很可能是参数名没找对或者服务端作了缓存。我遇到过一次改orderId没用但实际上接口真正使用的标识是Header里的X-Order-Id字段。所以排查路径是先确认改的是不是服务端实际使用的参数名再看请求里有没有其它同义字段最后确认响应是否有Cache-Control相关的缓存标记。此外响应相同也可能是接口对越权做了静默处理返回了一个通用的空对象。卡壳二请求返回401。多数情况是Token缺失或已过期但还有一种容易被忽略的情况接口要求的认证方式是自定义Header而测试工具里没有带上。再就是某些接口接受短期Token但不接受长期Token或反过来。排查顺序先确认Token有效性再看接口文档或正常请求里用的哪种认证字段最后确认是不是IP白名单限制。卡壳三返回200但data是空的。这个现象很值得警惕。它往往意味着请求已经进入业务逻辑处理环节但因为某个前置条件不满足被“软拒绝”了。常见原因当前账号确实不在可查询的范围内缺少某些必选参数导致查询结果为空后端的多租户隔离起了作用但接口没有明确返回错误。需要做的是对比正常请求和异常请求的报文差异逐字段排查。卡壳四批量赋值的字段不生效。问题通常不在于“要不要传字段”而在于服务端用了白名单方式只取预定义的字段。这时候单纯加字段没用需要找其他的赋值路径。比如有一个接口专门用来更新用户资料它绑定的是ProfileDTO这里的DTO如果包含role字段那往这个接口塞role就有机会生效。所以批量赋值的测试面不能只看注册和登录接口凡是能修改数据的接口都应该留意。卡壳五抓不到App的流量。现在的App普遍做了证书校验不信任抓包工具的证书导致流量抓不出来。实用的方案是找App里有没有相关的网络安全配置开关或者安装旧版本App部分历史版本没有强校验。如果这些都行不通那就换思路——把App的流量在系统层面做透明转发或者用动态调试手段绕过证书校验。注意这个环节非常依赖具体环境操作前先确认具备测试授权。5.2 测试中容易忽略的三个细节第一个细节旧版本接口未下线。研发迭代快接口路径经常换版本/v1/order换成了/v2/order。但如果/v1/order还继续在服务端运行且没有接入新版的安全校验逻辑那它就是一个泄漏点。我在测试时会特意用工具对相同功能的不同版本接口做一轮对比看是否存在旧接口鉴权更弱的问题。第二个细节错误信息过度详细。很多API在参数非法时会返回完整的堆栈信息、数据库表名、SQL片段。这些信息对定位漏洞和构造下一步攻击非常有价值。测试时遇到响应异常别急着跳过看一下返回体里的message和detail字段。第三个细节批量接口的频率限制。某系统提供了一个“批量查询用户信息”的接口传一组ID就返回一组数据。这种接口如果没有限制单次请求的ID数量就会成为数据拖库的通道。测试时要关注这类接口是否区分了单次上限和总量上限以及是否存在绕过限制的办法。写在最后我个人做API漏洞挖掘这几年最大的收获不是掌握了多少工具而是养成了“先理解业务逻辑再动手测试”的习惯。很多漏洞的钥匙不在Payload里而在你对业务模型的理解里——你得多思考“这个接口本来应该怎么用哪一步会出岔子”。另外想强调一点API漏洞挖掘的底线是授权。所有测试行为都应当在自己有权限的环境中进行。洞挖到了第一时间整理好复现步骤和修复建议提交这是负责任的做法。如果你刚开始接触API安全按照这篇内容里的思路先找一个靶场项目练手把接口收集、参数理解、越权测试各过一遍。踩几个坑之后你对API漏洞的感觉就会完全不一样了。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
