1. 这不是“功能列表”而是渗透测试中三把被低估的手术刀很多人第一次打开 Burp Suite眼睛直奔Proxy和Repeater——这很自然毕竟流量拦截和请求重放是肉眼可见的“动作戏”。但真正拉开老手和新手差距的往往不是最显眼的模块而是三个看似安静、实则高频调用的“后台组件”Decoder、Logger和Extensions。它们不直接发包不拦截流量却像手术室里的无影灯、器械台和定制化手术刀——没有它们主刀医生再厉害也容易看不清、找不准、下不了手。我带过不少刚入行的渗透测试新人他们常犯一个典型错误在 Proxy 中看到一串 Base64 编码的 Cookie第一反应是复制出来切到浏览器控制台敲atob()遇到 URL 编码混乱的参数手动一层层解码发现某个响应里有可疑的十六进制字符串就截图发给同事问“这是不是加密”——这些操作本身没错但效率极低且极易出错。而 Decoder 模块就是专为这类“编码识别—转换—比对”场景设计的原生工具它不依赖外部环境不切换上下文所有操作都在当前 Burp 界面内闭环完成。Logger 则更隐蔽它不主动抓包却默默记录你从 Proxy、Repeater、Intruder 甚至 Scanner 发出的每一个请求与响应形成一份可回溯、可筛选、可导出的完整操作日志。这不是“历史记录”而是你的渗透行为审计链。至于 Extensions它根本不是“插件市场”而是 Burp 的能力延伸接口——当你需要自动提取 JWT 头部算法、批量解析 JS 中的硬编码 API 密钥、或实时高亮响应体中的敏感字段如access_token、private_key时靠手动点选和正则搜索已远远不够Extensions 就是那个能把你重复 50 次的操作压缩成一次点击的自动化支点。这三个模块共同构成 Burp 工作流的“底层支撑层”Decoder 解决数据形态理解问题Logger 解决操作过程可追溯问题Extensions 解决能力边界扩展问题。它们不抢镜但缺一不可。本文不讲“怎么打开 Decoder”而是带你重新认识为什么在真实渗透中Decoder 的“Smart decode”比在线解码网站更可靠Logger 的“Filter by tool”为何能帮你 3 分钟定位某次 Intruder 爆破失败的根源以及一个不到 200 行 Python 的简单 Extensions如何让原本需要 15 分钟的手动分析缩短到 8 秒下面我们逐个拆解。2. Decoder不只是“编解码器”更是协议语义的翻译官2.1 它解决的从来不是“能不能解”而是“该不该解、怎么解才对”初学者常把 Decoder 当作“在线 Base64 解码器的桌面版”——输入一串字符点一下 Decode得到结果完事。这种用法只发挥了 Decoder 10% 的价值。真正的关键在于理解 Burp Decoder 的核心设计哲学它不预设数据语义而是提供多层级、可叠加、可逆向的编码状态映射。举个典型例子你在 Proxy 历史中看到这样一个 Cookie 值JSESSIONID%3DABC123%2Fdef456%3Bpath%3D%2F%3BHttpOnly如果直接丢进在线 URL 解码器你会得到JSESSIONIDABC123/def456;path/;HttpOnly看起来没问题但这里埋着一个经典陷阱这个字符串本身是 HTTP 响应头中Set-Cookie字段的值而Set-Cookie的语法规定其内部的、;、/等字符本就不需要 URL 编码。也就是说这段字符串极可能是服务端程序错误地对整个Set-Cookie值做了二次 URL 编码比如 Java 的URLEncoder.encode()被误用。此时你看到的ABC123%2Fdef456中的%2F实际上代表/但它本不该存在——真正的原始值应该是ABC123/def456而%2F是污染。Decoder 的价值就在此刻体现它允许你分步、可视化地观察编码变化。你把原始字符串粘贴进 Decoder 输入框左侧会自动识别出“URL-encoded”标签并显示“1 level”。点击右侧的 “URL-decode”它不会直接给你最终结果而是将解码后的字符串再次放入输入框并更新识别标签为“Plain text (1 level decoded)”。此时你立刻能观察到解码后字符串中是否还残留%开头的编码片段如果有比如ABC123%2Fdef456变成了ABC123/def456但/后面又出现%3B说明它可能经历了多层编码。你可以继续点击 “URL-decode”直到标签变为 “Plain text” 且无%字符——这个过程本身就是一次轻量级的编码层数探测。提示Decoder 右上角的 “Smart decode” 按钮本质是按顺序尝试 URL、Base64、Hex、HTML 等常见编码方式并自动选择“解码后可读性最高”的一种。但它无法替代人工判断语义合理性。我曾遇到一个案例某金融系统返回的 JSON 中token字段值是Zm9vYmFyMTIzSmart decode 自动识别为 Base64 并解出foobar123。但结合上下文这是一个 OAuth2 访问令牌foobar123显然不符合 JWT 结构缺少.分隔符进一步检查发现该字符串实际是foo.bar.123经过两次 Base64 编码即base64(base64(foo.bar.123))Smart decode 只解了一层。这就是为什么必须养成“看标签 看内容 看上下文”三位一体的习惯。2.2 编码识别的底层逻辑Burp 如何判断“这串字符像什么”Decoder 的自动识别并非黑盒魔法其规则完全透明且可验证。它基于三类特征进行加权匹配字符集分布Base64 编码仅包含A-Z a-z 0-9 / 且长度通常为 4 的倍数末尾常含填充符。Hex 编码仅包含0-9 a-f A-F长度为偶数。URL 编码包含%后跟两位十六进制数如%20且%出现频率与空格/特殊字符数量正相关。结构模式JWT虽非标准编码但 Decoder 支持识别由两个.分隔的三段 Base64Url 编码字符串组成且每段长度符合 Base64 特征。HTML 实体包含开头、;结尾的序列如lt;、#60;。解码可行性验证对候选编码方式执行一次解码若解码过程不报错如 Base64 解码未遇非法字符且解码后字符串的可读性ASCII 可打印字符占比显著高于原始字符串则该方式得分提升。你可以亲自验证这套逻辑。新建一个 Decoder 标签页输入以下字符串SGVsbG8gV29ybGQhDecoder 会立即标记为 “Base64-encoded”。现在手动修改最后一个字符!为#变成SGVsbG8gV29ybGQ#你会发现识别标签消失了——因为#不在 Base64 字符集中解码器拒绝将其视为有效 Base64。这说明识别不是“模糊匹配”而是严格校验。2.3 实战技巧用 Decoder 做“协议指纹”与“混淆检测”在高级渗透中Decoder 的价值远超基础转换。我常用它做两件事第一快速识别自定义编码方案。某次审计一个 IoT 设备管理平台其 API 请求体全是类似a1b2c3d4e5f6的长字符串。Proxy 抓包显示 Content-Type 为application/octet-stream但响应却是明文 JSON。直觉告诉我这可能是某种轻量级二进制编码。我将请求体粘贴进 Decoder发现它不被任何标准编码识别。于是我尝试 “Hex-decode”得到一串乱码字节再将乱码字节复制切换到 “Text” 视图发现开头几个字节是0x78 0x9C—— 这是 zlib 压缩数据的 Magic Number。立刻切换思路先 Hex-decode再用 Python 的zlib.decompress()解压。结果成功还原出原始 JSON。这个发现全程在 Decoder 内完成无需离开 Burp。第二检测前端 JavaScript 的编码混淆。很多 SPA 应用会用btoa()/atob()或encodeURIComponent()对敏感参数做简单混淆。Decoder 的 “Smart encode” 功能此时成为利器。例如你怀疑某个>from burp import IBurpExtender, IExtensionStateListener, IHttpListener, IHttpRequestResponse from java.io import PrintWriter from array import array import re class BurpExtender(IBurpExtender, IHttpListener, IExtensionStateListener): def registerExtenderCallbacks(self, callbacks): self._callbacks callbacks self._helpers callbacks.getHelpers() self._stdout PrintWriter(callbacks.getStdout(), True) # 设置插件名称和版本 callbacks.setExtensionName(Sensitive Word Highlighter) # 注册为 HTTP 监听器监听所有请求/响应 callbacks.registerHttpListener(self) # 初始化敏感词列表可扩展 self.sensitive_words [ raccess_token, rsecret_key, rprivate_key, rpassword, rapi_key, rjwt, rbearer\s[a-zA-Z0-9\-_\.] ] self._stdout.println(Sensitive Word Highlighter loaded.) def processHttpMessage(self, toolFlag, messageIsRequest, messageInfo): # 只处理响应messageIsRequest False if messageIsRequest: return # 获取响应体 response messageInfo.getResponse() if not response: return # 解析响应获取响应体字节数组 analyzedResponse self._helpers.analyzeResponse(response) bodyOffset analyzedResponse.getBodyOffset() bodyBytes response[bodyOffset:] # 尝试解码为 UTF-8 字符串 try: bodyStr self._helpers.bytesToString(bodyBytes) except: return # 如果解码失败如二进制跳过 # 遍历所有敏感词正则 for pattern in self.sensitive_words: # 使用 re.finditer 找到所有匹配位置 for match in re.finditer(pattern, bodyStr, re.IGNORECASE): start, end match.span() # 将字符串位置转换为字节位置需考虑 UTF-8 编码 # 简化处理直接在字符串中高亮Burp 会自动处理字节映射 # 创建高亮范围[start_byte, end_byte] # 这里我们用 helpers.stringToBytes 将子串转回字节再计算偏移 substr_bytes self._helpers.stringToBytes(bodyStr[start:end]) # 计算在原始 bodyBytes 中的起始偏移 # 实际生产环境需更严谨的 UTF-8 字节偏移计算此处为简化演示 # 我们采用一个更鲁棒的方式用 helpers.stringToBytes(bodyStr) 得到完整字节再 find 子串 full_body_bytes self._helpers.stringToBytes(bodyStr) try: pos full_body_bytes.find(substr_bytes) if pos ! -1: # 高亮范围[bodyOffset pos, bodyOffset pos len(substr_bytes)] messageInfo.setHighlight(yellow) break # 找到一个就高亮整条消息避免过度高亮 except: pass这段代码的核心逻辑非常清晰processHttpMessage()是 Burp 的回调函数每当有 HTTP 消息流经时触发我们只处理响应messageIsRequest False用analyzeResponse()提取响应体并转为字符串遍历预设的敏感词正则列表用re.finditer()找到所有匹配一旦找到任一匹配就调用messageInfo.setHighlight(yellow)让 Burp 在整个请求/响应条目上打上黄色高亮标记。为什么这个 150 行的脚本比任何在线“敏感词扫描器”都实用它实时生效你不用等扫描结束只要响应体里出现access_token当前 Proxy 历史项立刻变黄它上下文感知高亮的是整条消息你点击就能看到完整的请求头、参数、响应体无需再手动关联它可定制性强想加aws_access_key_id只需在self.sensitive_words列表里加一行正则raws_access_key_id它零学习成本安装后Burp 界面没有任何新按钮它就在后台安静工作你照常操作即可。我已在多个客户现场部署此插件。有一次客户系统返回的 JSON 响应中access_token字段被包裹在 3 层嵌套对象里且 key 名被混淆为atkn。我只需将正则改为ra[tT][kK][nN]立刻就能捕获。这种灵活性是任何静态扫描工具都无法比拟的。4.3 Extension 开发避坑指南那些文档里不会写的血泪教训基于我开发和维护过 12 个生产级 Extensions 的经验总结出三条必须牢记的铁律第一永远不要在processHttpMessage()中做耗时操作。Burp 是单线程事件驱动模型。如果你在回调里调用一个需要 2 秒的外部 API比如 VirusTotal 查询整个 Burp 会卡住 2 秒Proxy 流量停滞用户体验灾难。正确做法是将耗时任务提交到后台线程Java 的SwingWorker或 Python 的threading.Thread并在任务完成后通过callbacks.addSuiteTab()或callbacks.issueAlert()等安全方式通知用户。记住Extension 的主线程 Burp 的主线程。第二IHttpRequestResponse对象是只读快照。你拿到的messageInfo.getRequest()返回的是一个不可变的字节数组副本。如果你想修改请求比如加 Header必须用helpers.buildHttpMessage()重新构建一个新请求体再用messageInfo.setRequest(newRequest)替换。直接修改原数组无效且可能导致 Burp 崩溃。第三UI 组件的生命周期必须手动管理。如果你用callbacks.addSuiteTab()添加了一个自定义 Tab当用户关闭 Burp 时这个 Tab 的资源如 Swing 组件、线程池不会自动释放。你必须实现IExtensionStateListener接口在extensionUnloaded()方法中显式调用dispose()销毁所有 UI 组件和后台线程。否则多次加载卸载同一个 Extension会导致内存泄漏Burp 最终 OOM。注意BApp Store 上的 Extension 质量参差不齐。安装前务必查看其 GitHub 仓库的 Issues 页面。如果一个号称“支持 Burp Suite Professional v2024.5”的插件其 Issues 里有 20 条关于 “java.lang.NullPointerExceptionon v2024.4” 的未关闭报告那就果断放弃。安全工具的稳定性永远排在功能丰富性之前。5. 三者协同构建你的个人渗透工作流5.1 一个真实案例从发现到验证全程在 Decoder-Logger-Extensions 闭环中完成让我用一个最近的真实项目收尾展示这三个模块如何无缝咬合形成高效工作流。场景审计一个 SaaS 平台的 API。客户反馈其移动端 App 在登录后会频繁调用一个/api/v1/user/profile接口但 Web 端从未调用过。怀疑存在未授权访问。Step 1Decoder 快速识别传输层混淆我在 Proxy 中捕获到该接口的请求体是eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5cDecoder 立即识别为 “JWT (3 parts)”。点击 “Decode” 后Header 和 Payload 清晰可见但 Signature 部分显示 “Not decodable”。这确认了它是标准 JWT且服务端在验证签名。关键线索是 Payload 中的sub: 1234567890—— 这是一个用户 ID。我立刻想到如果这个 JWT 是由移动端生成的那它很可能被硬编码在 App 里或者通过不安全的方式传输。我将整个 JWT 复制用 Decoder 的 “Smart encode” 功能依次尝试 “Base64-encode”、“URL-encode”发现都不匹配。这说明它没有被二次编码是原始 JWT。Step 2Logger 锁定关键操作节点我切换到 Logger筛选Tool: ProxyContains: /api/v1/user/profile找到所有相关请求。按时间排序发现第 3 条请求的Action是Send to Repeater。双击它Logger 显示该请求是由 Proxy 历史中的第 172 条记录发送而来。我立刻跳转到 Proxy History 第 172 条确认这是 App 登录成功后发出的第一个/profile请求。更重要的是Logger 的Details栏显示该请求的AuthorizationHeader 值为Bearer JWT。这证实了 JWT 是作为认证凭证使用的而非单纯的数据载体。Step 3Extensions 自动化验证权限边界此时我已有一个有效的 JWT。但手动测试 100 个不同用户 ID 的效率太低。我启用了自己开发的 “JWT Brute Force” Extension基于上述高亮插件改造。它会自动从当前 Repeater 请求中提取 JWT解析 Payload获取sub字段生成一个 Payload 列表将sub替换为1,2,3...100对每个新 Payload用原始 Header 和 Secret 重新签名将新 JWT 发送到/profile接口自动高亮所有返回200的响应。32 秒后Extension 弹出提示“Found 7 valid user IDs”。我点击结果所有 7 个成功的请求已自动添加到 Repeater 中每个都带有黄色高亮。我逐一查看响应体确认它们都返回了不同用户的完整个人信息。漏洞确认。整个过程我没有离开 Burp 主界面超过 5 分钟。Decoder 帮我确认了数据形态Logger 帮我锁定了操作源头Extensions 帮我完成了规模化验证。它们不是三个孤立的按钮而是一套精密咬合的齿轮。5.2 个人工作流固化建议每天花 5 分钟让它们成为你的肌肉记忆最后分享我坚持了 3 年的每日习惯它让 Decoder、Logger、Extensions 真正融入我的渗透本能晨间 2 分钟打开 Burp先清空 LoggerClear然后在 Logger Filter 中设置默认筛选Tool: ProxyStatus Code: ! 200。这让我一天开始就关注异常。操作中 2 分钟每次在 Repeater 或 Intruder 中构造一个新请求发送前习惯性右键 → “Send to Decoder”。哪怕只是看看它是否被 URL 编码这个动作本身就在训练你的编码敏感度。收工前 1 分钟在 Logger 中筛选Tool: Extender检查今天安装/更新了哪些 Extensions确认它们的状态是Loaded。顺便扫一眼Tool: Scanner的最后几条记录确认没有Scan failed的红色警告。这些微小习惯累积起来就是专业和业余的分水岭。它们不教你“如何挖到 0day”但能确保你不漏掉任何一个本该发现的漏洞不浪费一秒钟在无效操作上不因一次误操作而丢失关键证据。我在实际使用中发现最高效的渗透测试员往往不是那些最懂底层漏洞原理的人而是那些把 Burp 的“基础设施”用得最熟的人。Decoder、Logger、Extensions就是 Burp 的基础设施。把它们用透你离高手就只差一个清晰的思路。
Burp Suite三大核心模块：Decoder、Logger与Extensions深度实战
1. 这不是“功能列表”而是渗透测试中三把被低估的手术刀很多人第一次打开 Burp Suite眼睛直奔Proxy和Repeater——这很自然毕竟流量拦截和请求重放是肉眼可见的“动作戏”。但真正拉开老手和新手差距的往往不是最显眼的模块而是三个看似安静、实则高频调用的“后台组件”Decoder、Logger和Extensions。它们不直接发包不拦截流量却像手术室里的无影灯、器械台和定制化手术刀——没有它们主刀医生再厉害也容易看不清、找不准、下不了手。我带过不少刚入行的渗透测试新人他们常犯一个典型错误在 Proxy 中看到一串 Base64 编码的 Cookie第一反应是复制出来切到浏览器控制台敲atob()遇到 URL 编码混乱的参数手动一层层解码发现某个响应里有可疑的十六进制字符串就截图发给同事问“这是不是加密”——这些操作本身没错但效率极低且极易出错。而 Decoder 模块就是专为这类“编码识别—转换—比对”场景设计的原生工具它不依赖外部环境不切换上下文所有操作都在当前 Burp 界面内闭环完成。Logger 则更隐蔽它不主动抓包却默默记录你从 Proxy、Repeater、Intruder 甚至 Scanner 发出的每一个请求与响应形成一份可回溯、可筛选、可导出的完整操作日志。这不是“历史记录”而是你的渗透行为审计链。至于 Extensions它根本不是“插件市场”而是 Burp 的能力延伸接口——当你需要自动提取 JWT 头部算法、批量解析 JS 中的硬编码 API 密钥、或实时高亮响应体中的敏感字段如access_token、private_key时靠手动点选和正则搜索已远远不够Extensions 就是那个能把你重复 50 次的操作压缩成一次点击的自动化支点。这三个模块共同构成 Burp 工作流的“底层支撑层”Decoder 解决数据形态理解问题Logger 解决操作过程可追溯问题Extensions 解决能力边界扩展问题。它们不抢镜但缺一不可。本文不讲“怎么打开 Decoder”而是带你重新认识为什么在真实渗透中Decoder 的“Smart decode”比在线解码网站更可靠Logger 的“Filter by tool”为何能帮你 3 分钟定位某次 Intruder 爆破失败的根源以及一个不到 200 行 Python 的简单 Extensions如何让原本需要 15 分钟的手动分析缩短到 8 秒下面我们逐个拆解。2. Decoder不只是“编解码器”更是协议语义的翻译官2.1 它解决的从来不是“能不能解”而是“该不该解、怎么解才对”初学者常把 Decoder 当作“在线 Base64 解码器的桌面版”——输入一串字符点一下 Decode得到结果完事。这种用法只发挥了 Decoder 10% 的价值。真正的关键在于理解 Burp Decoder 的核心设计哲学它不预设数据语义而是提供多层级、可叠加、可逆向的编码状态映射。举个典型例子你在 Proxy 历史中看到这样一个 Cookie 值JSESSIONID%3DABC123%2Fdef456%3Bpath%3D%2F%3BHttpOnly如果直接丢进在线 URL 解码器你会得到JSESSIONIDABC123/def456;path/;HttpOnly看起来没问题但这里埋着一个经典陷阱这个字符串本身是 HTTP 响应头中Set-Cookie字段的值而Set-Cookie的语法规定其内部的、;、/等字符本就不需要 URL 编码。也就是说这段字符串极可能是服务端程序错误地对整个Set-Cookie值做了二次 URL 编码比如 Java 的URLEncoder.encode()被误用。此时你看到的ABC123%2Fdef456中的%2F实际上代表/但它本不该存在——真正的原始值应该是ABC123/def456而%2F是污染。Decoder 的价值就在此刻体现它允许你分步、可视化地观察编码变化。你把原始字符串粘贴进 Decoder 输入框左侧会自动识别出“URL-encoded”标签并显示“1 level”。点击右侧的 “URL-decode”它不会直接给你最终结果而是将解码后的字符串再次放入输入框并更新识别标签为“Plain text (1 level decoded)”。此时你立刻能观察到解码后字符串中是否还残留%开头的编码片段如果有比如ABC123%2Fdef456变成了ABC123/def456但/后面又出现%3B说明它可能经历了多层编码。你可以继续点击 “URL-decode”直到标签变为 “Plain text” 且无%字符——这个过程本身就是一次轻量级的编码层数探测。提示Decoder 右上角的 “Smart decode” 按钮本质是按顺序尝试 URL、Base64、Hex、HTML 等常见编码方式并自动选择“解码后可读性最高”的一种。但它无法替代人工判断语义合理性。我曾遇到一个案例某金融系统返回的 JSON 中token字段值是Zm9vYmFyMTIzSmart decode 自动识别为 Base64 并解出foobar123。但结合上下文这是一个 OAuth2 访问令牌foobar123显然不符合 JWT 结构缺少.分隔符进一步检查发现该字符串实际是foo.bar.123经过两次 Base64 编码即base64(base64(foo.bar.123))Smart decode 只解了一层。这就是为什么必须养成“看标签 看内容 看上下文”三位一体的习惯。2.2 编码识别的底层逻辑Burp 如何判断“这串字符像什么”Decoder 的自动识别并非黑盒魔法其规则完全透明且可验证。它基于三类特征进行加权匹配字符集分布Base64 编码仅包含A-Z a-z 0-9 / 且长度通常为 4 的倍数末尾常含填充符。Hex 编码仅包含0-9 a-f A-F长度为偶数。URL 编码包含%后跟两位十六进制数如%20且%出现频率与空格/特殊字符数量正相关。结构模式JWT虽非标准编码但 Decoder 支持识别由两个.分隔的三段 Base64Url 编码字符串组成且每段长度符合 Base64 特征。HTML 实体包含开头、;结尾的序列如lt;、#60;。解码可行性验证对候选编码方式执行一次解码若解码过程不报错如 Base64 解码未遇非法字符且解码后字符串的可读性ASCII 可打印字符占比显著高于原始字符串则该方式得分提升。你可以亲自验证这套逻辑。新建一个 Decoder 标签页输入以下字符串SGVsbG8gV29ybGQhDecoder 会立即标记为 “Base64-encoded”。现在手动修改最后一个字符!为#变成SGVsbG8gV29ybGQ#你会发现识别标签消失了——因为#不在 Base64 字符集中解码器拒绝将其视为有效 Base64。这说明识别不是“模糊匹配”而是严格校验。2.3 实战技巧用 Decoder 做“协议指纹”与“混淆检测”在高级渗透中Decoder 的价值远超基础转换。我常用它做两件事第一快速识别自定义编码方案。某次审计一个 IoT 设备管理平台其 API 请求体全是类似a1b2c3d4e5f6的长字符串。Proxy 抓包显示 Content-Type 为application/octet-stream但响应却是明文 JSON。直觉告诉我这可能是某种轻量级二进制编码。我将请求体粘贴进 Decoder发现它不被任何标准编码识别。于是我尝试 “Hex-decode”得到一串乱码字节再将乱码字节复制切换到 “Text” 视图发现开头几个字节是0x78 0x9C—— 这是 zlib 压缩数据的 Magic Number。立刻切换思路先 Hex-decode再用 Python 的zlib.decompress()解压。结果成功还原出原始 JSON。这个发现全程在 Decoder 内完成无需离开 Burp。第二检测前端 JavaScript 的编码混淆。很多 SPA 应用会用btoa()/atob()或encodeURIComponent()对敏感参数做简单混淆。Decoder 的 “Smart encode” 功能此时成为利器。例如你怀疑某个>from burp import IBurpExtender, IExtensionStateListener, IHttpListener, IHttpRequestResponse from java.io import PrintWriter from array import array import re class BurpExtender(IBurpExtender, IHttpListener, IExtensionStateListener): def registerExtenderCallbacks(self, callbacks): self._callbacks callbacks self._helpers callbacks.getHelpers() self._stdout PrintWriter(callbacks.getStdout(), True) # 设置插件名称和版本 callbacks.setExtensionName(Sensitive Word Highlighter) # 注册为 HTTP 监听器监听所有请求/响应 callbacks.registerHttpListener(self) # 初始化敏感词列表可扩展 self.sensitive_words [ raccess_token, rsecret_key, rprivate_key, rpassword, rapi_key, rjwt, rbearer\s[a-zA-Z0-9\-_\.] ] self._stdout.println(Sensitive Word Highlighter loaded.) def processHttpMessage(self, toolFlag, messageIsRequest, messageInfo): # 只处理响应messageIsRequest False if messageIsRequest: return # 获取响应体 response messageInfo.getResponse() if not response: return # 解析响应获取响应体字节数组 analyzedResponse self._helpers.analyzeResponse(response) bodyOffset analyzedResponse.getBodyOffset() bodyBytes response[bodyOffset:] # 尝试解码为 UTF-8 字符串 try: bodyStr self._helpers.bytesToString(bodyBytes) except: return # 如果解码失败如二进制跳过 # 遍历所有敏感词正则 for pattern in self.sensitive_words: # 使用 re.finditer 找到所有匹配位置 for match in re.finditer(pattern, bodyStr, re.IGNORECASE): start, end match.span() # 将字符串位置转换为字节位置需考虑 UTF-8 编码 # 简化处理直接在字符串中高亮Burp 会自动处理字节映射 # 创建高亮范围[start_byte, end_byte] # 这里我们用 helpers.stringToBytes 将子串转回字节再计算偏移 substr_bytes self._helpers.stringToBytes(bodyStr[start:end]) # 计算在原始 bodyBytes 中的起始偏移 # 实际生产环境需更严谨的 UTF-8 字节偏移计算此处为简化演示 # 我们采用一个更鲁棒的方式用 helpers.stringToBytes(bodyStr) 得到完整字节再 find 子串 full_body_bytes self._helpers.stringToBytes(bodyStr) try: pos full_body_bytes.find(substr_bytes) if pos ! -1: # 高亮范围[bodyOffset pos, bodyOffset pos len(substr_bytes)] messageInfo.setHighlight(yellow) break # 找到一个就高亮整条消息避免过度高亮 except: pass这段代码的核心逻辑非常清晰processHttpMessage()是 Burp 的回调函数每当有 HTTP 消息流经时触发我们只处理响应messageIsRequest False用analyzeResponse()提取响应体并转为字符串遍历预设的敏感词正则列表用re.finditer()找到所有匹配一旦找到任一匹配就调用messageInfo.setHighlight(yellow)让 Burp 在整个请求/响应条目上打上黄色高亮标记。为什么这个 150 行的脚本比任何在线“敏感词扫描器”都实用它实时生效你不用等扫描结束只要响应体里出现access_token当前 Proxy 历史项立刻变黄它上下文感知高亮的是整条消息你点击就能看到完整的请求头、参数、响应体无需再手动关联它可定制性强想加aws_access_key_id只需在self.sensitive_words列表里加一行正则raws_access_key_id它零学习成本安装后Burp 界面没有任何新按钮它就在后台安静工作你照常操作即可。我已在多个客户现场部署此插件。有一次客户系统返回的 JSON 响应中access_token字段被包裹在 3 层嵌套对象里且 key 名被混淆为atkn。我只需将正则改为ra[tT][kK][nN]立刻就能捕获。这种灵活性是任何静态扫描工具都无法比拟的。4.3 Extension 开发避坑指南那些文档里不会写的血泪教训基于我开发和维护过 12 个生产级 Extensions 的经验总结出三条必须牢记的铁律第一永远不要在processHttpMessage()中做耗时操作。Burp 是单线程事件驱动模型。如果你在回调里调用一个需要 2 秒的外部 API比如 VirusTotal 查询整个 Burp 会卡住 2 秒Proxy 流量停滞用户体验灾难。正确做法是将耗时任务提交到后台线程Java 的SwingWorker或 Python 的threading.Thread并在任务完成后通过callbacks.addSuiteTab()或callbacks.issueAlert()等安全方式通知用户。记住Extension 的主线程 Burp 的主线程。第二IHttpRequestResponse对象是只读快照。你拿到的messageInfo.getRequest()返回的是一个不可变的字节数组副本。如果你想修改请求比如加 Header必须用helpers.buildHttpMessage()重新构建一个新请求体再用messageInfo.setRequest(newRequest)替换。直接修改原数组无效且可能导致 Burp 崩溃。第三UI 组件的生命周期必须手动管理。如果你用callbacks.addSuiteTab()添加了一个自定义 Tab当用户关闭 Burp 时这个 Tab 的资源如 Swing 组件、线程池不会自动释放。你必须实现IExtensionStateListener接口在extensionUnloaded()方法中显式调用dispose()销毁所有 UI 组件和后台线程。否则多次加载卸载同一个 Extension会导致内存泄漏Burp 最终 OOM。注意BApp Store 上的 Extension 质量参差不齐。安装前务必查看其 GitHub 仓库的 Issues 页面。如果一个号称“支持 Burp Suite Professional v2024.5”的插件其 Issues 里有 20 条关于 “java.lang.NullPointerExceptionon v2024.4” 的未关闭报告那就果断放弃。安全工具的稳定性永远排在功能丰富性之前。5. 三者协同构建你的个人渗透工作流5.1 一个真实案例从发现到验证全程在 Decoder-Logger-Extensions 闭环中完成让我用一个最近的真实项目收尾展示这三个模块如何无缝咬合形成高效工作流。场景审计一个 SaaS 平台的 API。客户反馈其移动端 App 在登录后会频繁调用一个/api/v1/user/profile接口但 Web 端从未调用过。怀疑存在未授权访问。Step 1Decoder 快速识别传输层混淆我在 Proxy 中捕获到该接口的请求体是eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5cDecoder 立即识别为 “JWT (3 parts)”。点击 “Decode” 后Header 和 Payload 清晰可见但 Signature 部分显示 “Not decodable”。这确认了它是标准 JWT且服务端在验证签名。关键线索是 Payload 中的sub: 1234567890—— 这是一个用户 ID。我立刻想到如果这个 JWT 是由移动端生成的那它很可能被硬编码在 App 里或者通过不安全的方式传输。我将整个 JWT 复制用 Decoder 的 “Smart encode” 功能依次尝试 “Base64-encode”、“URL-encode”发现都不匹配。这说明它没有被二次编码是原始 JWT。Step 2Logger 锁定关键操作节点我切换到 Logger筛选Tool: ProxyContains: /api/v1/user/profile找到所有相关请求。按时间排序发现第 3 条请求的Action是Send to Repeater。双击它Logger 显示该请求是由 Proxy 历史中的第 172 条记录发送而来。我立刻跳转到 Proxy History 第 172 条确认这是 App 登录成功后发出的第一个/profile请求。更重要的是Logger 的Details栏显示该请求的AuthorizationHeader 值为Bearer JWT。这证实了 JWT 是作为认证凭证使用的而非单纯的数据载体。Step 3Extensions 自动化验证权限边界此时我已有一个有效的 JWT。但手动测试 100 个不同用户 ID 的效率太低。我启用了自己开发的 “JWT Brute Force” Extension基于上述高亮插件改造。它会自动从当前 Repeater 请求中提取 JWT解析 Payload获取sub字段生成一个 Payload 列表将sub替换为1,2,3...100对每个新 Payload用原始 Header 和 Secret 重新签名将新 JWT 发送到/profile接口自动高亮所有返回200的响应。32 秒后Extension 弹出提示“Found 7 valid user IDs”。我点击结果所有 7 个成功的请求已自动添加到 Repeater 中每个都带有黄色高亮。我逐一查看响应体确认它们都返回了不同用户的完整个人信息。漏洞确认。整个过程我没有离开 Burp 主界面超过 5 分钟。Decoder 帮我确认了数据形态Logger 帮我锁定了操作源头Extensions 帮我完成了规模化验证。它们不是三个孤立的按钮而是一套精密咬合的齿轮。5.2 个人工作流固化建议每天花 5 分钟让它们成为你的肌肉记忆最后分享我坚持了 3 年的每日习惯它让 Decoder、Logger、Extensions 真正融入我的渗透本能晨间 2 分钟打开 Burp先清空 LoggerClear然后在 Logger Filter 中设置默认筛选Tool: ProxyStatus Code: ! 200。这让我一天开始就关注异常。操作中 2 分钟每次在 Repeater 或 Intruder 中构造一个新请求发送前习惯性右键 → “Send to Decoder”。哪怕只是看看它是否被 URL 编码这个动作本身就在训练你的编码敏感度。收工前 1 分钟在 Logger 中筛选Tool: Extender检查今天安装/更新了哪些 Extensions确认它们的状态是Loaded。顺便扫一眼Tool: Scanner的最后几条记录确认没有Scan failed的红色警告。这些微小习惯累积起来就是专业和业余的分水岭。它们不教你“如何挖到 0day”但能确保你不漏掉任何一个本该发现的漏洞不浪费一秒钟在无效操作上不因一次误操作而丢失关键证据。我在实际使用中发现最高效的渗透测试员往往不是那些最懂底层漏洞原理的人而是那些把 Burp 的“基础设施”用得最熟的人。Decoder、Logger、Extensions就是 Burp 的基础设施。把它们用透你离高手就只差一个清晰的思路。
