Fiddler+Postman+Wireshark三件套实战：从原理到抓取API安全漏洞
1. 项目概述：为什么需要三件套来抓接口漏洞？
在今天的应用开发里，接口（API）就是数据流动的血管。一个看似不起眼的接口漏洞，比如忘记验证用户权限，或者参数能被随意篡改，轻则导致用户信息泄露，重则可能让整个业务系统瘫痪。很多开发者和安全测试人员有个误区，觉得接口安全就是后端开发的事儿，写完代码跑通逻辑就完事了。但实际上，前端传过来的数据、网络传输的过程、甚至一个被遗忘的测试接口，都可能成为攻击的入口。
光靠看后端日志和代码审计，就像只检查了保险箱的锁，却忘了窗户可能没关。你需要主动出击，模拟攻击者的行为去“抓”漏洞。这就是为什么我强烈推荐将 Fiddler、Postman 和 Wireshark 这三款工具组合使用。它们分别覆盖了应用层交互、接口构造与批量测试、以及网络底层流量分析这三个关键层面，构成了一个从“请求构造”到“流量窥探”的完整安全测试闭环。
Fiddler 中文版是你的“请求手术刀”，它能拦截、修改、重放任何经过你设备的 HTTP/HTTPS 请求，让你能像黑客一样，实时篡改关键数据。Postman 是你的“批量测试工厂”，当你发现一个可疑参数时，可以用它快速生成成千上万种恶意输入组合进行轰炸测试。而 Wireshark 则是你的“网络显微镜”，它能抓取最底层的网络数据包，帮你验证敏感信息是否在传输过程中“裸奔”。接下来，我就结合我这些年踩过的坑和实战经验，带你一步步掌握这套组合拳，把隐藏的接口漏洞一个个揪出来。
2. 环境准备与工具配置要点
工欲善其事，必先利其器。在开始抓漏洞之前，确保你的工具环境配置正确、高效，能让你在后续的测试中事半功倍。这里面的门道，远不止点击“下一步”安装那么简单。
2.1 Fiddler Classic 中文版的安装与核心配置
首先，去 Telerik 官网下载 Fiddler Classic。虽然现在有 Fiddler Everywhere，但对于深度安全测试，Classic 版本因其强大的断点、自定义规则和脚本能力，依然是首选。安装时，建议以管理员身份运行安装程序，避免后续抓取某些系统进程流量时出现权限问题。
安装完成后，第一件事是配置信任根证书。Fiddler 要解密 HTTPS 流量，必须在你的系统中安装一个它自己生成的证书。打开 Fiddler，进入Tools -> Options -> HTTPS选项卡，勾选 “Capture HTTPS CONNECTs” 和 “Decrypt HTTPS traffic”。然后点击 “Actions” 按钮，选择 “Trust Root Certificate”。这一步至关重要，否则你看到的 HTTPS 流量都是一片乱码。完成后，最好再导出证书（同一面板下的 “Export Root Certificate to Desktop”），并手动导入到你的浏览器或系统证书存储区，确保所有流量都能被正确解密。
注意：在测试完成后，尤其是使用公共或不信任的电脑时，记得回到这个界面，点击 “Remove Root Certificate” 移除证书，这是一个基本的安全习惯。
接下来是过滤设置，这是提升效率的关键。在测试时，你的 Fiddler 可能会抓到大量浏览器插件、系统更新等无关流量，干扰视线。在右侧的 “Filters” 标签页中，勾选 “Use Filters”。一个常用的策略是：在 “Hosts” 区域选择 “Show only the following Hosts”，然后填入你目标测试的域名或IP，比如*.your-test-api.com。这样，Fiddler 就只显示与你目标接口相关的流量了。
2.2 Postman 的协作环境搭建
Postman 的安装很简单，从官网下载即可。这里我想强调的是“工作空间（Workspace）”和“环境变量（Environment Variables）”的配置，这对于高效的安全测试至关重要。
创建一个专门用于安全测试的工作空间。然后，针对你的测试目标，创建一个环境，例如命名为 “Security_Test_Prod”。在这个环境里，预定义一些变量：
base_url: 你的目标 API 基础地址，如https://api.example.com。auth_token: 用于存放登录后获取的 Token。user_id: 测试用户的 ID。malicious_payloads: 可以是一个指向本地文件路径的变量，存放你的 SQL 注入、XSS 等测试载荷。
这样做的好处是，当你编写测试用例时，请求 URL 可以写成{{base_url}}/api/user/{{user_id}}/profile，授权头可以写成Bearer {{auth_token}}。切换测试环境（如从测试环境切到生产环境）只需更换环境，所有请求自动适配。更重要的是，当你用 Fiddler 抓取 Postman 发出的流量时，这些变量已经被替换为实际值，方便你分析具体的请求内容。
2.3 Wireshark 的抓包接口选择与过滤语法
Wireshark 的安装同样直接。打开后，第一个挑战是选择正确的网络接口。你会看到一个列表，可能有“WLAN”、“以太网”、“本地连接*”等。如果你用的是有线网络，就选以太网对应的接口；如果是 WiFi，就选 WLAN 接口。一个快速判断的方法是：观察“Packets”列的数值，在你点击接口时，哪个的数值在快速增加，哪个就是你正在使用的活动接口。
双击选中的接口开始抓包，瞬间你会看到海量的数据包滚动，这几乎无法分析。此时，过滤语法就是你的救命稻草。在过滤器栏输入表达式：
- 按IP过滤：
ip.addr == 192.168.1.100（只显示与该IP地址相关的所有流量）。 - 按端口过滤：
tcp.port == 443（只显示 HTTPS 流量）。 - 按协议过滤：
http或tls。 - 组合过滤：
ip.src == 192.168.1.1 and tcp.port == 80（显示来自特定IP且目标端口为80的流量）。
对于接口测试，一个非常实用的过滤条件是http contains “password”或tls.app_data contains “token”，这可以帮助你快速定位可能以明文传输敏感信息的请求。不过要注意，对于 HTTPS 的tls.app_data，只有在没有完全加密或你能解密 TLS 的情况下才能看到内容，通常这用于检查是否意外使用了 HTTP 协议。
3. 核心漏洞挖掘实战流程
环境准备好后，我们就可以进入正题了。漏洞挖掘不是漫无目的地乱点，而是有策略、有步骤的“外科手术”。下面这套流程，是我在多次渗透测试和代码审计中总结出来的高效路径。
3.1 信息收集与接口探测
在发起任何攻击之前，充分的信息收集是成功的一半。你的目标不仅仅是已知的接口，更要发现那些“隐藏”或“被遗忘”的接口。
使用 Fiddler 进行被动爬取：正常操作你的网页或 App，让 Fiddler 在后台记录所有流量。不要只关注主要的业务功能，多点击那些边角料，比如“忘记密码”、“用户协议”、“版本更新检查”等页面。这些地方常常会调用一些不为人知的 API。将 Fiddler 抓取到的所有 Session 导出为.saz文件。然后，你可以使用 Fiddler 的“文件 -> 导出 -> 所有 Sessions”功能，或者使用一些第三方脚本，将这些请求的 URL、方法（GET/POST）、参数列表提取出来，形成一个专属的接口清单。
主动扫描与目录爆破：将上面得到的接口路径作为基础，结合常见的 API 路径字典（如/api/v1/、/admin/、/debug/、/test/、/swagger/等），使用 Postman 的 Runner 功能或专门的扫描工具（如dirsearch、ffuf，这里仅作原理说明）进行批量请求。在 Postman 中，你可以创建一个 Collection，将猜测的路径作为变量，然后批量发送请求，根据响应状态码（200、403、500等）和响应体长度来判断接口是否存在以及是否可访问。一个返回 200 状态码但本该不存在的/api/test/clearDatabase接口，就是一个重大发现。
3.2 身份认证与授权漏洞挖掘
这是最常见也最危险的漏洞类型。核心思路是：在拥有一个合法身份和请求的基础上，尝试越权访问他人的数据或功能。
未授权访问（Missing Authorization）：用你的测试账号正常登录，在 Fiddler 中找到一个需要权限的请求，例如GET /api/admin/users。右键该请求，选择 “Breakpoint -> Before Requests”。再次在浏览器或 App 中触发这个请求，Fiddler 会中断它。在右侧的 “Inspectors” 标签页的 “Headers” 部分，直接删除整个Authorization: Bearer ...或Cookie头部。然后点击 “Run to Completion” 放行这个被“阉割”的请求。观察响应：如果仍然返回了用户列表（200 OK），或者只是返回一个模糊的错误如{“code”: 400, “msg”: “参数错误”}，而不是明确的401 Unauthorized或403 Forbidden，那么这就是一个典型的未授权访问漏洞。攻击者无需登录即可直接获取敏感数据。
水平越权（Insecure Direct Object References, IDOR）：假设你抓到一个请求GET /api/user/12345/profile，返回的是用户 12345 的资料。在 Fiddler 中设置断点，将这个 URL 中的12345修改为12346，然后放行。如果返回了用户 12346 的资料，说明后端只通过 URL 参数来判断数据归属，没有在服务器端校验当前登录用户是否有权访问该 ID 对应的资源，这就是 IDOR 漏洞。攻击者可以遍历用户 ID，窃取所有用户信息。
垂直越权：用一个普通用户账号登录，抓取到一个管理员功能接口的请求（可能是你通过信息收集发现的/api/admin/exportData）。尝试用普通用户的 Token 去访问它。如果成功，说明后端只验证了 Token 的有效性，但没有校验 Token 对应的用户角色或权限等级。
3.3 业务逻辑与参数篡改测试
这类漏洞不依赖于任何技术栈，纯粹是业务逻辑设计缺陷。Fiddler 的断点修改功能在这里大放异彩。
金额/数量篡改：在电商、支付场景中最为致命。拦截一个创建订单或支付的请求，在请求体（如 JSON 或 Form Data）中找到amount、price、quantity等字段。例如，将”total_amount”: 100.00改为”total_amount”: 0.01，或者将”quantity”: 1改为”quantity”: -999。放行请求，观察后端是否只依赖前端传来的值进行扣款或库存扣除。如果后端没有用订单号去数据库查询并核对商品单价和总价，这个漏洞就可能让用户以极低价格购买商品，或者通过负数“增加”库存。
状态篡改：拦截一个业务流程中的请求，比如“申请退货”。请求体中可能有”status”: “applying”。尝试修改为”status”: “refunded”或”status”: “approved”，直接跳过审核流程。这考验的是后端每一步状态流转的严格校验。
标识符篡改：类似于 IDOR，但更侧重于业务标识。例如，在提交一个涉及优惠券的请求时，将”coupon_id”: “NEW_USER_10”改为”coupon_id”: “VIP_FREE”，尝试使用不属于自己的高级优惠券。
3.4 输入验证与注入漏洞探测
当参数篡改测试发现后端似乎会对关键业务参数做校验时，攻击面就转向了更传统的输入验证漏洞。这里需要 Postman 出场，进行批量、系统的 payload 测试。
构造测试集合：在 Postman 中，为你找到的每个可疑接口（尤其是带有查询参数、请求体参数的接口）创建一个请求。然后，为这个请求编写测试用例（Tests），但更高效的方法是使用Collection Runner或Newman（命令行工具）进行数据驱动测试。
准备攻击载荷文件：创建一个 CSV 或 JSON 文件，里面包含各种恶意输入：
- SQL 注入：
‘ OR ‘1’=’1，admin’--，1; DROP TABLE users。 - XSS（跨站脚本）：
<script>alert(1)</script>，<img src=x onerror=alert(1)>。 - 命令注入：
127.0.0.1; ls -la，|| ping -c 5 your-attack-server.com。 - 路径遍历：
../../../etc/passwd，..\..\windows\system32\drivers\etc\hosts。 - 特殊字符与边界值：超长字符串（如10000个‘A’）、空值
null、空字符串“”、极大/极小整数、浮点数、科学计数法。
执行批量测试：在 Postman 的 Collection Runner 中，选择你的接口集合和准备好的数据文件，将数据文件中的变量（如{{payload}}）绑定到请求的参数位置上。然后运行。同时，开启 Fiddler 监听 Postman 的流量（确保 Postman 的代理设置为 Fiddler 的127.0.0.1:8888）。这样，你不仅能看到 Postman 的测试结果（响应状态码、时间），还能在 Fiddler 中观察每一个具体请求和响应的细节，特别是数据库错误信息、异常堆栈跟踪等，这些是判断漏洞是否存在的关键证据。
3.5 会话管理与重放攻击验证
会话管理漏洞允许攻击者劫持或滥用用户的会话。重放攻击是其中一种。
会话固定与 Token 泄露：在 Fiddler 中，仔细观察登录过程的流量。登录成功后，服务器返回的 Token 或 Session ID 是否在响应体中明文传输？这个 Token 是否过于简单（如短数字、有规律）？用这个 Token 替换其他请求的认证头，是否能一直有效？如果 Token 没有和客户端指纹（如 IP、User-Agent）绑定，且失效时间过长，风险就很高。
重放攻击实操：找到一个有状态的请求，比如“转账”、“修改密码”、“使用优惠券”。在 Fiddler 中，右键该请求，选择 “Replay -> Reissue Requests”。你可以多次重放，或者使用 “Replay -> Reissue and Edit…” 在重放前稍作修改（比如改个金额）。观察后端处理：第二次及以后的相同请求是否仍然成功？如果成功，说明后端缺乏防重放机制。一个健壮的接口应该使用一次性的 Nonce（随机数）、时间戳校验或者请求流水号来确保同一笔业务请求不能被重复执行。
4. 网络层与传输安全深度检查
应用层的测试做完后，我们需要把视角下沉到网络传输层。有些漏洞在应用层日志里风平浪静，但在网络流量里却原形毕露。这就是 Wireshark 的战场。
4.1 明文传输与敏感信息泄露排查
这是最基础也最致命的问题。即使你的 API 用了 HTTPS，也可能存在配置不当。
全局抓包与过滤：启动 Wireshark，在目标设备上（可以是手机，通过设置代理到电脑；也可以是运行服务的服务器本身）进行正常的业务操作，特别是登录、注册、支付、查看敏感信息等。在 Wireshark 中，使用过滤条件http。这会过滤出所有明文 HTTP 流量。逐条检查，看是否有你的目标域名或 IP 的请求。如果发现，立即拉响警报，这意味着该接口完全没有加密。
深入 HTTPS 流量检查：对于 HTTPS 流量，正常情况下你看到的是 TLS 握手和应用数据（加密的）。但是，你可以关注几个点：
- 证书：在 TLS 握手包中，查看服务器发送的证书是否有效、是否由可信机构签发、是否与域名匹配。自签名证书或过期证书可能存在中间人攻击风险。
- 协议与加密套件：检查 TLS 握手阶段协商使用的协议版本（应避免 SSLv2, SSLv3， 优先使用 TLS 1.2+）和加密套件（应避免使用弱加密算法如 RC4、DES）。
- 意外明文：有时开发者在调试时，可能会在 URL 参数、Cookie 甚至某个自定义头里泄露信息。虽然 HTTPS 包内容本身加密，但某些元信息可能暴露。更关键的是，检查是否有非 HTTPS 的请求混杂其中，比如一些图片、JS 文件通过 HTTP 加载，这可能导致混合内容问题，或泄露 Referer 头。
一个实战技巧：在 Wireshark 中，使用tls and (frame contains “password” or frame contains “token”)这样的过滤条件尝试搜索（虽然内容加密，但某些特定模式或长度可能有助于发现可疑流量），或者直接搜索http.request.uri contains “login”来定位登录请求，观察其是否使用了 HTTPS。
4.2 协议分析与异常行为识别
Wireshark 不仅能看内容，还能分析通信模式，发现异常。
分析通信频率与数据量：对一个特定 API 接口进行多次调用，在 Wireshark 中统计其请求-响应的频率、数据包大小、响应时间。如果某个查询接口的响应数据包异常巨大，可能意味着存在数据泄露（如一次性返回了全部用户数据）。如果某个接口在未被操作的情况下频繁通信，可能意味着客户端存在异常轮询或后台任务泄露。
识别异常协议与端口：关注除了 80（HTTP）、443（HTTPS）、常见的数据库端口（如 3306, 5432）之外的通信。如果发现你的应用服务器向一个陌生的外部 IP 和端口发送数据，这可能是存在恶意代码或配置错误，导致数据外泄。
重建会话流：在 Wireshark 中，右键某个 TCP 或 HTTP 数据包，选择 “Follow -> TCP Stream” 或 “Follow -> HTTP Stream”。这可以将一次完整的会话（包括多次请求响应）重组在一起，以纯文本或十六进制形式展示。这对于分析一个复杂的多步骤业务逻辑（如登录后跳转再请求数据）的完整流量非常有帮助，你可以清晰地看到 Token 是如何传递和使用的。
5. 漏洞复现、报告与修复验证
发现漏洞只是第一步，如何清晰地向开发团队复现问题，并验证修复是否有效，是安全测试闭环的关键。
5.1 使用 Fiddler Session 文件进行精准复现
文字描述一百句，不如一个可重现的案例。Fiddler 的.saz文件是完美的复现工具。
保存问题场景：当你通过断点修改、重放等方式成功触发一个漏洞（例如，通过删除 Token 访问了管理员接口）后，在 Fiddler 的会话列表中选择从触发漏洞开始到收到异常响应为止的所有相关请求（通常包括一个前置的正常请求和被你修改后的漏洞请求）。右键选择 “Save -> Selected Sessions…”，保存为.saz文件。这个文件完整记录了请求和响应的所有原始数据，包括头、体、时间戳。
制作复现步骤：将.saz文件发给开发人员，并附上一个简短的步骤说明：
- 打开 Fiddler，导入此
.saz文件。 - 找到名为 “[#编号] 漏洞请求” 的会话（你可以在保存前重命名会话）。
- 点击 “Replay” 重新发出这个请求。
- 观察响应，应与文件中记录的漏洞响应一致（如返回了未授权的数据）。
这种方式避免了因环境差异、数据差异导致的“我这边没问题”的扯皮，让问题定位变得极其高效。
5.2 编写清晰的安全测试报告
一份好的报告能让修复工作快速启动。报告不应只是漏洞列表，而应包含风险上下文。
报告结构建议：
- 概述：简要说明测试范围、时间、使用的工具。
- 漏洞详情（每个漏洞单独一节）：
- 漏洞标题：简明扼要，如“用户个人资料接口存在未授权访问漏洞”。
- 风险等级：高、中、低（可根据 CVSS 标准粗略评估）。
- 受影响接口：完整的 URL 和方法。
- 漏洞描述：清晰说明漏洞是什么，例如“该接口在请求头中移除 Authorization 字段后，仍返回 200 状态码及用户敏感数据，未进行有效的身份验证。”
- 复现步骤：一步一步的操作指南，最好配上关键步骤的截图。附上
.saz文件或 Postman Collection 的链接。 - 请求/响应示例：粘贴触发漏洞的原始请求和响应数据（注意脱敏敏感信息）。
- 潜在影响：说明攻击者利用此漏洞可以做什么，如“导致所有用户的姓名、手机号、邮箱地址泄露。”
- 修复建议：给出具体的、可操作的修复方案，如“在后端该接口处理逻辑的最开始，增加有效的会话验证中间件，对于无效或缺失的 Token，统一返回 401 Unauthorized 状态码。”
- 附录：可以附上测试用的 Payload 列表、扫描的接口清单等。
5.3 修复后的回归测试策略
开发人员修复漏洞后，你的工作还没结束。必须进行回归测试，确保漏洞被真正修复，且没有引入新的问题。
正向测试：按照漏洞原本的复现步骤再操作一遍。例如，再次尝试用 Fiddler 删除 Token 访问那个接口，此时应该收到明确的401或403错误，而不是数据。使用 Postman 重新运行之前触发漏洞的恶意 Payload，应该得到预期的错误处理（如参数校验失败），而不是服务器错误或异常数据。
边界与副作用测试：修复一个漏洞时，可能会影响其他正常功能。例如，修复 IDOR 时，如果校验逻辑写错，可能导致合法用户也无法访问自己的数据。因此，需要用合法的、不同权限的测试账号，完整地走一遍相关的业务流，确保功能正常。
自动化脚本辅助：对于需要频繁回归测试的接口，可以将 Postman 的测试用例集合化、自动化。利用 Postman 的测试脚本（如pm.test）来断言响应状态码、响应体内容是否符合安全预期。然后通过 Collection Runner 或 Newman 定期自动执行，形成持续的安全回归测试能力。
安全测试是一个持续的过程，而不是一次性的任务。将 Fiddler、Postman、Wireshark 融入你的开发和安全流程，养成在功能开发完成后主动“攻击”一下自己接口的习惯，能极大地提升产品的安全水位。这套组合工具的学习曲线并不陡峭，但其在发现和预防真实安全风险方面的价值，远超投入。