第2章 环境搭建：Burp Suite、Postman与API安全工具
做API安全测试，说白了就是一场攻防对抗。你得先把自己的武器库备齐了，才能去探测目标系统的漏洞。
我个人习惯把工具分为三类：拦截代理、请求构造、自动化扫描。这一章咱们就把这三板斧都搭好。先别急着装软件，先想明白每样工具解决什么问题，这才是老手和新手的区别。
2.1 核心工具链总览
你在项目里最常用的工具，就这三个阵营：
- Burp Suite —— 流量拦截与中间人攻击的核心。我见过不少新手直接用浏览器开发者工具看请求，那只能看自己发出的，根本没法模拟攻击者视角。
- Postman —— 接口调试与批量测试。它其实不只是个HTTP客户端，它的脚本能力能帮你做很多自动化验证。
- 专用安全工具 —— 比如sqlmap、kiterunner、jwt_tool等。这些是针对特定漏洞类型的利器。
下面这张图展示了这些工具在测试流程中的位置。眼睛要盯着数据的流向——从浏览器到Burp，再到目标API，Postman在旁边做辅助验证。
2.2 Burp Suite 安装与配置
Burp Suite 可以说是API渗透的标配。我刚开始用的时候也踩过坑，比如忘了装CA证书，结果全是TLS加密流量，啥也看不了。
安装步骤 其实很简单：
- 去PortSwigger官网下载Community版（免费）或Pro版（付费）。我自己平时用Pro，因为那个主动扫描器能省不少力气。
- 用
java -jar burpsuite_xxx.jar启动。嗯，前提是你得装了JDK 17+。 - 第一次启动后，选Temporary Project，用默认配置就行。
2.2.1 代理设置与证书安装
这里有个关键动作：让Burp能抓到HTTPS流量。你想想看，现在90%的API都是HTTPS，抓不到加密流量就相当于盲人摸象。
配置顺序是这样的：
- Burp里进入 Proxy → Intercept 标签，确保 intercept 按钮为 "Intercept is on"。
- 打开 Proxy → Settings，默认监听地址是
127.0.0.1:8080。如果你要用手机测试，得改成0.0.0.0:8080—— 我提醒一下，这样做有安全风险，别在公开网络里用。 - 浏览器里装SwitchyOmega之类的插件，把代理指向
127.0.0.1:8080。 - 访问
http://burp，下载CA证书并安装到系统信任根。
2.2.2 核心模块速览
| 模块 | 用途 | 在API测试中的角色 |
|---|---|---|
| Proxy | 拦截/修改流量 | 捕获API请求，实时篡改参数 |
| Repeater | 手动重放请求 | 精确测试单个API端点的响应变化 |
| Intruder | 自动化参数枚举 | 爆破、Fuzz、参数探测 |
| Decoder | 编码/解码 | 处理Base64、URL编码等API常见格式 |
| Logger++ | 流量日志 | 记录所有经过代理的请求，便于事后分析 |
你真正要在API测试中频繁使用的，是Proxy + Repeater + Intruder 这三个的组合。Logger++属于辅助，但别小看它——我经常靠翻日志找到遗漏的漏洞点。
2.3 Postman 环境配置与脚本能力
Postman 在安全测试里的角色，和Burp是互补的。Burp管拦截，Postman管构造。
我个人习惯把Postman的环境变量当配置中心。比如不同的API域名、、都写在变量里，测试集合直接引用变量。这样换环境时只需要改一套变量，不用改几百个请求。
环境变量设置示例：
// 在 Postman 的 Environment 中创建
变量名: base_url
初始值: https://api.example.com/v1
当前值: https://api.target.com/v1 // 测试时切换
变量名: auth_
初始值: eyJhbGciOiJIUzI1NiIs...
当前值: <从Burp里复制的真实>2.3.1 Pre-request Script 与 Tests
这是Postman真正强大的地方。你可以用JavaScript写脚本，在请求发出前或响应返回后自动执行逻辑。
举个例子，测试JWT认证时，我经常这样用：
// Pre-request Script: 自动从环境变量注入
const = pm.environment.get("auth_");
pm.request.headers.add({
key: "Authorization",
value: "Bearer " +
});你想想看，如果一个API测试集合有200个请求，每个都要手动填，那还不得疯掉？用脚本一次搞定。
pm.response.to.have.status(200)这样的断言。看起来简单，但批量跑完测试后一眼就能看到哪些请求返回异常，那些异常可能就是漏洞的入口。我曾用这个方法在CI流水线里发现了一个未授权访问的API端点。
2.4 辅助安全工具清单
除了上面两个主力，还有几样小工具得备着。它们不一定每天用，但遇到特定场景时，能帮你省下大把时间。
| 工具名称 | 用途 | 安装方式 |
|---|---|---|
| curl | 命令行HTTP请求 | 系统自带/WSL/brew |
| jq | JSON格式化与过滤 | brew install jq / apt install jq |
| sqlmap | 自动化SQL注入检测 | git clone + python setup.py |
| jwt_tool | JWT令牌安全检测 | git clone + pip install |
| kiterunner | API路径/端点爆破 | 从GitHub Releases下载二进制 |
| wfuzz | Web Fuzz测试 | pip install wfuzz |
2.4.1 一个典型的组合用法
假设你从Burp的Logger里复制了一个POST请求的cURL命令：
curl -X POST "https://api.example.com/user/login" \
-H "Content-Type: application/json" \
-d '{"username":"admin","password":"123456"}' | jq .这个输出直接就是格式化好的JSON。如果你想要提取特定的字段，比如看access_是否存在泄露风险，可以用 jq '.access_'。
2.5 验证环境是否就绪
工具装完了，怎么确认它们真的能协同工作？我建议你跑一个最简单的"冒烟测试"：
- 打开Burp，打开拦截，浏览器设好代理。
- 访问任意一个公开API（比如 httpbin.org/get）。
- 在Burp里看到请求被拦截，点击 Forward 放行。
- 在Burp的Repeater里，直接修改请求参数（比如加一个
?test=1），再发送。 - 用Postman导入同一个请求，加上之前的环境变量，确认能正常返回。
如果以上五步都能跑通，那恭喜你，你的基础环境已经搭好了。别小看这个流程，我见过有团队卡在第一周，就因为在证书安装那一步没配好。
好了，工具链都就位了。接下来你就可以开始真正的API安全测试了——嗯，先别急，在我们实操之前，还是得确保每个工具的版本都是最新的。特别是Burp Pro的扫描器插件，每两周更新一次，老旧版本可能会漏掉最新的漏洞payload。