Fiddler抓包改金额实战：支付接口信任边界与漏洞测试

简介针对需要掌握Fiddler抓包与请求篡改技术的测试人员、安全学习者和开发者这套教程与工具包提供了从环境配置到实战操作的完整参考。资源共52个文件大小10.62MB包含13个exe工具、12个dll依赖库、14个dat配置文件、4个wav演示音频、3个txt说明文档及若干图标脚本其中exe与dll负责工具运行txt与wav提供操作指引和演示。内容以视频文档工具三种形式组织覆盖夜神模拟器配置、Fiddler抓包设置、修改商品金额并提交支付的全流程并配有发货图片、文本说明和可执行教程方便对照练习。资源已有9963人学习下载适合希望快速上手抓包修改请求参数、理解HTTP/HTTPS流量篡改原理的入门与进阶用户。1. 抓包改金额测的是服务端信不信任前端在一次授权漏洞测试里我对着一个带支付流程的模拟商城调接口前端结算页把商品合计金额放在 POST 请求体里明码提交后端既不重新计价也不校验签名。用 Fiddler 挂上代理、开断点把 100 改成 0.01放行之后支付流程照常走完订单却按原始金额入账。fiddler抓包修改金额就是干这件事截住请求、篡改金额参数、观察服务端是否信任客户端传值。它验证的是支付链路里最基础的逻辑漏洞——金额是否在后端被固化、签名是否覆盖关键字段。这套技术适合接口测试工程师、做支付功能自查的开发以及刚接触 Web 安全测试的从业者前提只有一个目标是你自己搭的环境或拿到书面授权的测试系统。2. 改包前先看清三层校验哪个环节能改、哪个环节一改就死2.1 先分清前端计算、后端重算和签名校验改包能不能生效不取决于你手速多快而取决于金额在服务端被信任到哪一层。常见支付链路里存在三种校验强度我习惯把目标系统按这三类归档再决定怎么改。第一类是纯前端计算页面把所有商品单价和数量在浏览器里算出一个合计放进请求体提交后端拿到这个数值直接用于生成支付单。这种系统里改包几乎是必成的甚至不需要改请求前端 DevTools 改一下合计变量都能生效。第二类是后端重算前端虽然传了金额但后端收到请求后重新查库、重新累加以服务端计算结果为准。这种系统里你改包改了个寂寞请求里的金额被忽略支付单金额不变。第三类是签名校验前端把金额、订单号、时间戳一起扔进某个哈希算法生成 sign后端收到后先验签再处理。这种系统里只改金额不改 sign请求直接被拒绝。实际操作前我会先抓一单正常支付请求看请求体里除金额外有没有 sign、token、nonce 这类字段再翻一下前端打包后的 JS 确认签名逻辑在哪边算的。这个判断决定了后面所有操作策略三类系统的改包方案完全不同花十分钟做分类能省掉后面半小时的无效断点。校验类型改包结果后端表现漏洞判定纯前端计算金额可任意改按修改后的金额生成支付单高危后端重算金额修改无效按库内价格生成支付单无此漏洞签名校验直接返回验签失败拒绝创建支付单需继续测签名绕过2.2 为什么这个场景里我优先选 Fiddler抓包工具有不少常见的选择是 Burp Suite、Charles、Fiddler 三选一。针对“抓 HTTP 请求→改金额→验证支付逻辑”这个具体任务我一般建议直接用 Fiddler理由很实在。Fiddler 是 Windows 桌面程序装上就能当系统代理用不需要像 Burp 那样先配置上游代理和项目作用域学习成本最低它的断点功能是图形化的按一下 F11 就能拦下请求改完点放行即可适合第一次做改包的人很快跑通全流程。更关键的是 Fiddler 自带 FiddlerScript可以直接写一段规则让工具在请求经过代理时自动替换金额字段并高亮标记这就把“每次手动改”变成了“挂机自动改”做批量验证时效率高很多。Burp 的 Repeater 也能干同样的事手动重放甚至更顺手但要做自动化和条件替换得装 Turbo Intruder 这类扩展配置成本高。Charles 的断点改包体验尚可但脚本化能力弱遇到需要循环验证的场景就卡住了。我的习惯是临时验证一两次用 Fiddler 断点需要反复提交多组金额时用 FiddlerScript 自动替换。另外提醒一点不要用网上“汉化整合版”或“绿色版”这类便携包经常被塞了私货优先用官方安装包功能完全够用。2.3 HTTPS 流量解密不装证书只能看到 CONNECT现在的支付接口几乎全是 HTTPSFiddler 默认只能看到一条 CONNECT 隧道请求体完全不可见。要抓到明文内容必须让 Fiddler 作为中间人给客户端签发证书。做法是打开 Fiddler 后进入 Tools Options HTTPS勾选 Decrypt HTTPS traffic首次会弹出安装根证书的提示一路确认。这个根证书会装进 Windows 当前用户的受信任根证书颁发机构。如果是抓浏览器流量到这一步就够了。如果是抓手机 App 的流量需要把同一张证书导出成 .cer 文件发给手机安装安卓还要额外做一件事Android 7.0 及以上版本App 默认不信任用户安装的证书只信系统证书库所以证书装到“用户”分区往往无效。常见做法是用模拟器镜像把证书预置到系统证书目录或者用测试框架绕过证书校验。iOS 则在设置里安装描述文件后还要到“证书信任设置”里手动开启完全信任少这一步仍然解不开。这里有个很容易翻车的点证书没装好时Fiddler 里能看到一条条 CONNECT 请求但双击进去 Inspectors 面板是空白或者只有 TLS 握手失败信息。排查时先看根证书是否在受信任列表里再看目标地址是不是走了 443 端口。确认证书链路正常才进入下一步否则后面所有操作都是在盲改。3. 工具落地三件套HTTPS 证书、自动改包脚本和必调参数3.1 这类压缩包打开后通常装的是这三样名为“教程工具.rar”的压缩包解压后的结构虽然各家打包方式不同但常见组成无非三样一份图文教程文档、一个便携版 Fiddler 程序、以及一到两个辅助脚本。辅助脚本里出现频率最高的是证书安装说明和基于 Python 的请求重放脚本。我的建议是教程可以看便携版 Fiddler 慎用。便携版 Fiddler 的问题在于你无法确认发布者是否改动过程序的证书逻辑、代理端口或内置脚本而抓包工具本身就具备解密 HTTPS 的能力用不可信的来源等于把自己的流量明文交给未知方属于典型的信任风险。更稳的做法是从官方渠道装一个正版 Fiddler把压缩包里的证书脚本只用来看思路然后自己重新导出证书、自己写改包脚本。整套工具三件套——Fiddler 主程序、证书处理步骤、Python 验证脚本——每一样都自己掌控花不了多少时间但能避免很多后续的玄学问题。我习惯把这三样放在固定目录Fiddler 装系统盘证书导出文件放工作目录Python 脚本放同一个文件夹后续批量验证时直接定位不用每次重新找。目录整洁本身就能省掉改包一半的错乱问题。3.2 HTTPS 解密配置三个必调参数证书装上之后还有三个参数建议逐一确认很多改包失败其实不是改包操作的问题而是代理配置没有设对。第一端口必须固定且不冲突。Fiddler 默认监听 8888 端口但同事电脑上如果装了别的代理工具占用了这个端口Fiddler 会自动跳到随机端口而你的客户端若还指向 8888流量根本过不来。配置路径在 Tools Options Connections把 Fiddler listens on port 写死成 8888并勾选 Allow remote computers to connect这样手机和模拟器才能通过局域网 IP 访问代理。第二解密开关必须确认在勾选状态。有时候 Fiddler 更新或重装后默认不开启解密抓到的全是 CONNECT。第三关闭“连接重置”类干扰选项。部分版本默认会拦截服务端证书错误并直接断开连接测试环境里不少支付接口用的是自签名证书一抓就断。这时可以临时把 HTTPS 面板里的“Server certificate errors”相关选项放宽先保证看到明文再判定漏洞不要被证书错误本身打断了流程。设置完成后在浏览器里访问一次目标地址Filters 面板确认自己能抓到该域名的请求再做后续操作。代理链路都不通的话改包无从谈起。3.3 用 FiddlerScript 把“手动断点改包”变成“自动替换”手动断点适合验证单个请求但要测多个金额、多个订单手动点太慢而且每个请求都要重复同样的替换动作。我常用的做法是直接在 FiddlerScript 里写一段自动替换规则让工具碰到匹配的请求就自动改好金额并染色标记。static function OnBeforeRequest(oSession: Session) { // 只处理目标测试环境避免误伤其他流量 if (oSession.HostnameIs(demo.shop.test) oSession.PathAndQuery.StartsWith(/api/pay)) { var body oSession.GetRequestBody(); if (body.Contains(amount100)) { // 把金额参数从 100 替换成 0.01 body body.Replace(amount100, amount0.01); oSession.utilSetRequestBody(body); // 染色标记方便在会话列表里快速定位 oSession[ui-color] pink; } } }这段脚本挂在 FiddlerScript 的 OnBeforeRequest 钩子里作用是每个请求经过代理、在发送到服务端之前先检查目标主机名和路径是否匹配匹配则读取整个请求体若包含特定金额字符串就替换再把修改后的请求体写回去。逻辑不复杂但有两个参数需要特别注意。第一个是匹配条件里的 HostnameIs 和 PathAndQuery 前缀必须和你的测试环境完全一致否则要么漏改要么误伤其他系统的请求。第二个是 Replace 的源字符串必须精确对齐请求体里的实际报文。支付接口的请求体存在两种格式表单格式形如 amount100orderId123JSON 格式形如 {amount:100}两种格式的替换写法完全不同JSON 里直接 Replace 字符串容易误替换到别的同名字段我一般先打印一次原始 body 再写规则。脚本改完后在 Fiddler 命令行输入!之类的手动加载命令让脚本立即生效或者直接重开 Fiddler 加载规则。改完记得把 Replace 的值恢复并验证一次正常请求别把自动化规则留在代理里坑到后面的测试。4. 一次完整改包从定位金额字段到验证订单结果4.1 定位支付请求过滤器和命令行断点组合改包的第一步不是改而是找到那个该改的请求。页面上的支付按钮点下去往往连续触发多个请求有创建订单的、有计算价格的、有拉起收银台的如果一路 F12 手动断下去会拦截到一堆无关请求新手很容易在第三个请求上就懵了。我习惯分两步缩小范围。第一步用 Filters 只显示目标主机的内容在 Fiddler 右侧 Filters 面板勾选 Use FiltersHosts 区域设置成只显示指定域名这样会话列表里剩下的都是目标系统的流量。第二步在 Fiddler 左下角的命令行快查区域输入断点命令格式是bpu /api/pay这条命令的含义是只对 URL 路径里包含 /api/pay 的请求生效断点触发时 Fiddler 会在该请求发出前拦截。相比全局断点这种命令方式精准得多。输入命令后回到客户端页面重新点一次支付按钮此时 Fiddler 会话列表里目标请求会变成带断点图标的待处理状态双击打开该会话在 Inspectors 面板里就能看到完整的 Headers 和请求体。定位金额字段时优先找这几个关键词amount、price、totalAmount、payMoney、totalFee。看到字段后先别急着改把请求体整体截图或者复制出来尤其是要把字段名、数值格式、前后逗号引号关系看清楚。很多翻车是因为少看了一个引号导致替换后的报文直接变非法 JSON。4.2 实战修改金额正向篡改与负金额测试定位到请求并进入断点状态后操作流程是这样的在 Inspectors 面板下方的请求体区域直接修改 amount 字段的值改完后点击面板上方的“放行”按钮让修改后的请求继续发送到服务端随后观察响应内容和支付流程变化。第一次测试建议先做正向小额篡改也就是把金额从大改小。比如正常订单是 100 元改成 0.01 元看服务端是否照常创建支付单。这个测试能直接判定后端是否信任客户端传值。如果响应里带着支付单号、支付金额也是 0.01说明第一层校验无效。第二次测试做负金额或零金额把 amount 改成 -1 或 0观察后端是否存在数值范围校验。负金额场景里部分系统会出现订单金额为负、支付通道回调异常、订单状态错乱等连锁问题能挖的问题比小额篡改更严重。第三次做精度边界测试把单位搞混接口如果约定以“分”为单位就传 1即一分钱如果接口以“元”为单位就传超大值 999999999看后端有没有上限控制。测试类型修改示例观察点正向小额100 → 0.01支付单金额、回调金额负金额100 → -1订单状态、支付通道行为精度边界100 → 1 或超大值后端是否有范围校验每改一次我都要在响应面板里确认三组关键证据响应体里返回的订单金额是多少、支付回调里最终落库的实付金额是多少、以及订单状态是否发生了跳转。只有这三个位置的数据和修改值对应上才算确认漏洞存在否则只是请求改了但业务没生效。4.3 遇到签名校验三种绕过情况的判断标准很多支付接口不会让你改得这么顺利请求体里带着 sign、signature、token 字段金额一改签名校验立刻失败响应直接返回验签错误。遇到这种情况先别放弃签名校验有三种不同的强度逐一测过才知道有没有突破空间。第一种是签名只覆盖部分字段。有些后端偷懒签名算法只对订单号和时间戳计算没把金额纳入签名原文。这种系统里你改金额后保持 sign 不变直接放行后端验签通过漏洞成立这属于低水平实现但真实存在。第二种是签名在前端算出密钥和算法都打包在 JS 里。这种系统里虽然改了金额需要同步改 sign但只要你从 JS 里找到签名算法构造新 sign 也不难。测试做法把原始请求的金额和 sign 一起截获用页面里的加密函数算出一个新 sign替换后提交如果能通过说明服务端的验签只验证了“签名的确存在”却无法阻止客户端自己用真实密钥生成合法签名——密钥已经暴露给客户端本身就有问题。第三种是签名在后端生成前端完全拿不到密钥这种系统改包基本无效直接判定“防御有效”不必硬撞。区分这三种情况的方法很直接第一次只改金额不改 sign看响应第二次金额和 sign 一起改看响应第三次只改 sign 不改金额看响应是否仍提示验签错误。三次结果组合起来就能确定签名链路的设计缺陷在哪一层。这套组合测试比盲目尝试更高效也能在测试报告里写出更准确的结论。5. 改包避坑与排查五个常见翻车点的现象、原因和解决5.1 现象一会话列表里能看到请求但请求体全是乱码现象Fiddler 已经解开了 TLSInspectors 面板也能看到报文但 Body 区域显示一堆乱码改包无从下手。原因服务端对响应做了 Content-Encoding 压缩常见的是 gzip部分是 br。Fiddler 在 Inspectors 展示时会自动解压地址栏上方通常有蓝色的“Response is encoded”提示但如果你在 FiddlerScript 里用 GetResponseBody 取数据拿到的是压缩后的原始字节直接做 Replace 会把压缩流改坏。解决在脚本里先判断 Content-Encoding再解压后替换替换完重新设置 Content-Length。实操上如果只是手工改包优先在 Inspectors 面板里看清楚提示手动复制解压后的内容如果是脚本化需要额外写几行解压逻辑。这里有个提醒请求体是 JSON 的接口一般不会走 gzip遇到乱码大概率是响应侧的压缩别在请求体上白费功夫。5.2 现象二金额改成功了但后端一直返回签名错误现象请求体里的金额字段已经改完放行响应却返回“验签失败”或“参数不合法”反复确认过报文格式没问题。原因目标系统的签名计算覆盖了金额字段而且签名原文里的金额可能是被序列化过、参与排序的单纯改 JSON 里的 value签名原文却还引用着旧值。常见做法是普通请求用旧秘钥算新签名再替换重放时同步替换掉 sign。解决我在实际操作中的做法是先把请求体和签名原文都复制出来在 Python 脚本里复刻一遍签名流程截取时间戳、金额等字段按接口文档规定的顺序拼接算哈希然后替换新的 sign 字段。如果目标签名逻辑无法复刻那就说明这块硬校验暂时绕不过去果断记录下来转测其他接口。5.3 现象三改包后请求不但没生效整个页面还卡住了现象Fiddler 断点拦截了请求改完金额后点击放行但客户端页面一直转圈请求既没有在服务端产生日志也没有正常返回。原因断点状态下Fiddler 等待的是你手动放行但很多人放行时只点了“继续”下一次断点没有真正完成本次请求。另一个常见原因是请求体长度字段没同步改了 Body 之后Content-Length 还是旧值服务端等不到完整请求体直接把连接挂起或回复 400。解决改完 Body 必须同步检查 Headers 里的 Content-Length。Fiddler 的 utilSetRequestBody 会自动更新长度但如果你是在 Inspector 面板手工改的需要确认是否重新计算。另外确认 Fiddler 底部状态栏显示的是“Break on Request is enabled”避免里外断点叠加。5.4 现象四改包成功服务端也返回了成功但订单金额没变现象金额确实改了服务端响应里也显示支付成功但去订单详情页看实际支付金额还是原价。原因这是最容易误判的一种情况。支付环节有两条链路一条是“下单”时锁定价格另一条是“支付”时确认金额。很多系统在下单接口就把金额写死进订单表支付接口收到的金额只用于签名校验和通道传输最终入账金额以下单链路为准。也就是说你改的支付请求金额对订单不产生影响不等于漏洞不存在而是说明改动的地方不对。解决把测试重点转移到创建订单的接口上对下单请求里的金额参数重复同样的改包流程。如果下单接口也做了价格校验再测购物车结算接口的金额字段。常见做法是把整条链路的请求全部抓下来逐个观察金额参数从哪个环节开始被服务端固化。改完在订单详情页进行一次回读确认最终落库数据来源这个证据比接口响应更有说服力。5.5 现象五自动化脚本循环重放时请求顺序和老崩现象写好的 Python 脚本循环发多个改包请求但服务端收到的顺序和脚本里发送的顺序不一致甚至有的请求直接被拒日志显示终端 IP 被临时封禁。原因排查下来通常是两个原因。第一是测试环境有频率限制和风控短时间高频请求被反爬或者风控模块识别第二是 Fiddler 断点状态没清理干净脚本发出的请求也被代理截获卡在代理里等待人工放行请求堆积后表现出的现象就是顺序错乱。解决跑脚本前先清掉 Fiddler 的断点命令命令行输入bps取消之前设置的断点规则再确认脚本并发数。我在批量验证时一般把并发控制在 2~3每条请求之间加 50 到 200 毫秒延时用超时重试机制处理临时失败避免打崩测试环境后数据变得不可信。6. 把单个改包变成批量验证一段自动化脚本与使用边界单次改包验证的结论说服力有限尤其是需要对比多组金额、观察不同金额下的响应差异时手动改一次就要点好几下效率太低。我会在跑通单次流程后把验证逻辑写成一段 Python 脚本指定测试目标、金额列表和断言条件循环提交请求最后汇总结果。下面这段是我常用的最小脚本骨架。import requests import time # 目标地址仅限授权测试环境 url https://demo.shop.test/api/pay headers { Content-Type: application/json, User-Agent: Mozilla/5.0, Cookie: sessiontest_session_001 # 先通过 Fiddler 抓包拿到有效会话 } amounts [0.01, 0, -1, 999999999] for amount in amounts: payload { orderId: TEST_ORDER_2024001, amount: amount, sign: computed_by_js_logic # 若有签名先复刻签名逻辑再填值 } try: r requests.post(url, jsonpayload, headersheaders, timeout10) result r.json() # 检查响应中的订单金额与提交金额是否一致 if result.get(orderAmount) amount: print(f[{amount}] 服务端接受修改后的金额漏洞疑似存在) else: print(f[{amount}] 服务端未接受修改返回金额: {result.get(orderAmount)}) except requests.exceptions.Timeout: print(f[{amount}] 请求超时可能是风控或连接问题) time.sleep(0.2) # 控制请求间隔避免触发测试环境限流脚本逻辑很简单遍历一组测试金额每次构造一个新的支付请求提交到目标接口然后用响应里的订单金额字段判断服务端是否信任客户端传值。这里的 headers 和 payload 都要先通过 Fiddler 抓包获得真实格式不能凭空猜。三个参数按需调整amounts 列表根据测试计划增删、sleep 间隔控制请求频率、断言字段 response 里的字段名要对上接口实际的返回结构。这段脚本帮我在一次接口测试里快速筛出问题——有回读响应里金额和提交一致的情况说明支付金额完全由前端决定。但后来一次测试里忘了先清断点脚本发出的请求全被 Fiddler 拦下堆积测试环境被压了几个小时教训是自动化和代理状态必须分开管理。现在我的习惯是固定用一套专用的代理配置和端口跑自动化脚本跑完立刻恢复现场保证每个测试环境的流量干净可控。顺便把使用边界说清楚这类验证脚本只适合在授权测试靶标、本地搭的模拟商城、回环测试环境里跑不要拿它去试探任何真实生产支付链路。改包验证的本质是证明“某个接口是否信任客户端传参”帮助开发团队把支付逻辑漏洞在发布前修掉。希望帮到你。本文还有配套的精品资源点击获取