1. API接口为什么成了攻击者的“香饽饽”这几年做安全测试，我最大的感受就是：Web应用的传统漏洞越来越难挖，但API接口的暴露面反而越来越大。前后端分离架构普及之后，后端逻辑几乎全部通过API对外提供，前端只是一个“壳”。攻击者根本不需要跟你纠缠什么SQL注入、XSS，直接分析你的接口请求，找业务逻辑漏洞，往往一抓一个准。而在所有API漏洞里，未授权访问和越权又是最“朴实无华”但杀伤力最大的两类。所谓未授权，就是不需要登录就能访问需要鉴权的接口；所谓越权，就是登录了A账号，却能操作B账号的数据。这两类漏洞不像RCE那样需要花里胡哨的利用链，更多时候是“看到了，测一下，就出了”。但恰恰因为API接口数量庞大、命名规则各异，靠纯手工一个个去翻JS文件、抓包、猜路径，效率低得让人怀疑人生。BurpAPIFinder这个插件，是我在实际工作中用得比较顺手的API发现工具。它的核心价值就一句话：帮你把目标站点里藏着的API接口快速、批量地找出来，然后你只需要把精力放在验证那些高价值接口的鉴权逻辑上。今天这篇文章，我就从插件原理、安装配置、实战流程到常见坑位，完整拆解一遍我是怎么用BurpAPIFinder做API未授权与越权自动化排查的。不管你是刚入门的安全新人，还是已经在做渗透测试、红队评估的老手，只要你日常工作需要跟API接口打交道，这篇文章应该都能给你一些可落地的参考。2. 为什么选择BurpAPIFinder：它的核心设计思路2.1 它解决的是“接口发现”这个核心痛点做API安全测试，第一步永远是“找到接口在哪里”。很多测试者习惯性地盯着BurpSuite的HTTP History翻，但真实场景里，一次正常的业务操作往往会产生几十上百个请求，其中夹杂着静态资源、第三方统计、埋点上报，真正有价值的业务接口可能只占一小部分。而且，很多接口并不会直接出现在History里——它们藏在JS文件里、藏在WebSocket消息里、藏在注释里，甚至藏在代码混淆之后的字符串中。BurpAPIFinder的思路其实很直接：在BurpSuite的被动流量基础上，主动去JS文件里“捞”接口。它会自动从你浏览过的页面中提取JS文件链接，然后对这些JS文件发起请求，用正则匹配的方式把里面看起来像API路径、API域名、接口参数的字符串全部摘出来。这个过程不需要你手工干预，挂在后台就行。我举个例子。之前测试一个模拟项目X的招标系统，前端框架是Vue全家桶，所有业务都走API。我手动看了半天History，只看到一堆 /api/user/info、/api/login 这类常规接口。但挂了BurpAPIFinder之后，它从main.js和chunk-vendors.js里捞出来几十条带版本号的内部接口，比如 /v1/internal/audit/export、/v1/admin/bid/project/delete，这些才是真正的高价值目标。没有这个插件，我大概率会漏掉一大片攻击面。2.2 和同类工具的简单对比不能说BurpAPIFinder是唯一的选择，但它有几个点让我一直留在BurpSuite生态里用：轻量：就是个Java插件，加载到BurpSuite的Extender里就行，不依赖额外环境。被动加主动结合：不光被动看流量，还能主动拉JS文件做二次解析，覆盖面比纯被动嗅探广。规则可调：正则表达式可以自己改，域名白名单黑名单也能配，灵活性高。结果输出友好：发现的接口直接列在Tab页里，支持导出，方便后续用其他工具批量验证。同类工具里，像JSFinder、APIKit，其实思路也有相近之处。但BurpAPIFinder在BurpSuite内的集成体验更顺，尤其是配合Burp的主动扫描和Intruder做批量验证时，工作流很流畅。提示：插件本身不负责“验证漏洞”，它的职责是“找到接口”。真正判断某个接口是否存在未授权或越权，需要结合后端的响应差异、状态码、数据特征来综合判断。这个我后面实操部分会细说。2.3 核心流程拆解BurpAPIFinder的工作流程可以简化为四步：流量监听：通过被动方式监听BurpSuite代理的所有请求，自动提取其中出现的JS文件URL。JS拉取：对这些JS文件发起Get请求，拿到内容后做静态分析。正则匹配：用内置或自定义的正则规则，从JS内容中匹配API路径、域名、参数名等关键信息。结果聚合：把发现的结构化数据展示在独立Tab页中，并支持筛选、复制、导出。这个流程设计得很聪明，因为JS文件在前后端分离架构里，实际上就是“前端路由表”，大部分接口地址都会暴露在JS bundle里。只要你的爬虫或手动浏览覆盖了足够多的页面，插件就能把接口清单挖得七七八八。3. 环境搭建与插件安装3.1 前置准备要跑BurpAPIFinder，你至少需要准备好这几样东西：一个可以正常工作的BurpSuite（社区版或专业版都行，我用的是专业版，但社区版功能也够用）。Java环境，BurpSuite本身依赖Java运行，版本别太老，建议Java 11以上。一个测试目标，强烈建议在授权的靶场环境里练手，不要直接拿线上站点试，容易出问题。工具链上，我习惯配合这么几个一起用：工具用途BurpSuite主代理工具，负责抓包、改包、重放BurpAPIFinderAPI接口发现浏览器开发者工具手动分析页面结构和JS加载情况一些字典后续路径爆破、参数爆破用3.2 具体安装步骤安装BurpAPIFinder本身不难，但我第一次装的时候还是踩了个小坑，在这里我把步骤写清楚：先到GitHub上把BurpAPIFinder的Release版本下载下来。注意选jar文件，别下成源码。打开BurpSuite，切到Extender标签页。在Extensions子页里，点击Add按钮。Extension Type选Java，然后在Extension File里选到你刚才下载的jar文件。点击Next，等下方输出窗口显示加载成功即可。加载成功之后，BurpSuite主界面会多出一个APIFinder的标签页，这个就是插件的主界面。我遇到的坑是：第一次加载时忘记确认BurpSuite的版本兼容性，加载后插件根本没出现在标签栏里，查了输出日志才发现是不兼容。所以建议下载插件前先看一眼它要求的BurpSuite版本号，尽量保持一致。注意：加载插件后建议重启一次BurpSuite，有些版本不重启直接开代理会概率性不生效。3.3 基本配置项BurpAPIFinder的主界面不算复杂，核心配置集中在几个地方：API域名配置：可以手动添加目标域名，让插件只关注白名单内的接口，减少噪音。比如你要测试的目标是 api.example.com，那就把这个域名加进去。正则规则：插件内置了一些默认正则，能匹配"/api/xxx"、"https://api.xxx.com/yyy"这类常见格式。你也可以根据目标特征增删规则。自动请求JS开关：这个开关建议打开，让插件在发现JS文件后自动去拉取并解析。如果不打开，它就只能靠你手动浏览触发的流量，覆盖率会低很多。去重设置：可以设置对相似URL进行去重合并，避免结果列表里全是重复条目。每个人习惯不一样，我是倾向于把自动请求JS打开、白名单域名填好，然后正常浏览目标网站。浏览得越细，插件采集到的JS就越多，后续接口列表就越全。4. 自动化API接口发现：实战操作全记录4.1 第一步：挂上代理，正常浏览目标如果你以为装好插件就能直接“剑指API”，那还是太年轻了。插件的输入是你浏览过程中产生的流量，所以前期的手动浏览环节至关重要。实际操作中，我会先在BurpSuite里把代理配置好，浏览器走Burp的代理端口。然后开始正常访问目标系统的各个页面：登录页、列表页、详情页、个人中心、管理后台，能点的都点一遍，能翻的页都翻一遍。这样做两个目的：让BurpSuite的History积累足够多的请求样本。让BurpAPIFinder能从这些样本里提取到尽可能多的JS文件链接。有一说一，这一步没法偷懒。我曾经为了省时间，只浏览了登录页和首页就切去做别的了，结果接口列表只出来不到二十条。后来老老实实把整个业务流程走了一遍，接口列表直接翻了好几倍。4.2 第二步：观察APIFinder结果页当你浏览了一定量的页面后，切到APIFinder标签页，会看到一个列表。这个列表每一行就是插件发现的一个API路径或域名。我简单说下各个字段的意思：API路径：比如 /api/user/list 这种，是插件从JS里直接匹配出来的。来源域名：这个接口所属的域名。发现位置：告诉你这个接口是从哪个JS文件里挖出来的，方便溯源。请求方法：部分接口可以从JS调用代码里推断出POST还是GET，插件也会尽量标注。这个列表是支持排序和筛选的，你可以按域名、按路径关键字过滤。比如想看跟“admin”相关的路径，直接在筛选框里输入“admin”即可。4.3 第三步：验证与导出接口列表出来后，别急着全量扔进扫描器。先人工过几遍，目的是大致了解接口的分类和业务归属。有些接口一看就知道是内部接口，比如/v1/internal/...，这类优先关注。有些接口是公开的静态资源接口，比如/api/config、/api/version，价值相对低。有些接口路径里有明显的ID参数，比如/api/order/12345，这类是越权测试的重点。筛选完之后，我一般会把这些接口导出成文本文件，方便后续批量验证。导出按钮在插件界面上很显眼，点一下就能保存。4.4 高级玩法：结合JS逆向精准挖接口只看插件默认匹配结果还不够过瘾。真正高价值的接口，往往藏在混淆过的JS代码里，或者被构建工具改成了难以一眼看出的路径。我的做法是：用BurpAPIFinder定位到某个关键的JS文件之后，再手动打开这个JS文件，用BurpSuite自带的功能做二次分析。比如搜索一些关键字：axios、fetch(、XMLHttpRequest、baseURL、apiUrl、.post(、.get(。这些调用的参数里经常藏着接口路径和参数格式。如果JS被混淆得没法直接看，我还试过把整个JS内容复制出来，格式化一遍再做关键字搜索。虽然效率低一些，但针对高价值目标值得花这点时间。5. 未授权与越权漏洞的自动化验证方法5.1 区分未授权和越权的判断逻辑接口找到之后，问题来了：怎么判断它安不安全？这里先明确两个基础判断逻辑：未授权：直接发送请求，不带任何Cookie或Token，如果接口返回了业务数据而不是401/403，基本就可以判定为未授权访问。越权：用A账号的认证凭证去访问B账号的资源。如果接口返回了B账号的数据，就是水平越权；如果用普通用户身份调用了管理员接口，就是垂直越权。但在自动化验证的时候，这两个场景需要拆开来处理。5.2 未授权测试：批量丢包未授权测试其实最简单。把BurpAPIFinder导出的接口列表整理一下，配合BurpSuite的Intruder模块，做一次批量请求：把接口列表作为Payload，放在请求路径的位置。请求头里不要带Cookie字段，也不带Authorization头。发送方式统一用GET（如果要测POST接口，需要先看接口参数格式，再构造POST包）。勾选BurpSuite的“区分响应状态码和响应长度”功能，观察哪些接口返回了非401/403状态码，或者响应包长度显著偏大。如果一个未带凭证的请求返回了200，而且响应体里出现了业务数据，哪怕只有一条，也基本可以确认存在未授权风险。注意：有些系统用网关统一鉴权，网关会对所有 /api/ 前缀的请求做拦截，这种情况下未授权测试会比较难出结果。但别忘了绕过思路，比如加一个/v1/../api/user/list这种路径混淆，或者试试不带前缀的备用路径，有时候能有意外发现。5.3 越权测试：账号切换与ID遍历越权测试比未授权稍微复杂点，因为你需要两个账号。我的操作流程一般是：先用A账号登录，复制它的Cookie或Token。用BurpAPIFinder找到的某个带ID参数的接口，比如/api/user/profile?uid=10001。用A账号的凭证正常访问一次，确认返回正常。然后用B账号登录，抓取B的Cookie/Token，替换到刚才的请求里。但把URL里的ID参数改成A的uid（比如10001），或者把请求体里的user_id改成A的。观察返回结果：如果B的凭证能拿到A的数据，就是水平越权。听起来简单，但自动化批量测越权时有个关键问题：你没法枚举所有参数的排列组合。所以我的经验是分两步走：先重点测不加参数就能操作的接口（比如删除操作、修改操作的接口），因为这些往往是最危险的。再测带ID参数且语义明显的接口（订单号、用户ID、文件ID、项目ID），手动改一个值试一下，如果越权成立，再考虑用Intruder对ID做批量枚举。还有一点容易被忽略：越权不一定只在URL里有ID。很多JSON格式的POST请求，数据都放在请求体里，比如{"order_id": 12345, "user_id": 67890}。这种接口要验证越权，必须把请求体里的字段也改掉，只看URL是不够的。5.4 利用插件的接口信息做精准验证BurpAPIFinder虽然不直接报告漏洞，但它提供的接口元数据对验证很有帮助。比如它有时候会标注接口的请求方法、参数位置，你就能更快速地构造测试包。另外，插件发现的接口里，往往包含一些管理后台独有的路径。一旦发现这类路径，我会重点测试垂直越权。因为普通的水平越权通常需要两个平行账号，而垂直越权只要一个低权限账号就能测。如果低权限用户能调用管理员的删除接口，这个漏洞的严重程度仅次于RCE。6. 完整实战案例：模拟项目X的API安全测试6.1 目标概况与前期准备为了把整个过程串起来讲，我模拟一个比较典型的场景。目标是一个模拟项目X的在线教育平台，名字不重要，关键信息如下：前端是Vue 2.0 + Element UI。后端接口统一走/api/前缀。用户角色分学生、教师、管理员三种。核心业务包括课程查看、作业提交、成绩管理、用户管理。前期准备就是按照前面说的，配置BurpSuite代理、加载好BurpAPIFinder、设置好目标域名白名单。6.2 发现阶段：接口列表出炉正常浏览了一轮主流程后，我注意到APIFinder的列表里出现了这样几类高价值接口：/api/admin/user/list /api/admin/user/delete /api/teacher/score/update /api/student/homework/submit /api/internal/class/roster/export /api/v1/order/detail看到/api/admin/...和/api/internal/...这种路径，我的直觉告诉我这几个大概率有问题。很多开发习惯把接口路径写得很直白，权限控制却是后补的，漏配的情况很常见。6.3 未授权验证现场我先拿/api/admin/user/list开刀。把这个请求丢进Intruder，删掉Cookie和Authorization头，只保留基础的User-Agent：GET /api/admin/user/list HTTP/1.1 Host: target.example.com User-Agent: Mozilla/5.0 Accept: application/json结果返回：HTTP/1.1 200 OK Content-Type: application/json {"code":0,"data":{"total":1024,"users":[...]}}看到这个响应，我心里基本上有数了。一个管理员的用户列表接口，不带任何身份凭证直接200返回数据，这就是典型的未授权访问。我又顺手测了/api/internal/class/roster/export，同样不带Cookie，结果直接返回了一个班级花名册的Excel文件。这个接口的敏感程度更高，涉及大量学生信息，这种漏洞放到正式环境里，数据泄露风险很大。6.4 越权验证现场未授权测完后，我开始测越权。先注册了学生账号A和B，模拟一下“A能看到B的作业”的场景。正常逻辑下，学生只能看到自己的作业。我抓到的请求是：GET /api/student/homework/detail?homeworkId=1001&studentId=10001我先把A的Cookie带着，请求一次，返回200，正常看到A自己的作业。接着我把请求里的studentId改成10002，其他不动，带着A的Cookie再发一次：GET /api/student/homework/detail?homeworkId=2001&studentId=10002结果又是200，返回了B的作业内容。到这里基本可以确认水平越权存在。这种漏洞不在于你用什么高深技巧，而在于你有没有意识到要改这个参数。BurpAPIFinder的价值就体现在这里——如果没有它批量把接口列出来，我可能压根不会注意到作业详情接口在/api/student/homework/detail这个位置。6.5 垂直越权的额外发现接着我测垂直越权。用学生A的Cookie去请求/api/teacher/score/update，按常理这个接口应该拒绝非教师身份的访问。我构造了一个PUT请求，把某个学生的成绩改成满分：PUT /api/teacher/score/update HTTP/1.1 Host: target.example.com Cookie: studentA_session=xxxx Content-Type: application/json {"studentId":10001,"courseId":101,"score":100}结果返回：HTTP/1.1 200 OK {"code":0,"msg":"success"}我人都麻了，这是非常典型的垂直越权。一个学生身份能修改成绩，而且没有任何角色校验。这种漏洞如果被恶意利用，整个平台的成绩公正性都受影响。整个测试下来，我在这个目标上发现了3个未授权接口、2个水平越权、1个垂直越权。整个过程里BurpAPIFinder负责“找出接口”，我负责“验证逻辑”，分工很明确，效率比手工翻JS高太多了。7. 常见问题与排查技巧实录7.1 插件加载失败怎么办我遇到过几次插件加载失败的情况，常见原因无非这几种：BurpSuite版本太旧：老版本的BurpSuite和一些新插件不兼容，建议升级到最新版。Java版本不对：检查BurpSuite启动日志里报错信息，基本都是Java版本不满足要求。jar包损坏：下载中断导致jar包不完整，重新下载即可。排查方法：看BurpSuite的Extender输出窗口，里面会有具体的Exception信息。不要怕报错，报错信息是最直接的线索。7.2 接口列表太少如果你发现接口列表寥寥无几，先别急着怀疑插件没用，更多可能是输入不够。解决办法：多浏览几个页面，特别是有交互的页面，比如搜索、翻页、详情弹窗。检查自动请求JS开关：如果没打开，插件只能被动等流量，不会主动拉JS文件。手动触发一些AJAX请求：比如点击“加载更多”按钮，这能让你看到动态加载的JS模块。还有一个细节：有些JS文件是动态加载的，只有特定操作才会触发。比如点击某个Tab页才会加载对应的chunk文件。所以测试时要尽量走完整个业务流程，不要只停留在首页。7.3 正则规则匹配不到接口BurpAPIFinder默认的正则规则是通用的，但每个系统的接口命名风格不一样。比如有的系统接口用的是REST风格/api/svc/order/query，有的用的是短路径/o/q，还有的是带时间戳的/api/20240601/order/list。遇到这种情况，就得自己加正则。我一般会在插件的规则配置里加几条基于目标特征的规则。比如：/api/[a-zA-Z0-9]+/[a-zA-Z0-9]+这种规则可以匹配两层路径。如果你的目标是固定风格的，还可以更精准。改了规则之后，记得重新触发一下浏览行为，让插件重新解析已有的JS文件。7.4 流量太大容易漏接口多的时候，BurpSuite的History会非常臃肿，手工审查反而容易漏。我的建议是：先用APIFinder的筛选功能按域名过滤。再按路径关键字分组，比如admin、user、order、pay、export这类业务关键字。按需导出，不要一股脑全塞进扫描器。而且批量验证时，建议把接口按照“含ID参数”和“不含ID参数”分成两组。第一组优先测未授权，第二组优先测越权，这样工作流更清晰。提示：别对线上生产环境跑大量Intruder任务，容易触发风控，也可能给业务带来真实影响。非常不建议在未授权状态下对线上系统进行批量接口测试，测试范围和方法需要提前确认。8. 一些心得与建议BurpAPIFinder终究只是一个帮你找接口的工具，Web安全测试的核心还是在于对业务逻辑的理解。同样面对APIFinder输出的五十个接口，有人只能对着列表发呆，有人却能在三个小时内挖出好几个未授权和越权。差别在哪？我觉得是对请求和响应之间“语义”的敏感度。一个请求接口，如果返回的数据里有手机号、身份证号、订单金额、权限角色这类敏感字段，那它的安全价值天然就高。你在验证时就要重点看它有没有做鉴权和越权校验。反过来说，如果接口返回的只是个静态配置，即使未授权，影响也不大，可以放后面处理。另外，接口测试永远不要只测“理想情况”。很多开发者会做鉴权，但做得不完整。例如只校验了登录状态，却没校验角色；只校验了GET请求，却没限制POST；只守住了URL里的ID，请求体里换个ID就漏了。这些边界情况，才是测试者真正要花时间去钻的地方。我把自己的习惯列一下，给你参考：先看目录，再测逻辑：用插件找到接口后，手动过一遍，按业务模块分类。未授权优先，越权重参数：先批量测未授权，再挑带ID参数的接口测越权。记录要比对：一个接口的不同身份响应必须留存，方便写报告时佐证。别全自动：周边工具可以用来自动化扫描，但至少要手动验证一遍关键漏洞是否存在。再提一句关于工具链的扩展。BurpAPIFinder找到的接口，可以配合一些开放API或在线接口测试平台做后续批量验证。也可以通过脚本把接口列表导出来，批量检测接口是否返回敏感字段。工具是死的人是活的，工作流顺不顺，完全看你平时怎么组织自己的武器库。最后分享一个小技巧：BurpAPIFinder发现的接口里，带export、download、upload这类文件操作关键字的，我都会格外留意。这类接口经常涉及文件系统操作，一旦存在未授权或越权，往往能直接导致敏感文件泄露，危害比普通数据接口大得多。测的时候不妨优先处理，大概率会有惊喜。
1. API接口为什么成了攻击者的“香饽饽”这几年做安全测试，我最大的感受就是：Web应用的传统漏洞越来越难挖，但API接口的暴露面反而越来越大。前后端分离架构普及之后，后端逻辑几乎全部通过API对外提供，前端只是一个“壳”。攻击者根本不需要跟你纠缠什么SQL注入、XSS，直接分析你的接口请求，找业务逻辑漏洞，往往一抓一个准。而在所有API漏洞里，未授权访问和越权又是最“朴实无华”但杀伤力最大的两类。所谓未授权，就是不需要登录就能访问需要鉴权的接口；所谓越权，就是登录了A账号，却能操作B账号的数据。这两类漏洞不像RCE那样需要花里胡哨的利用链，更多时候是“看到了，测一下，就出了”。但恰恰因为API接口数量庞大、命名规则各异，靠纯手工一个个去翻JS文件、抓包、猜路径，效率低得让人怀疑人生。BurpAPIFinder这个插件，是我在实际工作中用得比较顺手的API发现工具。它的核心价值就一句话：帮你把目标站点里藏着的API接口快速、批量地找出来，然后你只需要把精力放在验证那些高价值接口的鉴权逻辑上。今天这篇文章，我就从插件原理、安装配置、实战流程到常见坑位，完整拆解一遍我是怎么用BurpAPIFinder做API未授权与越权自动化排查的。不管你是刚入门的安全新人，还是已经在做渗透测试、红队评估的老手，只要你日常工作需要跟API接口打交道，这篇文章应该都能给你一些可落地的参考。2. 为什么选择BurpAPIFinder：它的核心设计思路2.1 它解决的是“接口发现”这个核心痛点做API安全测试，第一步永远是“找到接口在哪里”。很多测试者习惯性地盯着BurpSuite的HTTP History翻，但真实场景里，一次正常的业务操作往往会产生几十上百个请求，其中夹杂着静态资源、第三方统计、埋点上报，真正有价值的业务接口可能只占一小部分。而且，很多接口并不会直接出现在History里——它们藏在JS文件里、藏在WebSocket消息里、藏在注释里，甚至藏在代码混淆之后的字符串中。BurpAPIFinder的思路其实很直接：在BurpSuite的被动流量基础上，主动去JS文件里“捞”接口。它会自动从你浏览过的页面中提取JS文件链接，然后对这些JS文件发起请求，用正则匹配的方式把里面看起来像API路径、API域名、接口参数的字符串全部摘出来。这个过程不需要你手工干预，挂在后台就行。我举个例子。之前测试一个模拟项目X的招标系统，前端框架是Vue全家桶，所有业务都走API。我手动看了半天History，只看到一堆 /api/user/info、/api/login 这类常规接口。但挂了BurpAPIFinder之后，它从main.js和chunk-vendors.js里捞出来几十条带版本号的内部接口，比如 /v1/internal/audit/export、/v1/admin/bid/project/delete，这些才是真正的高价值目标。没有这个插件，我大概率会漏掉一大片攻击面。2.2 和同类工具的简单对比不能说BurpAPIFinder是唯一的选择，但它有几个点让我一直留在BurpSuite生态里用：轻量：就是个Java插件，加载到BurpSuite的Extender里就行，不依赖额外环境。被动加主动结合：不光被动看流量，还能主动拉JS文件做二次解析，覆盖面比纯被动嗅探广。规则可调：正则表达式可以自己改，域名白名单黑名单也能配，灵活性高。结果输出友好：发现的接口直接列在Tab页里，支持导出，方便后续用其他工具批量验证。同类工具里，像JSFinder、APIKit，其实思路也有相近之处。但BurpAPIFinder在BurpSuite内的集成体验更顺，尤其是配合Burp的主动扫描和Intruder做批量验证时，工作流很流畅。提示：插件本身不负责“验证漏洞”，它的职责是“找到接口”。真正判断某个接口是否存在未授权或越权，需要结合后端的响应差异、状态码、数据特征来综合判断。这个我后面实操部分会细说。2.3 核心流程拆解BurpAPIFinder的工作流程可以简化为四步：流量监听：通过被动方式监听BurpSuite代理的所有请求，自动提取其中出现的JS文件URL。JS拉取：对这些JS文件发起Get请求，拿到内容后做静态分析。正则匹配：用内置或自定义的正则规则，从JS内容中匹配API路径、域名、参数名等关键信息。结果聚合：把发现的结构化数据展示在独立Tab页中，并支持筛选、复制、导出。这个流程设计得很聪明，因为JS文件在前后端分离架构里，实际上就是“前端路由表”，大部分接口地址都会暴露在JS bundle里。只要你的爬虫或手动浏览覆盖了足够多的页面，插件就能把接口清单挖得七七八八。3. 环境搭建与插件安装3.1 前置准备要跑BurpAPIFinder，你至少需要准备好这几样东西：一个可以正常工作的BurpSuite（社区版或专业版都行，我用的是专业版，但社区版功能也够用）。Java环境，BurpSuite本身依赖Java运行，版本别太老，建议Java 11以上。一个测试目标，强烈建议在授权的靶场环境里练手，不要直接拿线上站点试，容易出问题。工具链上，我习惯配合这么几个一起用：工具用途BurpSuite主代理工具，负责抓包、改包、重放BurpAPIFinderAPI接口发现浏览器开发者工具手动分析页面结构和JS加载情况一些字典后续路径爆破、参数爆破用3.2 具体安装步骤安装BurpAPIFinder本身不难，但我第一次装的时候还是踩了个小坑，在这里我把步骤写清楚：先到GitHub上把BurpAPIFinder的Release版本下载下来。注意选jar文件，别下成源码。打开BurpSuite，切到Extender标签页。在Extensions子页里，点击Add按钮。Extension Type选Java，然后在Extension File里选到你刚才下载的jar文件。点击Next，等下方输出窗口显示加载成功即可。加载成功之后，BurpSuite主界面会多出一个APIFinder的标签页，这个就是插件的主界面。我遇到的坑是：第一次加载时忘记确认BurpSuite的版本兼容性，加载后插件根本没出现在标签栏里，查了输出日志才发现是不兼容。所以建议下载插件前先看一眼它要求的BurpSuite版本号，尽量保持一致。注意：加载插件后建议重启一次BurpSuite，有些版本不重启直接开代理会概率性不生效。3.3 基本配置项BurpAPIFinder的主界面不算复杂，核心配置集中在几个地方：API域名配置：可以手动添加目标域名，让插件只关注白名单内的接口，减少噪音。比如你要测试的目标是 api.example.com，那就把这个域名加进去。正则规则：插件内置了一些默认正则，能匹配"/api/xxx"、"https://api.xxx.com/yyy"这类常见格式。你也可以根据目标特征增删规则。自动请求JS开关：这个开关建议打开，让插件在发现JS文件后自动去拉取并解析。如果不打开，它就只能靠你手动浏览触发的流量，覆盖率会低很多。去重设置：可以设置对相似URL进行去重合并，避免结果列表里全是重复条目。每个人习惯不一样，我是倾向于把自动请求JS打开、白名单域名填好，然后正常浏览目标网站。浏览得越细，插件采集到的JS就越多，后续接口列表就越全。4. 自动化API接口发现：实战操作全记录4.1 第一步：挂上代理，正常浏览目标如果你以为装好插件就能直接“剑指API”，那还是太年轻了。插件的输入是你浏览过程中产生的流量，所以前期的手动浏览环节至关重要。实际操作中，我会先在BurpSuite里把代理配置好，浏览器走Burp的代理端口。然后开始正常访问目标系统的各个页面：登录页、列表页、详情页、个人中心、管理后台，能点的都点一遍，能翻的页都翻一遍。这样做两个目的：让BurpSuite的History积累足够多的请求样本。让BurpAPIFinder能从这些样本里提取到尽可能多的JS文件链接。有一说一，这一步没法偷懒。我曾经为了省时间，只浏览了登录页和首页就切去做别的了，结果接口列表只出来不到二十条。后来老老实实把整个业务流程走了一遍，接口列表直接翻了好几倍。4.2 第二步：观察APIFinder结果页当你浏览了一定量的页面后，切到APIFinder标签页，会看到一个列表。这个列表每一行就是插件发现的一个API路径或域名。我简单说下各个字段的意思：API路径：比如 /api/user/list 这种，是插件从JS里直接匹配出来的。来源域名：这个接口所属的域名。发现位置：告诉你这个接口是从哪个JS文件里挖出来的，方便溯源。请求方法：部分接口可以从JS调用代码里推断出POST还是GET，插件也会尽量标注。这个列表是支持排序和筛选的，你可以按域名、按路径关键字过滤。比如想看跟“admin”相关的路径，直接在筛选框里输入“admin”即可。4.3 第三步：验证与导出接口列表出来后，别急着全量扔进扫描器。先人工过几遍，目的是大致了解接口的分类和业务归属。有些接口一看就知道是内部接口，比如/v1/internal/...，这类优先关注。有些接口是公开的静态资源接口，比如/api/config、/api/version，价值相对低。有些接口路径里有明显的ID参数，比如/api/order/12345，这类是越权测试的重点。筛选完之后，我一般会把这些接口导出成文本文件，方便后续批量验证。导出按钮在插件界面上很显眼，点一下就能保存。4.4 高级玩法：结合JS逆向精准挖接口只看插件默认匹配结果还不够过瘾。真正高价值的接口，往往藏在混淆过的JS代码里，或者被构建工具改成了难以一眼看出的路径。我的做法是：用BurpAPIFinder定位到某个关键的JS文件之后，再手动打开这个JS文件，用BurpSuite自带的功能做二次分析。比如搜索一些关键字：axios、fetch(、XMLHttpRequest、baseURL、apiUrl、.post(、.get(。这些调用的参数里经常藏着接口路径和参数格式。如果JS被混淆得没法直接看，我还试过把整个JS内容复制出来，格式化一遍再做关键字搜索。虽然效率低一些，但针对高价值目标值得花这点时间。5. 未授权与越权漏洞的自动化验证方法5.1 区分未授权和越权的判断逻辑接口找到之后，问题来了：怎么判断它安不安全？这里先明确两个基础判断逻辑：未授权：直接发送请求，不带任何Cookie或Token，如果接口返回了业务数据而不是401/403，基本就可以判定为未授权访问。越权：用A账号的认证凭证去访问B账号的资源。如果接口返回了B账号的数据，就是水平越权；如果用普通用户身份调用了管理员接口，就是垂直越权。但在自动化验证的时候，这两个场景需要拆开来处理。5.2 未授权测试：批量丢包未授权测试其实最简单。把BurpAPIFinder导出的接口列表整理一下，配合BurpSuite的Intruder模块，做一次批量请求：把接口列表作为Payload，放在请求路径的位置。请求头里不要带Cookie字段，也不带Authorization头。发送方式统一用GET（如果要测POST接口，需要先看接口参数格式，再构造POST包）。勾选BurpSuite的“区分响应状态码和响应长度”功能，观察哪些接口返回了非401/403状态码，或者响应包长度显著偏大。如果一个未带凭证的请求返回了200，而且响应体里出现了业务数据，哪怕只有一条，也基本可以确认存在未授权风险。注意：有些系统用网关统一鉴权，网关会对所有 /api/ 前缀的请求做拦截，这种情况下未授权测试会比较难出结果。但别忘了绕过思路，比如加一个/v1/../api/user/list这种路径混淆，或者试试不带前缀的备用路径，有时候能有意外发现。5.3 越权测试：账号切换与ID遍历越权测试比未授权稍微复杂点，因为你需要两个账号。我的操作流程一般是：先用A账号登录，复制它的Cookie或Token。用BurpAPIFinder找到的某个带ID参数的接口，比如/api/user/profile?uid=10001。用A账号的凭证正常访问一次，确认返回正常。然后用B账号登录，抓取B的Cookie/Token，替换到刚才的请求里。但把URL里的ID参数改成A的uid（比如10001），或者把请求体里的user_id改成A的。观察返回结果：如果B的凭证能拿到A的数据，就是水平越权。听起来简单，但自动化批量测越权时有个关键问题：你没法枚举所有参数的排列组合。所以我的经验是分两步走：先重点测不加参数就能操作的接口（比如删除操作、修改操作的接口），因为这些往往是最危险的。再测带ID参数且语义明显的接口（订单号、用户ID、文件ID、项目ID），手动改一个值试一下，如果越权成立，再考虑用Intruder对ID做批量枚举。还有一点容易被忽略：越权不一定只在URL里有ID。很多JSON格式的POST请求，数据都放在请求体里，比如{"order_id": 12345, "user_id": 67890}。这种接口要验证越权，必须把请求体里的字段也改掉，只看URL是不够的。5.4 利用插件的接口信息做精准验证BurpAPIFinder虽然不直接报告漏洞，但它提供的接口元数据对验证很有帮助。比如它有时候会标注接口的请求方法、参数位置，你就能更快速地构造测试包。另外，插件发现的接口里，往往包含一些管理后台独有的路径。一旦发现这类路径，我会重点测试垂直越权。因为普通的水平越权通常需要两个平行账号，而垂直越权只要一个低权限账号就能测。如果低权限用户能调用管理员的删除接口，这个漏洞的严重程度仅次于RCE。6. 完整实战案例：模拟项目X的API安全测试6.1 目标概况与前期准备为了把整个过程串起来讲，我模拟一个比较典型的场景。目标是一个模拟项目X的在线教育平台，名字不重要，关键信息如下：前端是Vue 2.0 + Element UI。后端接口统一走/api/前缀。用户角色分学生、教师、管理员三种。核心业务包括课程查看、作业提交、成绩管理、用户管理。前期准备就是按照前面说的，配置BurpSuite代理、加载好BurpAPIFinder、设置好目标域名白名单。6.2 发现阶段：接口列表出炉正常浏览了一轮主流程后，我注意到APIFinder的列表里出现了这样几类高价值接口：/api/admin/user/list /api/admin/user/delete /api/teacher/score/update /api/student/homework/submit /api/internal/class/roster/export /api/v1/order/detail看到/api/admin/...和/api/internal/...这种路径，我的直觉告诉我这几个大概率有问题。很多开发习惯把接口路径写得很直白，权限控制却是后补的，漏配的情况很常见。6.3 未授权验证现场我先拿/api/admin/user/list开刀。把这个请求丢进Intruder，删掉Cookie和Authorization头，只保留基础的User-Agent：GET /api/admin/user/list HTTP/1.1 Host: target.example.com User-Agent: Mozilla/5.0 Accept: application/json结果返回：HTTP/1.1 200 OK Content-Type: application/json {"code":0,"data":{"total":1024,"users":[...]}}看到这个响应，我心里基本上有数了。一个管理员的用户列表接口，不带任何身份凭证直接200返回数据，这就是典型的未授权访问。我又顺手测了/api/internal/class/roster/export，同样不带Cookie，结果直接返回了一个班级花名册的Excel文件。这个接口的敏感程度更高，涉及大量学生信息，这种漏洞放到正式环境里，数据泄露风险很大。6.4 越权验证现场未授权测完后，我开始测越权。先注册了学生账号A和B，模拟一下“A能看到B的作业”的场景。正常逻辑下，学生只能看到自己的作业。我抓到的请求是：GET /api/student/homework/detail?homeworkId=1001&studentId=10001我先把A的Cookie带着，请求一次，返回200，正常看到A自己的作业。接着我把请求里的studentId改成10002，其他不动，带着A的Cookie再发一次：GET /api/student/homework/detail?homeworkId=2001&studentId=10002结果又是200，返回了B的作业内容。到这里基本可以确认水平越权存在。这种漏洞不在于你用什么高深技巧，而在于你有没有意识到要改这个参数。BurpAPIFinder的价值就体现在这里——如果没有它批量把接口列出来，我可能压根不会注意到作业详情接口在/api/student/homework/detail这个位置。6.5 垂直越权的额外发现接着我测垂直越权。用学生A的Cookie去请求/api/teacher/score/update，按常理这个接口应该拒绝非教师身份的访问。我构造了一个PUT请求，把某个学生的成绩改成满分：PUT /api/teacher/score/update HTTP/1.1 Host: target.example.com Cookie: studentA_session=xxxx Content-Type: application/json {"studentId":10001,"courseId":101,"score":100}结果返回：HTTP/1.1 200 OK {"code":0,"msg":"success"}我人都麻了，这是非常典型的垂直越权。一个学生身份能修改成绩，而且没有任何角色校验。这种漏洞如果被恶意利用，整个平台的成绩公正性都受影响。整个测试下来，我在这个目标上发现了3个未授权接口、2个水平越权、1个垂直越权。整个过程里BurpAPIFinder负责“找出接口”，我负责“验证逻辑”，分工很明确，效率比手工翻JS高太多了。7. 常见问题与排查技巧实录7.1 插件加载失败怎么办我遇到过几次插件加载失败的情况，常见原因无非这几种：BurpSuite版本太旧：老版本的BurpSuite和一些新插件不兼容，建议升级到最新版。Java版本不对：检查BurpSuite启动日志里报错信息，基本都是Java版本不满足要求。jar包损坏：下载中断导致jar包不完整，重新下载即可。排查方法：看BurpSuite的Extender输出窗口，里面会有具体的Exception信息。不要怕报错，报错信息是最直接的线索。7.2 接口列表太少如果你发现接口列表寥寥无几，先别急着怀疑插件没用，更多可能是输入不够。解决办法：多浏览几个页面，特别是有交互的页面，比如搜索、翻页、详情弹窗。检查自动请求JS开关：如果没打开，插件只能被动等流量，不会主动拉JS文件。手动触发一些AJAX请求：比如点击“加载更多”按钮，这能让你看到动态加载的JS模块。还有一个细节：有些JS文件是动态加载的，只有特定操作才会触发。比如点击某个Tab页才会加载对应的chunk文件。所以测试时要尽量走完整个业务流程，不要只停留在首页。7.3 正则规则匹配不到接口BurpAPIFinder默认的正则规则是通用的，但每个系统的接口命名风格不一样。比如有的系统接口用的是REST风格/api/svc/order/query，有的用的是短路径/o/q，还有的是带时间戳的/api/20240601/order/list。遇到这种情况，就得自己加正则。我一般会在插件的规则配置里加几条基于目标特征的规则。比如：/api/[a-zA-Z0-9]+/[a-zA-Z0-9]+这种规则可以匹配两层路径。如果你的目标是固定风格的，还可以更精准。改了规则之后，记得重新触发一下浏览行为，让插件重新解析已有的JS文件。7.4 流量太大容易漏接口多的时候，BurpSuite的History会非常臃肿，手工审查反而容易漏。我的建议是：先用APIFinder的筛选功能按域名过滤。再按路径关键字分组，比如admin、user、order、pay、export这类业务关键字。按需导出，不要一股脑全塞进扫描器。而且批量验证时，建议把接口按照“含ID参数”和“不含ID参数”分成两组。第一组优先测未授权，第二组优先测越权，这样工作流更清晰。提示：别对线上生产环境跑大量Intruder任务，容易触发风控，也可能给业务带来真实影响。非常不建议在未授权状态下对线上系统进行批量接口测试，测试范围和方法需要提前确认。8. 一些心得与建议BurpAPIFinder终究只是一个帮你找接口的工具，Web安全测试的核心还是在于对业务逻辑的理解。同样面对APIFinder输出的五十个接口，有人只能对着列表发呆，有人却能在三个小时内挖出好几个未授权和越权。差别在哪？我觉得是对请求和响应之间“语义”的敏感度。一个请求接口，如果返回的数据里有手机号、身份证号、订单金额、权限角色这类敏感字段，那它的安全价值天然就高。你在验证时就要重点看它有没有做鉴权和越权校验。反过来说，如果接口返回的只是个静态配置，即使未授权，影响也不大，可以放后面处理。另外，接口测试永远不要只测“理想情况”。很多开发者会做鉴权，但做得不完整。例如只校验了登录状态，却没校验角色；只校验了GET请求，却没限制POST；只守住了URL里的ID，请求体里换个ID就漏了。这些边界情况，才是测试者真正要花时间去钻的地方。我把自己的习惯列一下，给你参考：先看目录，再测逻辑：用插件找到接口后，手动过一遍，按业务模块分类。未授权优先，越权重参数：先批量测未授权，再挑带ID参数的接口测越权。记录要比对：一个接口的不同身份响应必须留存，方便写报告时佐证。别全自动：周边工具可以用来自动化扫描，但至少要手动验证一遍关键漏洞是否存在。再提一句关于工具链的扩展。BurpAPIFinder找到的接口，可以配合一些开放API或在线接口测试平台做后续批量验证。也可以通过脚本把接口列表导出来，批量检测接口是否返回敏感字段。工具是死的人是活的，工作流顺不顺，完全看你平时怎么组织自己的武器库。最后分享一个小技巧：BurpAPIFinder发现的接口里，带export、download、upload这类文件操作关键字的，我都会格外留意。这类接口经常涉及文件系统操作，一旦存在未授权或越权，往往能直接导致敏感文件泄露，危害比普通数据接口大得多。测的时候不妨优先处理，大概率会有惊喜。