简介面向需要掌握Fiddler抓包与支付金额修改原理的测试工程师、安全学习者和技术爱好者这份资源提供了一整套从环境准备到实操演练的教程与工具适合作为Web安全、接口测试方向的入门参考资料。压缩包共52个文件大小10.62MB采用rar格式打包其中dat数据文件用于保存抓包记录exe可执行程序与dll依赖库构成工具主体配以wav操作演示、txt配置说明以及config、js、png等辅助文件整体覆盖视频、文档与工具三类内容。目前已有9963人学习下载。教程特别包含夜神模拟器配置、Fiddler2文本设置和发货图片样例可引导读者完成模拟器环境搭建、HTTPS抓包配置、购物商品金额拦截与修改的全流程操作并掌握常见问题的排查思路可辅助理解支付流程中的安全校验机制适合希望快速入门抓包改包实验的初中级用户。1. 偶然翻到一份fiddler抓包改金额的资源先别急着开抓先掂量掂量它能干哪些正事看到“修改金额”四个字很多人第一反应是黑产套路。但有过授权测试经验的开发者都明白这是接口参数篡改验证的经典场景——在测试环境里改掉订单金额、看后端有没有二次校验比任何扫描器都直观。这份资源我拆过一遍标题里“fiddier”其实是fiddler的笔误内容倒挺完整从基础抓包到HTTPS解密再到断点改包和配套工具路径是齐全的。适合刚入行想搞懂接口安全的测试工程师也适合前端开发者想看看自己发的请求到底长什么样。说白了它教的不是“怎么薅羊毛”而是“怎么验证后端参数是否可信”——这个能力放到哪家公司都实用。2. fiddler抓包环境搭建解密HTTPS是第一步证书装不对全盘翻车2.1 为什么抓包要用fiddler中间人代理模型和选型理由fiddler能在众多抓包工具里活到今天核心原因是它把自己伪装成一个本地代理服务器。所有HTTP/HTTPS流量从应用程序发出后先经过fiddler再由它转发给真正的服务器响应也是一样先回fiddler再回客户端。这个“截胡”模型叫中间人代理MITM抓包、断点、篡改数据全靠它。选型方面对比过Charles和Wireshark的人会明显感觉到差异。Wireshark走网卡层抓包看的是原始数据帧解密HTTPS需要手动导入私钥操作成本高Charles在Mac生态里确实顺手但跨平台场景和脚本扩展不如fiddler。fiddler的FiddlerScript基于JavaScript改请求和响应可以直接写逻辑不用每次都手工点界面。对于“修改金额”这种需要重复操作的任务脚本化几乎是刚需。不过要提醒一点fiddler默认只监听本机回环地址的流量也就是说电脑上安装好fiddler它会自动修改系统代理浏览器和桌面应用的HTTP请求都能被捕获。但手机上的App流量不会自动走fiddler需要手动把手机WiFi代理指向电脑IP和端口8888这个后面单独说。2.2 证书安装与解密开关配置每个开关的作用和参数含义HTTPS流量默认是加密的fiddler必须安装自己的根证书然后被客户端信任才能执行中间人解密。安装路径是Tools - Options - HTTPS界面里有几个关键开关我把它们的功能和适用场景整理成了表格开关项推荐状态作用Capture HTTPS CONNECTs勾选拦截HTTPS的CONNECT隧道请求必须勾否则HTTPS解密无从谈起Decrypt HTTPS traffic勾选对HTTPS流量解密点击后会弹出证书安装询问框Ignore server certificate errors勾选忽略服务器证书错误很多内网自签证书环境需要开这个Trust root certificate勾选把fiddler根证书安装到系统受信任的根证书存储区勾选Decrypt HTTPS traffic后fiddler会提示安装根证书。Windows上直接点“Yes”即可信任区域要选“受信任的根证书颁发机构”不要选错到“个人”或“中间证书颁发机构”否则浏览器会持续报证书错误。安装完成后最好重启一次浏览器让新证书生效。验证证书是否装好的常见做法是打开任意一个HTTPS网站看fiddler的Session列表里响应列是否显示“HTTPS”而不是“Tunnel to”。如果还是看到Tunnel to说明CONNECT请求被拦截了但没有解密。此时用下面这个PowerShell命令可以快速检查代理端口是否正常监听# 检查fiddler默认代理端口8888是否处于监听状态 netstat -ano | findstr 8888 # 检查fiddler根证书是否已进入受信任区 Get-ChildItem Cert:\CurrentUser\Root | Where-Object { $_.Issuer -like *Fiddler* }逻辑说明第一条命令用来确认fiddler的代理端口真的在监听很多改包失败都是因为端口被占用或者fiddler服务没起来第二条命令在Windows证书存储里搜索包含“Fiddler”字样的根证书能直接判断证书是否安装成功。参数说明如果netstat输出为空优先检查Tools - Options - Connections里的Listen on port是不是被改掉了默认是8888如果证书查询结果为空需要回到HTTPS选项卡重新执行一次“Trust root certificate”。2.3 手机抓包场景的额外配置全局代理和证书信任缺一不可手机App抓包比PC要复杂一截因为涉及代理配置和证书信任两个层面。首先把手机和电脑接到同一个WiFi下然后打开手机WiFi的高级设置设置代理为“手动”主机名填电脑的局域网IP端口填8888。电脑的局域网IP可以在命令行用ipconfig查询千万别填成127.0.0.1那是手机自己。代理配置完成后手机浏览器访问http://ip:8888会看到一个fiddler证书下载页面下载并安装证书。但这里有个容易栽的坑Android 7.0及以上版本默认情况下App只信任系统级证书不信任用户安装的证书。也就是说浏览器能正常解密HTTPS了App的流量照样抓不到。常见做法是两种第一种把fiddler导出的证书做成系统证书需要root权限过程繁琐第二种用破解过证书校验的测试机或者把App的network_security_config配置成信任用户证书这适合有源码的测试环境。iOS那边相对简单安装描述文件后在“设置 通用 关于本机 证书信任设置”里打开完全信任开关就行。3. 断点改包修改金额从定位请求到篡改请求体与响应体的完整链路3.1 先用Filters把无关流量过滤掉目标越聚焦越不容易改错包很多新手一上来就开抓Session面板几百条请求瞬间迷失。真实抓包的第一步一定是过滤。fiddler右侧的Filters页签就是干这个的勾选“Use Filters”在Hosts区域选择“Show only the following Hosts”然后输入目标测试环境的域名比如mockmall.local。这样fiddler只会显示该域名的请求其余流量全部隐藏。过滤规则里还有几个高频选项值得说明。“Request Headers”区域可以按Header字段过滤比如只显示包含Authorization: Bearer的请求用于定位登录态请求“Breakpoint on”区域可以针对特定URL或资源类型打断点比如只对/api/order路径打断点而不是所有请求都中断这在后面改包时会大幅度降低干扰。我一般还会配合使用会话分组功能在Session面板中按Ctrl Shift G对选中会话分组按请求域名、请求方法或响应码归类。改包前先花两分钟做这一步后面定位金额字段会快很多不用在一堆资源文件里翻眼睛。3.2 请求前断点 vs 响应前断点改请求体还是改响应体fiddler的断点有两种触发位置Before Requests请求发出前和After Responses响应返回前。“修改金额”这个场景下两种断点各有对应目的。如果目的是验证后端是否信任接口传入的金额值就断在Before Requests截获请求后把请求体里的amount字段从500改成1然后放行观察服务器是否接受。如果目的是验证前端展示容错能力比如改响应里的价格让页面显示0.01元就断在After Responses在响应返回到App前篡改JSON。两者的核心区别在于改请求体验证的是后端校验逻辑改响应体验证的是客户端渲染逻辑。面试里被问“你对参数篡改怎么理解”能说出这两者的区别比背一堆漏洞分类有意义得多。实际操作中断点开关在菜单Rules - Automatic Breakpoints里。选择“Before Requests”后fiddler会在每个匹配的请求前停下inspector面板会进入可编辑状态。这里要小心如果没有配置Filter所有请求都会被断住体验极差。正确做法是配合3.1节里的Filters或者用快捷键Shift F11开请求前断点、Alt F11开响应前断点避免全量断点。3.3 一次完整的“改金额放行”操作与FiddlerScript批量改包在测试环境“模拟项目X”里最常见的验证场景是这样的下单接口POST /api/order/create请求体是一个JSON里面有amount: 500目标是验证后端是否直接用这个值做结算。打开断点后在Inspectors面板找到JSON Body区域把500改成1然后点击“Run to Completion”放行观察返回。如果服务器接受了下单金额1元说明后端没有用商品表里的价格做校验存在参数信任风险如果服务器返回价格校验失败说明后端有二次查询这个改包操作本身证明了接口是安全的。这个过程在重复测试时效率太低每次都要手工改。这时候FiddlerScript就派上用场了。在FiddlerScript编辑器里写一段OnBeforeRequest逻辑针对指定测试域名替换金额字段// 只在模拟测试环境下生效域名务必替换成自己的授权测试环境 if (oSession.HostnameIs(mockmall.local)) { // 只处理订单创建接口 if (oSession.PathAndQuery.Contains(/api/order/create)) { var body oSession.GetRequestBodyAsString(); // 将JSON中的amount字段从任何数值替换为1 var newBody body.replace(/amount\s*:\s*\d/, \amount\: 1); if (newBody ! body) { oSession.utilSetRequestBody(newBody); // 修改请求体后必须同步更新Content-Length否则服务端读到的body会错位 oSession[Content-Length] newBody.length.toString(); } } }逻辑说明脚本先判断当前请求是否来自测试域名mockmall.local再判断路径是否包含订单创建接口路径两个条件都满足才做替换。GetRequestBodyAsString()把请求体读成字符串正则/amount\s*:\s*\d/匹配金额字段不管原始值是500还是0.01都能被找到并替换成1。utilSetRequestBody()写回请求体最后那两行重新计算Content-Length这是很多老手都会漏掉的关键点——请求体长度变了但请求头里的长度没更新服务端按旧长度读取body轻则解析失败重则直接把请求当作数据错位处理。OnBeforeResponse脚本的写法类似区别是把GetResponseBodyAsString()和utilSetResponseBody()换成对应的响应体操作。注意一点线上生产环境千万别开这个脚本后果用脚趾头想都知道。我一般只把它放在专用的测试fiddler配置里和日常抓包配置分开保存。4. fiddler抓包改包常见问题排查证书、Content-Length与字段校验三处玄学4.1 现象手机按步骤装了证书、配了代理App的HTTPS请求还是看不见内容Session列表里能看到CONNECT开头的隧道请求但双击进去看不到Request和Response的明文全是“HTTPS”字样。原因基本锁定在Android系统版本上。Android 7.0以后App默认只信任系统证书用户手动安装的证书被静默忽略fiddler的中间人解密在App层面根本不受信任。解决路径也清晰如果你手头测试的是自家App且有源码在res/xml/下新建network_security_config.xml加入trust-anchors信任用户证书然后在AndroidManifest的application标签里引用这个配置。没有源码的外包App就得换支持证书信任的测试机或者用模拟器配合解决这部分就属于各家环境差异了。4.2 现象用脚本改了请求体里的金额后端直接返回400或500错误码这个坑我踩过一次血泪经验。请求头里的Content-Length是HTTP协议用来声明body长度的字段你改了请求体却忘记同步它服务器按旧长度去读body读出来的字节流是乱的解析JSON必定失败于是报400或500。解决方式很简单每次修改请求体后强制重算Content-Length手动在脚本里加一行即可// 统一在修改请求体后调用避免Content-Length过期 oSession[Content-Length] oSession.GetRequestBodyAsString().length.toString();逻辑说明GetRequestBodyAsString()取得当前body完整字符串.length取字符数再转成字符串写回请求头。注意这里要求body是单字节编码场景JSON通常没问题如果是multipart上传的大body建议用oSession.utilSetRequestBody()后让fiddler自行处理头部或者直接把整个Session标记为utilPrevent608。参数说明getRequestBodyAsString()有两个重载版本第二个参数接受Encoding类型默认UTF-8在中文内容场景下务必确认编码一致否则length算出来也会有偏差。4.3 现象改完响应里的金额前端页面上确实变成了1元但服务端不认账这不是fiddler的问题是后端压根就没把响应体当结算依据。真实链路里接口接收请求后会用商品ID重新查一次表把数据库的真实价格作为结算金额前端展示的金额只是渲染层数据。所以“改响应体让页面显示1元”属于客户端展示验证对最终订单金额没有影响。要判断后端是否存在金额篡改风险断点应该打在请求发出前修改请求体里的金额字段观察响应里有没有价格校验异常。如果后端返回的订单总价仍然是500而不是1说明服务端做了二次校验这个接口是稳固的如果后端傻乎乎地按1元创建了订单那才是真正需要报告给开发同事的漏洞。4.4 现象断点开着但一分钟能断几十次改包改到怀疑人生过滤器没生效或者断点模式设置成了“全部请求”。去Filters页签确认“Use Filters”是勾选状态Hosts里是正确的目标域名然后在断点设置里把Breakpoint on右侧的URI contains填成精确路径比如api/order/create就能把断点范围收缩到只匹配目标接口。还有一个细节fiddler里同一时间只能有两种断点模式生效同时开着“请求前”和“响应前”会互相覆盖工具栏下方会出现断点状态提示看到就顺手点掉不需要的那侧。5. 进阶技巧用AutoResponder和FiddlerScript把改包操作变成固定流程5.1 AutoResponder把“改金额”变成一条固定替换规则如果不想每次打开fiddler都去断点里点来点去AutoResponder就是后悔药。它能把“拦截指定请求并替换响应”做成持久化规则下次启动fiddler直接生效。在AutoResponder页签勾选“Enable rules”勾选“Unmatched requests passthrough”然后Add Rule。匹配规则支持正则和通配符响应来源可以选择本地文件、其他URL或者直接用fiddler里已有的Session内容。接口测试场景里我经常把目标接口的完整JSON响应保存成文件修改其中的金额字段后作为固定响应源。这样App每次请求这个接口fiddler直接返回改好的响应连断点都不用点。勾选“Use latency”还能模拟网络延迟顺手把弱网场景一起测了。5.2 FiddlerScript做会话着色和自动标记一次性看清哪些请求被改过改包最怕改着改着忘了哪条被动过手脚。我在FiddlerScript的OnBeforeRequest里额外加一段着色逻辑凡是命中替换规则的请求Session在列表中直接标成红色。这样一来哪些请求被自动改过、改了哪条打开fiddler一眼就能看清不用再一条条展开比对。从那以后我每次做接口测试都强制自己走一遍这个流程先配好Filters和AutoResponder再开FiddlerScript做自动标记最后才动手改包。工具是死的流程是活的把流程固化成脚本才不容易在自己都忘了改过什么的时候翻车。希望这份关于fiddler抓包改包的经验能帮你少走两趟弯路。本文还有配套的精品资源点击获取