说实话Web安全这行干了这些年如果只让我给新手推荐一个必须吃透的工具我毫不犹豫选Burp Suite。市面上抓包改包的工具一抓一大把Fiddler、Charles、Wireshark各有各的长处但真要论Web渗透测试的完整度Burp Suite依然是绕不开的那个。今天这篇就把我实际工作中最常用的四个模块——抓包、改包、重放、爆破——从头到尾拆开讲一遍不是照搬官方文档而是把我踩过的坑、总结出来的经验和参数设置思路都写出来希望对刚入门或者用了一段时间还在皮毛上打转的朋友有点帮助。这篇内容适合什么人看一是刚接触Web安全、想系统学习Burp Suite操作的新手二是已经会用基本抓包但没深入用过Repeater和Intruder的初中级测试人员三是日常工作里需要做接口调试、参数校验的前后端开发Burp在这些场景下也一样好用。下面我按实际测试流程的顺序来讲先搞定环境再做抓包然后是改包和重放最后是爆破模块的重头戏每一步都尽量把原理和实操放一起说。1. 先搞懂Burp Suite到底帮你干什么1.1 从一次真实的测试经历说起之前有个朋友问我说他用浏览器F12的开发者工具也能看请求、也能改参数重新发一遍为什么还要装Burp Suite这么个大家伙这个问题问得特别好正好能说明Burp的定位差异。浏览器F12做的事情是浏览器发什么请求、收什么响应你在开发者工具里看的是浏览器替你完成的通信记录。这里有个关键限制你很难在请求发出的瞬间去拦截它、修改它的内容、然后再放行。F12的“Edit and Resend”虽然能改参数重发但它走的还是浏览器自己的网络栈很多测试场景根本覆盖不了。Burp Suite干的事情完全不同。它把自己架在浏览器和服务器中间做的是一个正向代理。你先把浏览器的代理地址指向Burp然后浏览器发出的所有HTTP/HTTPS请求都会先经过Burp由Burp转发到目标服务器。这个“中间人”的位置给了你极大的控制权请求在离开浏览器之后、到达服务器之前你可以拦截住它把参数改了、把请求头换了、把Cookie删了甚至把整个请求停下来不放行想怎么折腾怎么折腾。服务器返回的数据也一样在到达浏览器之前你可以先看到、先修改再决定要不要放给浏览器。所以Burp Suite最核心的价值不是“看请求”而是“掌控请求”。它让你真正站在了客户端和服务端的通信链路上这在渗透测试里是决定性的能力。你测试一个登录接口是否存在SQL注入不拦截直接在F12里改参数提交的瞬间浏览器可能还带上了自己的Cookie、Session、Origin头之类的东西这些都会干扰你对结果的判断。而用Burp拦截改包你可以把请求头洗得干干净净一个多余的字段都不带精准验证你关心的那一个点。1.2 社区版够不够用专业版要不要上Burp Suite分社区版Community和专业版Pro还有个企业版是给团队做持续扫描用的普通人一般用不上。很多人一上来就问是不是必须用Pro我的建议是学习阶段社区版完全够用但真的深入工作之后Pro的几个功能会让你效率翻倍。社区版免费功能上抓包、改包、Repeater这些核心模块一个不少限制主要在Intruder爆破模块上一是爆破速度被限制在低速档位二是不能保存项目配置。此外没有主动扫描器。如果你只是学习和做手工测试社区版足够了。Pro版本的话最值钱的是主动扫描功能、更快的爆破速度和BApp扩展支持价格确实不便宜个人学习不建议先上。我的操作习惯是本地用社区版做学习和练习工作环境用Pro。如果你们团队预算有限社区版也完全能支撑起手工渗透测试的大部分需求别觉得工具低配就没法做事关键是看你怎么用。1.3 环境准备和版本选择Burp Suite是Java写的跨平台Windows、macOS、Linux都能跑。需要注意的是它依赖Java运行时环境而且不同版本的Burp对Java版本要求不一样。新版Burp Suite 2023以上版本建议用Java 17及以上装之前先确认一下你机器上的Java版本用java -version看一眼就行。版本不对最典型的问题就是起不来或者启动后界面错乱。下载安装没啥好说的官网下载对应平台的安装包一路下一步就行。装完之后第一件事——别急着用它先把代理配置搞清楚。Burp默认监听地址是127.0.0.1:8080你要在浏览器里把代理指到这个端口。Chrome可以装SwitchyOmega插件来管理代理配置Firefox可以直接在设置里配。用SwitchyOmega的好处是可以按场景切换代理比如你访问公网普通网站时走直连测试目标时走Burp避免所有流量都被拦截导致打开什么网页都报错。我见过太多新手卡在第一步Burp开了浏览器里也配了代理但就是抓不到包。十有八九是没弄明白浏览器和代理之间的工作关系要么是代理没配对手要么是代理配了但没生效。记住一个检查思路配完代理后随便访问一个HTTP网站如果Burp的HTTP history里能看到记录说明链路通了如果浏览器直接报502或无法访问先检查Burp的代理监听是否正常启动再检查浏览器代理设置。2. 抓包模块流量入口所有测试从这里开始2.1 代理配置与HTTPS证书处理抓包是所有操作的起点。Burp启动后默认在Proxy Options里能看到代理监听设置默认监听127.0.0.1:8080。这个配置一般不用改除非你8080端口被占了那就换一个。HTTP流量配置好代理就能抓到明文但现在的Web应用基本都是HTTPS这就涉及证书信任的问题。HTTPS是加密的Burp要做中间人必须给浏览器颁发一个它自己的根证书让浏览器信任这个证书Burp才能解密HTTPS流量看到明文内容。证书安装路径浏览器访问http://burp页面会提示下载CA证书。下载后安装到系统“受信任的根证书颁发机构”里。关键点来了——很多人在这一步栽跟头。浏览器的证书信任有时和系统证书不是一套比如Firefox用的是自己的证书库你光在系统里装证书是不够的还得在Firefox的设置里单独导入。Chrome用的是系统证书库系统装了之后Chrome一般就认了。macOS上除了钥匙串里装还得在“系统”分类下装并且把信任级别设为“始终信任”少一步都不行。证书装好后你访问HTTPS网站就不会再报证书错误Burp的HTTP history里也能正常看到明文请求了。这里提醒一句装了Burp证书之后你的浏览器会信任Burp这个中间人证书这意味着如果Burp没开启状态或者代理配置出问题你访问HTTPS网站时浏览器会报证书错误这是正常的排查时心里有数就行。2.2 流量过滤与历史记录分析抓包不难难的是在一堆请求里快速找到你关心的那一个。一个正常的Web页面打开几十上百个请求瞬间就进来了什么图片、CSS、JS、字体文件全是噪音。你要是挨个看眼睛都得看花。Burp的HTTP History面板提供了强大的过滤功能这个是提高效率的关键。最常用的是在Filter栏里设置只显示特定主机比如你测试的目标域名、只显示JS和文档类型、隐藏静态资源文件扩展名、只看有参数项的请求。我自己的习惯是测试时先把Filter设置成只显示目标域名的请求这样不管是找登录接口还是找上传接口列表都干净很多。还有个小技巧在HTTP History里可以直接看请求的响应码、响应时间、MIME类型。响应时间这个指标特别有用如果一个接口响应时间明显加长比如其他接口都是50ms它要3秒钟那很可能存在时间盲注的潜在风险点值得进一步测试。这个判断维度很多人会忽略但实践中很能发现问题。2.3 手机抓包与无root环境的替代方案现在很多测试目标是App或者小程序这就涉及手机抓包的问题。电脑上浏览器抓包配好代理就行手机稍微麻烦一点因为手机流量要经过电脑端的Burp代理并且也要信任Burp证书。以Android手机为例基本流程是手机和电脑连同一个WiFi在WiFi设置里手动配置代理代理地址填电脑的局域网IP端口8080。然后手机浏览器访问http://burp下载证书并安装。这里有个大坑——Android 7.0API 24及以上版本应用默认不信任用户安装的CA证书就算你系统里装了证书很多App照样不鸟你直接报错或者干脆不走代理。解决思路有两类一类是测试debug包让开发在AndroidManifest里配置networkSecurityConfig允许信任用户证书这个适合自己团队的App做测试另一类是root设备后用Magisk模块把Burp证书装进系统证书目录我常用的模块叫MagiskTrustUserCerts可以把用户证书自动同步为系统证书。无root环境的话也可以尝试用LSPosed配合TrustMeAlready这类Xposed模块来绕过证书校验不过这就涉及更多工具链配置复杂度更高。iOS设备相对好一些安装Burp证书后在设置 通用 关于本机 证书信任设置里开启完全信任就行。不过iOS 10.3以后也需要到设置里手动打开证书信任开关忘了这一步也会抓不到HTTPS包。3. 改包模块把请求“洗”成你想要的样子3.1 拦截开关与实时编辑改包是Burp和普通调试工具最核心的区别点。在Proxy Intercept选项卡里默认拦截状态是开着的。打开状态下所有匹配拦截规则的请求都会停在Burp这里然后你可以在请求区里任意修改改完之后点Forward放行或者点Drop直接丢弃。实际测试中拦截开关不要一直开着。如果你开着拦截去看网页每个请求都需要手动放行烦得要命页面加载也会卡住。正确姿势是先关掉拦截正常操作把请求发给目标然后在HTTP History里找到感兴趣的请求右键选择Send to Repeater或者Send to Intruder再慢慢想怎么改。拦截模式更适合那种需要在请求发出瞬间做修改的场景比如你在页面上点了一个按钮请求正要发出去这时候你切到Burp去改请求头或者参数。3.2 请求头、Cookie与Body的修改技巧改包能改什么理论上请求的任何部分都能改。常用的包括修改请求头比如User-Agent伪装成不同浏览器Referer伪造来源页面X-Forwarded-For伪造客户端IP。修改Cookie和Session比如测试越权漏洞时把A用户的Cookie替换成B用户的看能不能访问B用户的数据。修改Body参数这是最常用的。比如金额字段、商品数量、用户ID、角色标识等全部可以改成你想测试的值。举一个实际例子测试一个购物网站的订单金额是否可以篡改。正常下单时请求里可能会带上商品单价参数比如price100你把这个值改成price1服务器如果没做服务端校验直接信任前端传来的价格那这个漏洞就很严重了。这就是经典的“参数篡改”场景也是改包技术的核心价值所在。改Header的思路则是另一个层面。比如你要测试某个管理接口是否存在权限绕过直接把请求头里的X-Forwarded-For: 127.0.0.1加上有些粗糙的服务端程序会认为请求来自本机从而放行管理操作。这种头伪造在测试中非常常见也是很多系统真实存在的隐患。3.3 Response修改与前端校验绕过改包不光是改请求响应也一样能改。Switch to response你就能看到服务器返回的数据然后直接修改再转发给浏览器。这个功能在绕过前端校验的时候特别有用。举个典型场景一个登录页面前端JavaScript限制了密码最少8位且必须包含大小写字母和数字。你要测试弱口令“123456”但前端根本不让你提交。这时候可以用Burp拦截登录请求直接构造一个包含“123456”的请求发给服务器。服务器端的校验逻辑可能就没有前端那么严格了直接返回登录成功。这个测试证明了什么问题说明服务端校验缺失前端限制形同虚设。响应修改的另一个用法是看隐藏数据。有些页面会把部分信息藏在响应的HTML注释里或者隐藏字段里前端不显示但响应里能看到。通过改响应你可以把隐藏字段改成显示或者把禁用的按钮改成可用的方便观察后续功能。3.4 Match and Replace规则自动改包的效率神器如果每次改包都手动来遇到大量重复测试时效率就很低。Burp的Match and Replace规则可以自动完成一些常规替换。在Proxy Options Match and Replace里可以配置规则。比如你测试的接口总是返回很大的响应你可以把Content-Type: text/html改成Content-Type: text/plain方便在浏览器里直接查看内容。或者把请求头里的某个固定值自动替换成另一个值省去手动改的麻烦。常见的配置还有自动加X-Forwarded-For: 127.0.0.1头、自动删除If-Modified-Since头避免缓存干扰。这些规则一旦配好后续测试就省心了属于“一次配置长期受益”的功能强烈建议花点时间研究一下。4. 重放模块Repeater的手工测试利器4.1 从History到Repeater的快捷流转Repeater是Burp里我使用频率最高的模块中文叫重放器。一句话说明它的用途把已经抓到的请求原样或者修改后再发一遍然后观察响应。这个模块解决的核心问题是你想精确地、可重复地测试一个接口而不是每次都在浏览器里重新操作一遍。从HTTP History里找到请求右键Send to Repeater请求就会被发送到Repeater面板。这里请求是可以随意编辑的你可以删掉某个参数看看服务器返回什么可以改参数值对比不同输入下响应的差异可以改请求方法从GET改成POST试试甚至可以重复发送Send按钮一次一次地看响应。Repeater界面上方是请求区下方是响应区。发送后响应直接显示在下面状态码、响应头、响应体一目了然。这里有组快捷键很重要CtrlR发送请求CtrlShiftR发送请求但不等待响应。测试时我基本不点按钮全是快捷键操作效率高太多。4.2 越权测试与参数组合实战Repeater最典型的应用场景是水平越权和垂直越权测试。水平越权就是用户A能访问用户B的数据垂直越权就是普通用户能执行管理员操作。测试步骤大概是这样的先用正常账号登录抓一个查看个人信息的请求比如GET /api/user/info?id1001发送到Repeater。然后把参数改成id1002发送看响应里是否返回了1002这个用户的信息。如果返回了那就是水平越权漏洞。再换个思路把请求头的某个管理标识加上或者把接口路径从/user/改成/admin/user/看普通用户能不能访问管理端接口这是垂直越权的测试思路。参数组合测试也是Repeater的强项。比如注册接口有用户名、手机号、邮箱三个字段你可以分别测试只填用户名不填手机号、手机号填一个不存在的号码、邮箱填一个格式非法的值……每种组合发送一次观察服务器端的处理逻辑和报错信息。有些开发对参数校验做得不严格少一个必填参数都不报错或者报错信息里泄露了内部数据结构这些都是有价值的发现。4.3 手工测试中的断言与结果分析响应的变化是判断漏洞存在与否的关键依据。在Repeater里测试时我会特别关注几个维度响应状态码变化200变500说明参数出问题了200变302说明跳转了可能涉及未授权访问。响应长度变化响应体长度突然变长很多可能返回了额外的数据。响应内容差异对比正常请求和修改后请求的响应主体看是否存在关键数据泄露。一个容易被忽略的点是Burp左下角的响应区有个Render按钮点击后可以把HTML响应渲染成网页的样子。这个功能在分析复杂页面时非常好用比直接看源码直观很多。不过测试时建议主要看Raw格式因为渲染后的页面可能屏蔽掉一些细节比如额外字段、注释信息等。Repeater还有个实用功能是Change request method右键点击请求行可以直接把POST请求转换成GET或者反过来。这个在测试一些接口是否校验请求方法时很管用有些后端只处理特定方法其他方法直接放行就可能产生绕过。5. 爆破模块Intruder的攻击面探索5.1 四种攻击类型怎么选Intruder是Burp Suite的爆破模块也是很多人认识Burp的起点。它的本质是自动化地发送大量请求用不同的payload去测试同一个请求模板。理解Intruder之前先搞明白它支持四种攻击类型每种适合不同的场景Sniper狙击手一次只爆破一个位置。适合单参数测试比如只爆破一个密码字段。Payload数量决定请求总数。Battering Ram攻城锤多个位置使用同一个payload值。适合多个参数需要相同输入的场景比如同时测试用户名和密码都填同一个值的情况。Pitchfork草叉多个位置分别使用不同的payload列表按顺序一一对应。适合用户名和密码需要配对的场景比如用固定的用户名列表对应固定的密码列表第N个用户名配第N个密码。Cluster Bomb集束炸弹多个位置各自使用不同的payload列表笛卡尔积组合。适合用户名和密码需要随机组合爆破的场景请求量是各个列表大小的乘积。实际测试中Sniper和Cluster Bomb用得最多。Sniper适合单点爆破Cluster Bomb适合组合爆破。选错类型会导致测试量级完全不同。比如有100个用户名、100个密码用Pitchfork只需要100个请求用Cluster Bomb则需要10000个请求差异巨大要根据测试目标本身的逻辑来决定。5.2 Payload配置与字典选择的门道爆破效果好不好很大程度上取决于字典好不好。Burp自带的Payload类型有很多种Simple list简单列表是最常用的直接粘贴或者加载一个字典文件就行。但聪明的做法是根据目标情况选择更精细的payload如果目标是4位数字短信验证码用Numbers类型设置从0000到9999只需要10000个请求。如果目标是常见用户名加载一个常见用户名字典比暴力遍历所有单词效率高得多。如果目标是密码可以试试字典规则的组合比如在字典基础上做大小写转换、末尾加数字、常见年份追加等变换。Burp的Payload Processing规则可以对这些变化做自动化处理。比如加载一个基础字典然后添加规则依次生成“密码123”、“密码2024”、“密码!#”等衍生变体这样能大幅扩大字典覆盖面。我实际测试时一个3000条的弱密码字典经过这些规则扩展后能覆盖几万种常见组合比直接用大字典更快更精准。5.3 请求限速、线程数与规避封禁的实战配置用Intruder爆破的时候最怕的不是爆破失败而是把目标搞挂了或者触发封禁。很多Web应用都有防暴力破解机制比如连续登录失败5次锁定账号15分钟。所以爆破模块的配置里除了payload本身还要考虑怎么“低调”地爆破。关键配置在Resource Pool资源池里。这里可以限制最大并发请求数和请求间隔。默认设置是并发10个请求没有延迟。对多数目标来说这个速度太激进了。我常用的配置是并发数5-8加上Fixed delay大约500-1000毫秒的延迟。这样每秒请求量大概在5-10个比较接近正常人手工操作的速度不容易触发风控。在Settings里还可以设置Throttle between requests请求间延迟更精细地控制每两个请求之间的间隔时间。而且Intruder的请求速率可以通过资源池做精细调控测试时我会根据目标的响应速度和是否存在验证码机制来动态调整。如果发现请求开始大量超时或者返回403说明触发风控了赶紧停掉爆破隔一段时间再继续。顺便说一个知识点如果你用社区版爆破会明显感觉到速度被限制得非常慢这是正常的。Pro版本的爆破速度上限远高于社区版这也是很多人升级Pro的最大动力。5.4 验证码、Token与登录态处理爆破登录接口时最大的拦路虎是验证码和动态Token。遇到验证码Intruder不能直接处理图片识别但是可以在Payload Processing里添加规则或者使用扩展插件来配合。常见做法是写一个自定义的Payload processor在每次请求前先请求一次验证码接口识别验证码内容然后把验证码字段和识别结果一起合并进请求模板。Burp的扩展API支持Java、Python等语言用Python插件配合第三方OCR库可以完成这个流程。不过这属于进阶玩法了新手阶段可以先跳过知道有这个思路就行。动态Token的问题更隐蔽。有些网站的表单里带一个csrf_token或者session_token每次都不同而且服务器校验这个token是否有效。如果你直接拿抓到的请求去爆破第一次可能成功第二次服务器就发现token不匹配直接返回错误。这种情况下爆破就废了。Burp Pro版的Session Handling Rules可以配置会话固定规则比如在每次爆破前自动重新请求一次登录页面提取新的Token再填充到爆破请求里。社区版和这部分功能有限但可以变通先用Repeater手动获取当前Token填入Intruder的payload里爆破次数控制在Token失效前完成。总之遇到Token就放低预期这已经不是简单的爆破问题而是逻辑对抗问题。5.5 基于响应特征的结果筛选Intruder爆破结束后会生成一个请求结果列表每个请求对应一个响应。几百上千个请求怎么快速找到成功的那一个靠眼睛一个个看肯定不行要掌握几个筛选技巧。最基础的是看Status列和Length列。登录成功一般返回302跳转或者200加欢迎语登录失败一般是200加错误提示。如果成功和失败都返回200那就看Length。成功的响应长度通常和失败的不同可能是多了一段个人信息HTML或者少了一段错误提示文本。在Intruder结果里按Length排序那些长度明显不同于大部队的请求就是可疑目标优先点开查看。更精确的做法是在Settings Grep - Match里添加匹配规则。比如登录失败时页面包含“用户名或密码错误”成功时包含“欢迎”你可以在爆破前设置这两个关键字的匹配规则爆破结束后结果列表里会直接显示每个响应是否包含这些关键字一眼就能锁定成功请求。这个方法在测试短信验证码爆破、验证接口爆破时一样适用强烈建议每次爆破前都先设置好Grep匹配能省不少筛查时间。等到你对所有正常请求的响应结构了如指掌之后还可以用Grep - Extract提取响应中的特定字段比如提取响应里的用户ID、Token作为后续请求的输入这个已经有点自动化测试的意思了。6. 抓包失败、证书无效等高频问题排查6.1 常见故障速查表Burp用久了各种问题都会遇到。我把这几年工作中最常见的故障整理成一张速查表看到对应症状直接对照解决。症状可能原因解决办法浏览器访问HTTPS网站报证书错误Burp根证书未安装或未信任重新下载CA证书并安装到受信任根证书库Firefox能抓http但抓不到httpsFirefox使用独立证书库在Firefox设置中单独导入Burp证书手机App抓不到包App不信任用户证书或做了证书校验root后安装证书到系统目录或使用框架绕过打开网页超时或502代理指向了Burp但Burp未运行确认Burp正在监听检查代理设置是否失效HTTP History里看不到目标域名请求Filter过滤规则挡住了在Filter里清除域名过滤或修改为显示全部Intruder爆破时请求全部失败配置了动态Token但未处理刷新逻辑更换为固定Token或编写会话规则自动提取抓包时卡在Intercept页面不放行拦截开关开启且请求匹配了拦截规则点击Forward放行或关闭Intercept开关安装证书后Chrome仍报证书无效系统信任设置没生效macOS需在钥匙串里将证书设为始终信任6.2 小程序和App抓包的疑难杂症小程序抓包近年问的人特别多。微信小程序走的HTTPS正常情况下只要你电脑上Burp证书装好小程序流量一样能抓到。但实际问题往往出在证书校验上——微信小程序框架默认开启证书校验信任的是系统内置的根证书库用户安装的证书它不认。解决办法常用的有三条路一是用旧版本的微信部分旧版本不做证书固定抓包相对容易二是用PC端微信配合Fiddler或Burp抓包PC端微信的小程序流量走系统代理只要系统证书信任了Burp就能抓到三是调试模式通过微信开发者工具运行小程序配合代理测试这种方式适合自己开发调试场景。App抓包失败的原因多数也是证书固定Certificate Pinning。主流App基本都做了防抓包处理比如对证书做SHA-256校验或者检测系统代理环境直接用安全连接。遇到这类目标纯靠改代理已经不够了得用Frida、Objection这类动态插桩工具去hook证书校验函数。这一块水比较深已经超出了Burp本身的教学范围但至少你先得判断清楚抓不到包到底是代理配置问题还是目标App安全机制的问题。判断方法很简单换一个普通App测试如果普通App能抓到而目标App抓不到那就是目标App做了防护。6.3 代理端口冲突与资源占用还有一种隐蔽的坑是代理端口冲突。你电脑上之前可能装过Fiddler、Charles或者其他代理工具它们默认用的也是8888、8080这类端口。如果多个工具同时监听同一个端口Burp就会起不来或者抓到的包是错乱的。排查方法启动Burp时如果提示端口被占用命令行用netstat -ano | findstr 8080看一下谁占了这个端口找到对应的PID然后在任务管理器里结束掉再重启Burp。这也是一个非常常见的环境问题遇到过几次之后就知道先查端口再查其他的。Burp长时间挂机后还会遇到内存占用过高的问题特别是抓了一整天的包、HTTP History里有几万条记录时。处理办法是定期清空HTTP History或者在Settings里配置自动清理规则只保留指定时间内的记录。这个我吃过亏有一次忘了清理Burp内存占用飙到好几个G电脑卡到鼠标都移不动。6.4 绕过iOS和Android代理限制的额外手段iOS 14以后系统对本地网络权限做了更严格的控制App默认无法访问本地网络也就是配置代理所在的那台电脑需要在设置 隐私 本地网络里允许对应App访问本地网络。很多时候iOS手机抓不到包就是这个权限没开先检查这里比上来就折腾证书省事得多。Android这边的坑则更多样。部分国产手机系统会在底层拦截代理设置或者WiFi的高级设置里藏得比较深用户根本找不到代理配置入口。常见的替代方案是使用ProxyDroid配合root权限设置全局代理或者使用ADB命令行设置全局代理命令大概是adb shell settings put global http_proxy 192.168.x.x:8080。这个命令在无root的测试机上也能用属于比较实用的技巧。7. 用Burp Suite建立自己的测试工作流讲了这么多模块最后再分享一下我平时是怎么把整个流程串起来用的。工具学得再好如果没有一套标准的测试思路用起来也是东一榔头西一棒子。7.1 目标分析先行工具配置紧跟拿到一个测试目标我的第一件事不是开Burp而是先理清目标是什么、范围在哪里。是纯Web系统还是App还是小程序登录流程是什么核心业务在哪些接口这些搞清楚之后再动Burp做测试。开Burp之后把代理配好、证书装好、过滤规则设好这些都是准备工作。然后我开始像正常用户一样操作目标系统完整走一遍注册、登录、浏览、下单、退出整个流程这个过程中HTTP History里会积累大量请求记录。这个阶段抓的数据越全后面测试的基础就越扎实。7.2 每个功能点都要过一遍改包和重放正常流程走完接下来是针对重点功能点做手工测试。登录接口、注册接口、找回密码、个人信息修改、文件上传、搜索列表这些是最容易出问题的地方。我一般会建一个搜狗输入法的词库一样的东西——把测试点分类然后挨个测试过去。拿登录接口来说我会做这么几件事先Send to Repeater测试万能密码和SQL注入特征再Send to Intruder做弱口令爆破测试同时关注是否存在用户名枚举问题用户名错误和密码错误的提示不一样就是一个信号。每个功能点对应一套测试动作这套动作熟练之后一个系统的安全测试半天就能完成大部分工作。7.3 请求记录如何整理成测试报告Burp有导出功能可以把HTTP History导出成XML或HTML格式但导出的文件很原始直接交出去没人看得懂。我的做法是测试过程中在Burp里给关键请求添加注释和标记测完之后对着这些标记整理报告。具体操作是在HTTP History里选中一个请求右键Add comment把测试结论写进去比如“存在水平越权可查看他人订单”。再用右键颜色标记功能给高危问题标红中危标黄。导出报告时这些注释和颜色会保留在导出的数据里整理报告时对着标记一条条写效率极高也不会漏掉问题。这也是Burp作为专业工具的细节设计用好了能省很多后期整理的时间。7.4 不断更新自己的字典和Payload库最后想强调一个容易被忽视的点Burp用得好不好很大程度取决于你的字典积累。默认的字典数量少、覆盖面窄到实际测试中效果有限。每次测试遇到好的弱口令、典型的注入payload、绕WAF的技巧我都随手记下来分门别类存进自己的字典库和payload库里。时间长了这些自己积累的资产比工具本身值钱得多。我自己现在常用的字典包括用户名Top10000、弱密码Top10000、SQL注入payload几百条、目录扫描字典、常见参数名字典等等都是这些年一点一滴攒下来的。这些字典配合Intruder用爆破的成功率比我刚入行时用默认字典高出一大截。建议你们也养成这个习惯每测一个项目就把新的测试思路和数据整理进自己的知识库这才是持续进步的正循环。最后再分享一个小技巧Burp的配置文件是可以导出的把常用的代理设置、匹配替换规则、资源池配置导出一份存起来换机器或者重装系统后直接导入分分钟恢复熟悉的工作环境。工具配置这种东西自己一点点调顺手了就是最好的复制一份下来也算给自己留个安稳。