Fiddler抓包改包实战：HTTP请求金额篡改原理与测试用例沉淀

简介这份资源面向对HTTP协议与抓包技术感兴趣的开发者、测试人员及安全初学者围绕Fiddler这一经典抓包工具展开重点演示如何通过抓包与请求篡改实现购物商品价格的修改与支付流程验证属于偏实战的技能进阶型资料。压缩包共收录52个文件整体约10.62MB其中exe与dll构成工具运行主体dat、config、txt承载配置与说明wav、png、ico等为辅助素材js脚本用于扩展逻辑结构紧凑、开箱即用。资源包含视频讲解、文档说明与配套工具三部分读者可借助录屏直观理解抓包、断点、请求改写等关键环节再结合文档梳理操作思路与常见问题排查方法从而独立完成从抓包到改价支付的完整链路演练。目前已有9963人学习下载适合希望快速上手Fiddler抓包实战、理解请求篡改原理的读者参考。1. 抓包改包这件事从一份被反复转手的工具包说起电商促销季刚过后台对账时发现几笔订单的实付金额和商品原价对不上运营第一反应是系统出了 bug开发排查半天却指向同一个结论请求在到达服务端之前被人动过手脚。这类场景在测试圈里不算新鲜一份名为「完整版 fiddler抓包修改金额教程工具.rar」的资源包最近又被频繁翻出来里面装着 Fiddler 的安装程序、一组预设规则脚本以及一份把「拦截请求—定位金额字段—改值—放行」串起来的操作说明。它解决的不是什么高深算法问题而是让一个没接触过代理抓包的人能在半小时内看懂 HTTP 请求里哪些参数决定了最终付款数字。适合谁做接口测试的、搞安全自查的、以及想弄明白自己写的下单逻辑到底暴露了多少可篡改字段的后端开发。需要先摆明立场这套东西只该出现在你自己拥有或获得书面授权的测试环境里拿它去碰真实交易系统性质就变了。2. Fiddler 的代理机制与改包原理为什么金额字段能被截下来2.1 中间人代理到底站在哪个位置Fiddler 的本质是一个本地 HTTP/HTTPS 代理服务器默认监听 127.0.0.1:8888。浏览器或移动端把流量指向它之后所有请求先到 Fiddler再由它转发给目标服务器响应也沿原路返回。这个「绕一道」的结构就是它能读能改的根基——请求和响应在它手里都是明文对象改完再放行服务端收到的就已经是你动过手脚的版本。HTTPS 场景下多一层证书信任。Fiddler 会动态签发证书客户端必须信任它的根证书否则握手直接失败。很多人第一次配手机抓包卡在这一步现象是浏览器提示证书无效或 App 直接断网原因就是根证书没装进系统信任区或者 Android 7.0 以上把用户证书排除在应用信任范围之外。常见做法是PC 端在 Tools Options HTTPS 里勾选 Decrypt HTTPS traffic 并导出根证书移动端装完后还要在「信任的凭据」里确认一遍。理解了这个位置就能明白为什么改金额可行下单请求里的价格、数量、优惠券抵扣这些字段如果服务端没有做二次校验客户端传什么它就信什么。Fiddler 只是把「客户端传什么」这个环节变得可见可改。2.2 断点拦截的两种触发方式Fiddler 提供两种断点Before Requests请求发出前和 After Responses响应返回后。改金额通常用前者因为要在请求到达服务端之前把值换掉。触发方式有两种。一是全局断点菜单 Rules Automatic Breakpoints Before Requests所有请求都会被拦。二是命令断点在底部黑色输入框敲bpu 目标URL关键字只拦匹配的请求。后者更实用不然满屏请求挨个放行能把人逼疯。# 在 Fiddler 命令行输入框执行只拦截包含 order/create 的请求 bpu /api/order/create # 取消断点 bpubpu后面跟的字符串会做包含匹配URL 里带这个片段才会被拦。取消时直接敲bpu不带参数。这个命令的好处是精准坏处是关键字写太短会误伤比如只写/api可能把登录、查询全拦下来。2.3 定位金额字段的实操路径拦截生效后请求会停在 Fiddler 里左侧会话列表出现红色箭头图标。点开 Inspectors WebForms 或 TextView能看到请求体的原始内容。JSON 体里找amount、price、totalFee、payAmount这类键名表单体里找同名参数。{ skuId: 10086, quantity: 1, unitPrice: 29900, payAmount: 29900, couponId: }上面这段里payAmount就是最终付款金额单位通常是分。把它改成1放行如果服务端没校验订单就会以 0.01 元生成。改完点 Run to Completion 放行或者按 ShiftF5 跳过剩余断点。参数说明unitPrice是单价quantity是数量payAmount一般等于单价乘数量减优惠。有些系统只校验unitPrice和quantity的乘积忽略payAmount那就得改前两个有些反过来只认payAmount。判断方法是逐个改、逐个放行、看服务端返回的订单金额以哪个为准。这一步没有捷径就是试。提示改之前先把原始请求体复制到记事本留底改错了能对照恢复不然拦下来一堆请求分不清哪个是哪个。3. 从安装到改包跑通一份可复现的操作链路3.1 环境准备与证书配置资源包里的 Fiddler 安装程序直接双击下一步即可装完首次启动会提示配置一路默认。关键是 HTTPS 解密和证书信任。PC 端配置Tools Options HTTPS勾选 Capture HTTPS CONNECTs 和 Decrypt HTTPS traffic弹窗选 Yes 生成根证书。然后 Actions Export Root Certificate to Desktop得到 FiddlerRoot.cer。移动端配置分两步。第一步手机 Wi-Fi 代理设为 PC 的局域网 IP端口 8888PC 防火墙放行 Fiddler。第二步手机浏览器访问http://PC的IP:8888点页面里的 FiddlerRoot certificate 下载安装。Android 装完要去「设置 安全 加密与凭据 信任的凭据 用户」确认存在iOS 装完要去「设置 通用 关于本机 证书信任设置」手动打开开关这一步漏了就是白装。# 查看本机局域网 IPWindows 用 ipconfigmacOS/Linux 用 ifconfig ipconfig | findstr IPv4拿到 IP 后填进手机代理设置。如果手机连不上先确认 PC 和手机在同一网段再确认防火墙没拦 8888 端口。3.2 拦截、修改、放行的完整动作环境通了之后按下面的顺序走一遍。第一步开启断点。命令行敲bpu /api/order/create或者菜单开全局断点。第二步在手机或浏览器触发下单操作。请求会被拦下Fiddler 左侧列表出现带红色箭头图标的会话。第三步点开该会话切到 Inspectors TextView找到请求体里的金额字段。第四步直接双击修改数值比如把29900改成1。第五步点工具栏的 Run to Completion 放行。服务端返回的响应会在同一会话的 Response 区显示看返回的订单金额是否跟着变了。// 如果资源包里带了 FiddlerScript 规则可以在 Rules Customize Rules 里加自动替换 // 下面这段把请求体中 payAmount 的值统一改成 1 if (oSession.uriContains(/api/order/create)) { oSession.utilDecodeRequest(); oSession.utilReplaceInRequest(payAmount\:29900, payAmount\:1); }这段脚本的作用是在请求发出前自动做字符串替换省去手动改的步骤。uriContains限定只对下单接口生效utilReplaceInRequest做原文替换。注意替换字符串要跟实际请求体格式完全一致多一个空格少一个引号都匹配不上。参数写死成29900只适合固定测试数据真实场景里金额是变的得用正则或者先解析 JSON 再改。3.3 验证改包是否生效的三个观察点改完不是看 Fiddler 里数字变了就算成功要以服务端返回为准。三个观察点一是响应体里的订单金额字段二是跳转后的支付页面显示金额三是后台订单列表里的实付金额。三个地方都跟着变说明服务端确实没做校验只有 Fiddler 里变了、服务端返回原价说明校验生效改包失败。这一步的意义在于区分「客户端展示层被改」和「服务端数据层被改」。很多新手看到 Fiddler 里数字变了就以为成功了其实服务端压根没理这个字段白忙一场。4. 改包测试里最容易翻车的几个地方4.1 现象请求拦下来了但改完放行服务端返回原价原因服务端对金额做了二次计算或签名校验。常见做法是客户端传 skuId 和 quantity服务端自己查价格算总价客户端传的 payAmount 只作展示用根本不参与计算。或者请求体带了 sign 签名字段改任何参数都会导致签名不匹配被拒。解决先看请求体里有没有 sign、token、timestamp 这类字段。有签名的话改完金额必须同步重算签名而签名算法在客户端代码里得反编译才能拿到。没有签名就确认服务端是否以自身计算为准如果是改客户端参数这条路走不通得换测试思路。4.2 现象HTTPS 请求全是 CONNECT 隧道看不到明文原因Decrypt HTTPS traffic 没勾选或者根证书没被信任。Android 7.0 以上默认不信任用户安装的证书App 如果没配置 networkSecurityConfig 允许用户证书抓包就是一片 CONNECT。解决PC 端确认 HTTPS 解密已开。Android 端如果是自己开发的 App在 manifest 里配android:networkSecurityConfig允许用户证书如果是第三方 App用户证书这条路基本堵死常见做法是用一台 Android 7.0 以下的测试机或者把证书装到系统分区需要 root。iOS 端确认「证书信任设置」开关已打开。4.3 现象手机连上代理后完全没网原因PC 防火墙拦了 8888 端口或者手机和 PC 不在同一网段或者 Fiddler 没开启远程连接。解决Fiddler 里 Tools Options Connections勾选 Allow remote computers to connect端口保持 8888。Windows 防火墙新建入站规则放行 8888。手机浏览器访问http://PC的IP:8888测试能否打开 Fiddler 页面打不开就是网络或防火墙问题。4.4 现象改完金额下单成功但订单状态异常或直接风控拦截原因金额改动幅度过大触发风控规则比如 299 元改成 0.01 元风控系统直接判定异常交易。或者订单创建成功但支付环节校验失败因为支付网关会拿订单号回查真实金额。解决测试时改动幅度别太夸张改成原价的一半或减个零头先确认改包链路通不通再逐步试探校验边界。风控拦截是预期行为说明防护生效记录下触发阈值本身就是测试产出。4.5 现象FiddlerScript 规则不生效原因脚本语法错误、匹配字符串跟实际请求体不一致、或者规则加在了错误的函数里。解决Rules Customize Rules 打开脚本编辑器确认代码加在OnBeforeRequest函数内。用 CtrlF 搜请求体里的实际字符串复制粘贴到脚本里别手敲。改完保存Fiddler 会自动重载。如果还不生效在脚本里加FiddlerObject.log(命中规则)看日志有没有输出。5. 把改包能力沉淀成可复用的测试用例跑通一次改金额不算本事能把它变成每次发版都能跑一遍的回归用例才有价值。我一般会做三件事。第一件把 FiddlerScript 里的替换规则参数化。别写死金额改成从外部文件读测试数据。// 从本地 JSON 文件读测试用例按顺序替换 var testCases []; var file C:\\test\\amount_cases.json; if (System.IO.File.Exists(file)) { testCases Fiddler.WebFormats.JSON.JsonDecode(System.IO.File.ReadAllText(file)).JSONObject; } if (oSession.uriContains(/api/order/create)) { oSession.utilDecodeRequest(); var body oSession.GetRequestBodyAsString(); // 遍历用例命中则替换 for (var i 0; i testCases.cases.length; i) { var c testCases.cases[i]; if (body.indexOf(c.original) -1) { body body.replace(c.original, c.replaced); FiddlerObject.log(应用用例: c.name); } } oSession.utilSetRequestBody(body); }这段脚本从amount_cases.json读一组「原值→替换值」的映射遍历匹配后替换。utilSetRequestBody把改完的请求体写回去。参数文件里可以放多组边界值改成 0、改成负数、改成超大数、改成小数每次发版跑一轮看哪些被服务端拦、哪些漏过去。第二件把观察点固化成检查清单。每次改包测试完对照三个观察点逐项确认别凭印象。响应金额、支付页金额、后台订单金额三个都一致才算服务端真被改了。第三件记录每次的拦截结果形成基线。哪些字段改了会被拒、哪些能过、风控在什么阈值触发这些数据积累下来就是服务端校验强度的画像。下次发版如果原本能过的字段突然被拒了说明加了校验是好事原本被拒的突然能过了说明校验被绕过了得赶紧报。注意这套流程只在授权测试环境里跑。真实交易系统上做这些操作不管金额多小性质都不是测试。从那以后我每次配完抓包环境都强制先拿一个无关紧要的查询接口跑一遍拦截放行确认证书、断点、放行三个环节都正常再去碰下单接口。这个习惯帮我省过好几次「以为是校验生效、其实是证书没配对」的误判。希望帮到你。本文还有配套的精品资源点击获取