1. 项目概述为什么需要“双剑合璧”在移动应用安全测试的日常里我经常遇到一个尴尬的局面Burp Suite作为Web安全测试的“瑞士军刀”对HTTP/HTTPS流量的拦截、重放、扫描功能强大到没朋友但它在处理移动端App特别是那些不走系统代理、使用证书绑定或自定义网络库的应用时常常显得力不从心。而Fiddler这个老牌的HTTP调试代理在移动端的流量捕获和协议降级上却有着得天独厚的优势操作直观对新手友好。于是一个自然而然的想法就诞生了能不能让Fiddler在前面“冲锋陷阵”负责搞定移动端复杂的流量捕获和初步处理然后把“净化”后的流量稳定地“喂”给后方的Burp Suite进行深度安全审计这就是“FiddlerBurp Suite双剑合璧”自动化流量中转站的核心思路。这个方案解决的绝不仅仅是“抓不到包”的问题。它本质上构建了一个分层的、可定制的移动端安全测试管道。Fiddler充当了“前线适配器”和“流量预处理中心”负责处理证书安装、HTTPS解密、协议转换比如强制HTTP/1.1、过滤无关流量等脏活累活。Burp Suite则作为“后端分析引擎”专注于漏洞扫描、主动测试、会话管理和复杂的攻击Payload构造。两者通过一个简单的代理转发规则连接起来实现了112的效果。无论是Android还是iOS无论是原生App、混合应用还是小程序内核这套组合拳都能为你打开一扇清晰的流量观察窗。对于安全测试工程师、渗透测试人员和应用开发人员来说掌握这套工作流意味着测试效率的质变。你不再需要反复折腾Burp的CA证书在移动设备上的信任问题也不用担心某些App的独特网络行为导致Burp“失明”。你可以更专注于业务逻辑漏洞、API接口安全隐患和数据传输风险这些核心安全问题。接下来我将从环境搭建、核心配置、自动化脚本编写到实战排错完整拆解这套工作流的每一个环节。2. 核心工具链搭建与环境配置2.1 Fiddler Classic你的前线流量枢纽首先我们得把Fiddler Classic这个前线枢纽搭建稳固。我强烈建议使用Fiddler Classic而非Fiddler Everywhere因为Classic版本在自定义脚本、扩展性和作为二级代理的稳定性上目前对于这种深度集成工作流支持得更好。安装过程很简单但从一开始就要为安全测试做好配置。安装完成后第一件事是开启HTTPS解密功能。在菜单栏点击Tools - Options - HTTPS勾选“Capture HTTPS CONNECTs”和“Decrypt HTTPS traffic”。这时Fiddler会生成一个唯一的根证书。你必须点击“Actions”按钮选择“Export Root Certificate to Desktop”将这个证书文件通常是FiddlerRoot.cer导出来。这个证书是你整个信任链的起点稍后需要安装到测试手机和Burp Suite的信任库中。注意在Windows上Fiddler的根证书也会安装到当前用户的Windows证书存储区。如果你在后续步骤中遇到证书信任问题可以尝试在这里运行certmgr.msc的“受信任的根证书颁发机构”中查看和管理Fiddler的证书。接下来是关键的一步配置Fiddler监听所有接口并允许远程连接。继续在Tools - Options - Connections选项卡中确保“Fiddler listens on port”设置了一个端口比如8888。然后必须勾选“Allow remote computers to connect”。这个选项允许你的移动设备和后续的Burp Suite将流量发送到这台电脑的Fiddler。完成设置后重启Fiddler使配置生效。此时你的电脑IP如192.168.1.100加上端口8888就成为了一个可被外部访问的代理服务器地址。2.2 Burp Suite Professional后端深度分析引擎Burp Suite这边我们主要需要配置两件事一是让它能接收来自Fiddler的转发流量二是要信任Fiddler的解密证书否则所有HTTPS流量在Burp里都会显示为证书错误。首先配置Burp的代理监听器。打开Burp进入Proxy - Options面板。在“Proxy Listeners”部分点击“Add”。在弹出的对话框中绑定端口可以选一个Fiddler未占用的比如8080。关键点在于“Bind to address”这里我建议选择“Loopback only (127.0.0.1)”。因为我们只希望Fiddler运行在同一台机器上的流量转发过来而不希望其他网络设备直接连接到Burp这样可以减少不必要的暴露面。这样Burp就监听在127.0.0.1:8080上静待Fiddler的“投喂”。其次导入并信任Fiddler的CA证书。这是保证HTTPS流量能在两个工具间无损传递的核心。在Burp Suite中进入Project options - TLS选项卡。找到“Client TLS certificates”部分点击“Import/export CA certificate”区域的“Import”按钮。选择你之前从Fiddler导出的FiddlerRoot.cer文件。导入后Burp就会信任由Fiddler签发的所有站点证书从而能够正常解密和显示经过Fiddler中转的HTTPS流量内容。2.3 移动端设备完成信任链的最后一环要让测试手机乖乖地把所有流量都发送到你的电脑需要在手机上进行代理和证书配置。首先确保手机和运行Fiddler的电脑在同一个局域网内。对于Android设备进入WLAN设置长按当前连接的Wi-Fi选择“修改网络”。展开“高级选项”将代理设置为“手动”。代理主机名填写你电脑的局域网IP地址代理端口填写Fiddler的监听端口如8888。保存后用手机浏览器访问http://你的电脑IP:8888例如http://192.168.1.100:8888。这个页面是Fiddler提供的点击“FiddlerRoot certificate”链接下载证书。下载后根据系统提示安装证书。对于Android 7.0及以上版本通常需要将证书安装到“VPN和应用”或“Wi-Fi”凭据存储中具体路径因厂商而异。安装成功后最好在系统设置的“加密与凭据”-“用户凭据”中确认证书已存在。对于iOS设备同样在Wi-Fi设置中配置HTTP代理填入服务器电脑IP和端口8888。用Safari浏览器访问http://你的电脑IP:8888点击下载证书。下载完成后进入“设置”-“通用”-“VPN与设备管理”点击已下载的描述文件进行安装。这是关键一步安装后必须进入“设置”-“通用”-“关于本机”-“证书信任设置”找到刚刚安装的Fiddler根证书并开启完全信任。否则iOS系统默认不信任用户安装的CA导致HTTPS连接失败。完成以上三步一个基础的“Fiddler抓包 - 手动转发到Burp”的链路就通了。但这还不够自动化我们需要让Fiddler自动、准确地将流量转发给Burp。3. 自动化流量转发规则与脚本编写手动在Fiddler里一条条把请求拖到Burp里测试是低效的。我们的目标是让所有捕获到的、符合特定条件的流量自动流向Burp Suite。这需要通过Fiddler的脚本功能来实现。3.1 FiddlerScript基础理解规则引擎FiddlerScript是基于JScript .NET的脚本可以在Fiddler的Rules - Customize Rules...菜单中打开默认是CustomRules.js文件。这个文件控制着Fiddler的核心行为。我们需要修改的是请求和响应的处理管道。脚本中主要会用到以下几个函数OnBeforeRequest(oSession): 在Fiddler将请求发送到服务器之前触发。这是我们修改请求、决定是否转发给Burp的关键位置。OnBeforeResponse(oSession): 在Fiddler将响应返回给客户端之前触发。可以在这里修改响应内容。OnPeekAtResponseHeaders(oSession): 在收到响应头时触发。我们的核心逻辑将在OnBeforeRequest中实现检查当前会话oSession是否符合我们设定的条件比如主机名、URL路径、内容类型等如果符合则将其请求重新指向Burp Suite的监听端口。3.2 编写自动转发脚本下面是一个基础但功能完整的自动转发脚本示例。你可以将其添加到CustomRules.js文件的OnBeforeRequest函数中或者放在一个独立的逻辑块里。import System; import Fiddler; class Handlers { // 定义Burp Suite的监听地址和端口 static var BURP_PROXY_HOST 127.0.0.1; static var BURP_PROXY_PORT 8080; // 定义需要转发到Burp的目标规则可根据需要修改或扩展 static var TARGET_DOMAINS [api.targetapp.com, app.example.com]; // 目标域名列表 static var TARGET_PATH_CONTAINS [/v1/, /auth/, /payment/]; // URL路径关键词 static var SKIP_EXTENSIONS [.css, .js, .png, .jpg, .gif, .ico, .woff, .woff2]; // 跳过的静态资源 static function OnBeforeRequest(oSession: Session) { // 规则1跳过本地或Fiddler/Burp自身的流量防止循环代理 if (oSession.host.ToLower() localhost || oSession.host 127.0.0.1 || oSession.host.Contains(fiddler) || oSession.host BURP_PROXY_HOST) { return; } // 规则2跳过静态资源提升效率 var url oSession.PathAndQuery.ToLower(); for (var i in SKIP_EXTENSIONS) { if (url.EndsWith(SKIP_EXTENSIONS[i])) { return; } } // 规则3根据域名匹配决定是否转发 var host oSession.host.ToLower(); var shouldForward false; for (var i in TARGET_DOMAINS) { if (host.Contains(TARGET_DOMAINS[i].ToLower())) { shouldForward true; break; } } // 规则4或者根据URL路径关键词决定是否转发 if (!shouldForward) { for (var i in TARGET_PATH_CONTAINS) { if (url.Contains(TARGET_PATH_CONTAINS[i].ToLower())) { shouldForward true; break; } } } // 如果决定转发则修改会话的目标主机和端口为Burp if (shouldForward) { // 保存原始主机信息方便查看 oSession[x-overrideHost] oSession.host; // 重定向请求到Burp Suite oSession[x-overrideGateway] BURP_PROXY_HOST : BURP_PROXY_PORT; // 可选在Fiddler界面为该会话添加标记便于识别 oSession[ui-color] orange; oSession[ui-bold] 这是一条转发到Burp的请求; } } }这段脚本做了几件事定义常量设置Burp的地址和过滤规则。防止循环代理避免将发送到Burp或本地的流量再次转发造成死循环。过滤静态资源图片、样式表等文件通常安全风险较低跳过它们可以大幅减少Burp的负担让测试更聚焦。智能匹配根据你预设的目标域名或URL路径关键词决定是否转发。你可以轻松修改TARGET_DOMAINS和TARGET_PATH_CONTAINS数组来适应不同的测试目标。执行转发通过设置x-overrideGateway属性Fiddler会将此请求发送到指定的主机和端口即我们的Burp Suite。视觉标记为转发的请求添加颜色和注释在Fiddler的会话列表里一目了然。保存脚本后无需重启Fiddler规则会立即生效。现在所有匹配规则的移动端App流量都会自动流经Fiddler然后被无缝转发到Burp Suite的代理监听器127.0.0.1:8080。3.3 高级过滤与条件转发基础脚本能满足大部分需求但在复杂场景下你可能需要更精细的控制。这里分享几个我常用的高级技巧基于响应内容的动态转发有时候是否转发需要根据上一个请求的响应来决定。例如只转发登录成功后的会话流量。这需要在OnBeforeResponse中设置标志然后在OnBeforeRequest中检查。static function OnBeforeResponse(oSession: Session) { // 如果响应中包含登录成功的令牌则在会话中做个标记 if (oSession.PathAndQuery.Contains(/login) oSession.oResponse.headers.ExistsAndContains(Set-Cookie, auth_token)) { oSession[user-authenticated] true; } } static function OnBeforeRequest(oSession: Session) { // 检查当前会话是否带有已认证的标记或者检查请求头中是否包含认证令牌 if (oSession[user-authenticated] true || oSession.oRequest.headers.Exists(Authorization)) { // 转发已认证的流量 oSession[x-overrideGateway] BURP_PROXY_HOST : BURP_PROXY_PORT; } }排除特定测试工具流量如果你同时在用Burp的主动扫描器Intruder, Scanner这些工具发出的请求也会被Fiddler捕获并再次转发导致混乱。你需要排除源IP是Burp的流量。static function OnBeforeRequest(oSession: Session) { // 如果请求来自Burp的端口假设Burp监听8080则直接放行不转发 if (oSession.clientPort BURP_PROXY_PORT) { return; } // ... 其余转发逻辑 }使用外部配置文件将目标域名、关键词等规则写死在脚本里不利于维护。可以将其保存为一个外部JSON或TXT文件在脚本启动时加载。// 假设有一个 config.txt 文件每行一个规则 var ruleFile System.IO.File.ReadAllLines(C:\\FiddlerConfig\\targets.txt); var TARGET_DOMAINS []; for (var i in ruleFile) { if (!ruleFile[i].StartsWith(#) ruleFile[i].Trim() ! ) { // 忽略注释和空行 TARGET_DOMAINS.push(ruleFile[i].Trim()); } }4. 实战场景应用与深度测试技巧搭建好自动化中转站只是开始如何利用它高效地进行安全测试才是关键。下面结合几个典型场景分享我的实战心得。4.1 场景一对抗证书绑定与协议检测越来越多的App采用了SSL Pinning证书绑定或检测系统代理导致即使安装了Fiddler的CA证书也无法捕获其HTTPS流量。此时Fiddler的预处理能力就派上用场了。方法一使用Fiddler的协议降级。有些App的证书绑定只针对高版本的TLS协议。在Fiddler的Rules - Performance - Hide (or Simulate) Protocol Violations菜单下你可以尝试勾选“Ignore server certificate errors”等选项。更有效的是在OnBeforeRequest脚本中强制将会话协议版本降级if (oSession.hostnameIs(tough.app.com)) { // 尝试移除ALPN扩展或强制使用旧协议但这可能影响连接稳定性 oSession[x-ClientHello-Protocols] http/1.1; // 或者直接修改请求的TLS版本标识需谨慎 // oSession.oRequest[tls-handshake] ... }注意协议降级可能被服务器拒绝或导致连接异常这本身也是一个安全测试点是否支持弱协议。方法二配合移动端Hook框架。这是更彻底的解决方案。对于Android可以配合使用Xposed、Frida或JustTrustMe模块来绕过证书绑定。你需要先在已Root的Android设备或模拟器上安装这些框架然后启用禁用证书绑定的模块。之后App的流量就会乖乖地流经Fiddler了。在这种情况下FiddlerBurp的中转站架构依然有效它负责接收被“解放”后的流量并转发给Burp进行深度测试。4.2 场景二高效进行API接口模糊测试当所有目标API流量都自动汇聚到Burp Suite后你可以利用Burp的强大工具进行高效测试。流量地图与梳理首先在Burp的Proxy - HTTP history中你已经能看到所有转发的请求。使用Target - Site map功能Burp会自动为你梳理出整个App的接口地图、参数结构非常直观。主动扫描右键点击某个主机或目录选择“Actively scan this branch”。Burp Scanner会自动对这些接口进行常见漏洞如SQLi、XSS、命令注入的扫描。由于流量是实时的你可以在App上操作触发新的接口Burp的扫描队列也会实时更新。Intruder爆破与模糊测试这是核心手动测试环节。在Proxy历史记录中右键选中一个包含参数的请求如登录请求发送到Intruder。设置好攻击类型如Sniper, Cluster bomb标记需要测试的参数位置加载你的字典用户名、密码、ID等然后开始攻击。Burp会自动化地进行重放测试并清晰展示不同Payload的响应状态、长度、内容差异帮你快速找出弱口令、ID遍历、SQL注入等漏洞。Repeater手动微调对于复杂的业务逻辑漏洞如条件竞争、顺序绕过、权限校验缺陷Repeater是你的最佳伙伴。将请求发送到Repeater你可以手动修改任何一个参数、Header反复重放观察响应变化。结合Fiddler中转你可以确保每次修改后的请求依然经过完整的App处理上下文携带正确的Cookie、Token。4.3 场景三会话管理与多用户测试很多业务漏洞如越权访问需要在不同用户会话上下文下测试。FiddlerBurp的架构能很好地管理这一点。在Burp中管理会话Burp Suite的Project options - Sessions功能非常强大。你可以配置会话处理规则自动从响应中提取Token如Cookie中的sessionid并在后续请求中替换。你还可以创建多个“会话处理”配置对应不同的测试用户。配合Fiddler脚本切换上下文你可以扩展之前的转发脚本根据请求中的某个特征如特定的Header值或URL参数动态决定将流量转发到Burp的哪个“用户上下文”对应的监听端口如果你为不同用户配置了不同的Burp监听端口虽然不常见。更常见的做法是在Burp内部使用一个主监听器但通过Sessions规则来动态管理多个用户的Cookie Jar。一个实用技巧是利用Fiddler的AutoResponder功能在测试初期快速模拟登录状态。你可以先捕获一次成功的登录请求和响应然后将这个响应保存为AutoResponder规则。之后任何匹配登录请求的流量都会被这个成功的响应直接返回从而绕过登录流程快速进入需要登录态的功能测试页面节省时间。5. 常见问题排查与性能调优实录即使搭建过程再顺利在实际长期使用中你也一定会遇到各种“坑”。下面是我总结的一些典型问题及其解决方案。5.1 证书错误与HTTPS解密失败这是最常见的问题现象是手机App无法联网或Burp Suite中看到的HTTPS请求全是证书错误。排查链1手机证书是否安装并完全信任现象手机浏览器访问HTTP网站正常但HTTPS网站或App内无法联网。解决重新访问http://电脑IP:8888下载并安装证书。对于iOS务必在“证书信任设置”中启用完全信任。对于Android高版本确认证书安装到了正确的存储位置“VPN和应用”或“Wi-Fi”。排查链2Fiddler的HTTPS解密配置是否正确现象Fiddler能抓到HTTP请求但HTTPS请求显示为Tunnel to。解决检查Tools - Options - HTTPS确保“Decrypt HTTPS traffic”已勾选。尝试点击“Actions - Reset All Certificates”重置证书然后重新导出并安装到手机和Burp。排查链3Burp是否信任Fiddler证书现象Fiddler里能看到解密的HTTPS流量但转发到Burp后在Burp的HTTP历史中显示为证书错误如certificate_unknown。解决确认已按照2.2节步骤将Fiddler的根证书FiddlerRoot.cer导入到Burp的CA证书列表中Project options - TLS。排查链4是否遇到证书绑定现象特定App如银行、支付类完全无法抓包即使证书安装正确。解决参考4.1节尝试使用Fiddler的协议模拟选项或配合移动端Hook框架如Frida进行绕过。5.2 流量未按预期转发到Burp检查FiddlerScript是否生效在Fiddler界面看看匹配规则的请求是否被标记了颜色如我们在脚本中设置的橙色。如果没有可能是脚本未保存或语法错误。打开Rules - Customize Rules检查底部状态栏是否有错误提示。检查Burp监听器是否运行确认Burp Suite的Proxy监听器如127.0.0.1:8080处于Running状态。检查转发规则逻辑确认你的目标域名或路径关键词拼写正确且逻辑符合预期。可以在脚本中添加调试日志FiddlerObject.log(Processing request to: oSession.host oSession.PathAndQuery); FiddlerObject.log(Should forward? shouldForward);然后在Fiddler的View - Show Fiddler Log中查看输出。检查循环代理确保脚本中已正确排除发往Burp端口8080和本地主机的流量防止请求在Fiddler和Burp之间无限循环。5.3 性能问题与优化建议当捕获的流量非常大时可能会拖慢测试速度或导致工具卡顿。精细化过滤这是提升性能最有效的方法。在FiddlerScript的SKIP_EXTENSIONS数组中尽可能多地添加静态资源后缀如.css, .js, .png, .jpg, .svg, .woff2, .map。大部分安全测试不关心这些文件。限制转发范围不要将所有流量都转发给Burp。利用TARGET_DOMAINS和TARGET_PATH_CONTAINS精确控制只转发与核心业务相关的API流量。调整Fiddler和Burp的缓冲区设置在Fiddler的Tools - Options - Performance中可以调整缓冲和压缩设置。在Burp的Project options - Misc中可以限制HTTP历史记录和站点地图的大小。定期清理会话长时间测试后Fiddler和Burp都会积累大量会话数据。定期在Fiddler中点击Edit - Remove - All Sessions清除。在Burp中可以右键点击Proxy历史或Site map选择删除不需要的条目。使用更强大的硬件如果条件允许为运行Fiddler和Burp的机器分配更多的内存建议16GB以上。Burp Suite尤其是Professional版的Scanner和Intruder是内存消耗大户。5.4 移动端网络异常与连接断开电脑防火墙确保Windows防火墙或其他安全软件没有阻止Fiddler监听端口8888的入站连接。Wi-Fi网络稳定性使用稳定的Wi-Fi网络避免使用企业级网络或有复杂代理策略的网络这些网络可能会干扰你的本地代理设置。Fiddler的“流模式”默认情况下Fiddler使用“缓冲模式”会等服务器返回完整响应后再转发给客户端。对于视频流或长连接这可能导致问题。你可以点击Fiddler左下角的“Streaming”按钮切换到“流模式”实现请求和响应的实时流转。但注意在流模式下一些自动修改响应的脚本可能无法正常工作。手机代理设置失效部分手机在锁屏或切换网络后代理设置可能会被重置。需要重新检查手机的Wi-Fi代理配置。这套“FiddlerBurp Suite双剑合璧”的自动化流量中转站经过我多年的实战检验已经成为移动端安全测试的标准起手式。它巧妙地将两个工具的优势结合化解了移动端抓包的诸多痛点让测试人员能够更专注于安全漏洞本身。从环境搭建、脚本编写到实战排错每一个环节的细节都决定了最终测试的流畅度和深度。希望这份详尽的指南能帮助你搭建起属于自己的高效移动安全测试工作流在纷繁复杂的流量中精准地找到那些隐藏的安全漏洞。