Burp Suite+Python脚本：CTF Web抓包找线索的高效流程

做CTF Web题，最怕的不是题目难，而是抓了一堆包，线索就在眼前却没认出来。Burp Suite抓包、Python脚本分析，这两样东西单拿出来大家都会，但真正把“抓包”变成“找线索”的高效流程，很多人其实没想明白。

这篇文章想聊的，不是某个具体题库的答案，而是一套可复用的解题思路：怎么用Burp Suite插件把每一次交互变成可检索的线索记录，再用Python脚本把记录里的编码、路径、参数批量提取出来并自动解码。适合刚入门CTF Web、总感觉抓包抓不到点子的选手，也适合已经会解常规题、但是效率上不去的朋友。顺着这套流程走一遍，你会发现自己不再是在“碰运气”，而是在“按图索骥”。

1. 先认清问题：为什么抓包抓了很多，却找不到线索

1.1 无效抓包的三个典型症状

很多人在CTF Web题里的抓包状态，看着热闹，其实无效。我总结了三个最常见的症状，你可以对照一下自己中了几条。

第一个症状是全程跟随重定向。Burp Suite默认会把302跳转自动跟完，于是你只看到了最终页面，中间那个302响应本身长什么样完全没看见。而Web题里出题人特别喜欢把线索放在302的响应头、Set-Cookie或者Location参数里。我见过一道题，线索就藏在登录接口302后的X-Hint头里，凡是跟着重定向走的人，全都错过了。解决办法也很简单：在Burp的Proxy Options里把“Follow Redirects”改成“Never”，所有跳转手动点，每个中间响应都不放过。

第二个症状是只看响应体，不看响应头。很多人把页面正文看了一遍又一遍，但响应头和Cookie一眼都不瞅。实际上响应头字段的自由度非常高，自定义一个X-Flag-Part、X-Debug之类的头对出题人来说太容易了。我现在的习惯是：任何响应拿到手，先扫一遍Header，把非标准的头挑出来看一遍，再回来看Body。这一个习惯，稳赚不赔。

第三个症状是抓到包之后不做复盘。抓了100个请求，但没有整理哪些接口返回过可疑字段、哪些JS被加载过、哪些响应里有编码串。等回头想找某条线索时，只能重新翻历史记录，翻到眼瞎。这个问题需要用工具解决——也就是后面要讲的Logger++和脚本化分析，靠人脑记不住这么多细节。

1.2 隐藏线索的常见藏身位置与识别思路

CTF Web题里的“隐藏线索”，形态其实是有规律的。我大致整理过一张表，平时解题基本可以对着它找：

识别线索最重要的一条原则：凡是看起来“不像正常数据”的字段，都要多看一眼。什么叫不像正常数据？一串大小写字母和数字混在一起、末尾带等号的，大概率是Base64；全是十六进制字符的，可能是Hex编码；夹在正常英文里的乱码，可能是ROT13或者某种变体。这些特征你见多了以后，几乎不用思考就能判断出来。

不过靠肉眼判断太慢了，而且容易漏。这就是我为什么坚持要把“Burp插件记录所有流量 + Python脚本批量分析”当成组合拳来用——前者保证线索不丢，后者保证线索能被快速挖出来。

2. 方案选型：用Burp Suite插件扩展你的信息获取能力

2.1 插件组合的逻辑：不是装得越多越好

Burp Suite的扩展商店里插件一大把，但真正在CTF Web题里高频使用的，其实是少数。我自己的经验是，与其装一堆插件然后挨个开关，不如按“信息获取—主动测试—定制分析”三层来搭。

第一层是信息获取，核心工具是Logger++。它解决的是“流量太多记不住”的问题。第二层是主动测试，核心工具是Turbo Intruder。它解决的是“参数名/路径需要批量爆破”的问题。第三层是定制分析，可以自己写一个Burp扩展。它解决的是“默认功能没有覆盖到的个性化需求”。

这三层对应CTF Web题里三种最典型的场景：线索藏在被动流量里、线索需要主动触发、线索形态需要定制化分析。下面逐个展开。

2.2 Logger++：把流量变成可检索的日志

Logger++是Burp扩展商店里Top级常用的插件，也是我最先推荐装的。它和Burp自带的HTTP History最大的区别在于两点：一是性能更好，流量大了之后不会卡到怀疑人生；二是过滤规则强大，你可以用正则控制哪些请求记录、哪些不记录，还能给特定关键词加高亮。

安装方式不复杂：在Burp里打开Extender标签页，点击BApp Store，搜索Logger++，点击安装即可。装完之后，我一般会先做两步配置。

第一步，过滤静态资源。默认日志会记录所有流量，图片、CSS、JS这些会占大量位置。在Logger++的Settings里找到Filter设置，加一条排除正则：

^(?!.*\.(js|css|png|jpg|svg|woff2?)(\?|$)).*

意思是不记录以这些静态资源后缀结尾的请求。但要注意，JS文件本身经常藏线索，所以我会把js从排除列表里去掉，只排除图片和样式表。如果你担心遗漏，可以不做过滤，而是用下方的关键词高亮。

第二步，配置高亮关键词。在Settings的高亮规则里加上：

(?i)(flag|secret|token|hint|admin|debug)

这条正则会让所有URL或响应中包含这些关键词的请求自动标红。这样一打开Logger++面板，红色条目就是你最该看的东西。

Logger++还有一个隐藏优势：它支持直接把搜索结果导出。你可以把所有过滤后的请求导出成文件，后续交给Python脚本做二次分析。这个工作流是Burp自带History给不了的，也是后面脚本三存在的前提。

2.3 Turbo Intruder：用代码做高速Fuzz

Turbo Intruder是Burp官方维护的一个高速Fuzz插件，脚本驱动，能同时开几十甚至上百个连接去爆破参数、路径、Header值，速度比自带的Intruder快一个量级。它在CTF题里最常用的场景是猜参数名、猜路径、或者批量提交候选值。

安装方法和Logger++一样，在BApp Store里搜索Turbo Intruder安装即可。使用的时候不是点界面，而是写Python脚本。下面这个脚本可以用来批量测试一组参数名：

def queueRequests(target, wordlists): engine = RequestEngine(endpoint=target.endpoint, concurrentConnections=10) for word in open('params.txt'): engine.queue(target.req, word.rstrip()) def handleResponse(req, word): if 'flag' in req.response.lower() or req.code != 404: print(f"发现响应异常: {req.code} 参数={word}") print(req.response[:500])

把params.txt换成你自己准备的参数名列表，比如admin、debug、action、cmd、file之类。运行时，脚本会并发发起大量请求，只要响应码不是404或者响应体里出现flag字样，就会在控制台打印出来。这个思路特别适合题目接口多、参数不明的情况。

提示：Turbo Intruder的并发数不要一上来就开到几百，先跑50左右观察一下目标反应。CTF靶场一般扛得住几十并发，但有些环境比较脆弱，把靶场打崩了反而没法做题。

2.4 自定义Burp扩展：给Burp写一个CTF小助手

插件商店里没有完全合适的扩展时，可以自己写一个。Burp支持编写扩展，官方接口用的是Java，但如果不想碰Java，可以基于Jython用Python来写。Jython不是纯Python环境，但它支持调用Burp的API，而且你把逻辑写成纯Python串进去也能跑。

下面是一个简单的HTTP监听器扩展，它在每次收到响应时自动打印包含关键词的响应片段。这个扩展的作用相当于把Logger++的“高亮”变成“主动弹提示”，适合流量不大、希望时刻盯着的场景。

from burp import IBurpExtender, IHttpListener class BurpExtender(IBurpExtender, IHttpListener): def registerExtenderCallbacks(self, callbacks): self._callbacks = callbacks self._helpers = callbacks.getHelpers() callbacks.setExtensionName("CTF-Line-Finder") callbacks.registerHttpListener(self) print("[+] CTF-Line-Finder 扩展已加载") def processHttpMessage(self, toolFlag, messageIsRequest, messageInfo): if messageIsRequest: return response = messageInfo.getResponse() if response is None: return analyzed = self._helpers.analyzeResponse(response) body_offset = analyzed.getBodyOffset() body_bytes = response[body_offset:] body_text = self._helpers.bytesToString(body_bytes) keywords = ("flag", "hint", "secret", "admin", "token") for kw in keywords: if kw in body_text.lower(): url = self._helpers.analyzeRequest(messageInfo).getUrl() print(f"[线索] {url} 包含关键词 \"{kw}\"") snippet = body_text[:300] print(snippet) break

写完保存成.py文件，在Burp的Extender里点击Add，选择Extension Type为Python，选中这个文件即可加载。加载后你在Burp里做的任何代理请求，只要响应体里包含关键词，控制台就会自动打印URL和响应片段。这个思路的精髓在于：你不是在“看”每一个请求，而是让Burp帮你盯着。

3. Python脚本：把重复劳动交给代码

3.1 脚本要解决的三类重复劳动

插件负责记录和标记，但真正“动手挖”的活儿，Python脚本更在行。我总结下来，脚本要替代的主要是三类重复劳动。

第一类是手工提取。响应里有一堆疑似Base64的字符串，你一个个复制到在线工具解码，手酸且容易错。第二类是手工判断编码。看到一个字符串不知道是什么编码，挨个试URL、Base64、Hex、ROT13，试了半天。第三类是手工翻历史记录。Burp导出或抓包日志里找线索，一页一页翻到眼瞎。下面这三个脚本，分别对应解决这三类问题。

3.2 脚本一：响应内容线索扫描器

这个脚本用来扫描一个URL（或者HTML页面、JS文件），把注释、字符串常量、自定义响应头提取出来。它做的就是“人工肉眼扫页面”这件事，但速度和完整性都比人肉强。

import requests import re import urllib3 urllib3.disable_warnings() def looks_like_code(s): if len(s) < 8: return False if not re.search(r'\d', s): return False if re.search(r'[a-zA-Z0-9+/=]{16,}', s): return True return False def scan_html(url): resp = requests.get(url, verify=False, timeout=10) resp.encoding = resp.apparent_encoding text = resp.text comments = re.findall(r'<!--(.*?)-->', text, re.S) for c in comments: print(f"[HTML注释] {c.strip()}") scripts = re.findall(r'<script[^>]*>(.*?)</script>', text, re.S) for script in scripts: for s in re.findall(r'"[^"]+"|\'[^\']+\'', script): s = s.strip('"\'') if looks_like_code(s): print(f"[JS字符串] {s}") for h, v in resp.headers.items(): if h.lower() not in ('server', 'date', 'content-type', 'content-length', 'connection', 'keep-alive'): print(f"[自定义头] {h}: {v}") def scan_js(url): resp = requests.get(url, verify=False, timeout=10) text = resp.text for s in re.findall(r'"[^"]+"|\'[^\']+\'', text): s = s.strip('"\'') if looks_like_code(s): print(f"[JS字符串] {s}") if __name__ == '__main__': target = input("请输入URL: ").strip() if target.endswith('.js'): scan_js(target) else: scan_html(target)

用法很简单：python3 scan.py，输入URL。脚本会自动判断输入的是HTML还是JS，然后分别处理。looks_like_code里我故意做了一个保守的判断：字符串长度大于8、包含数字、全是字母数字和+/=。这个判断在CTF题里命中率很高，因为正常页面上的字符串很少长成这副模样。

你可以根据自己的需求调整关键词和正则，比如觉得Base64串长度不够，就把len(s) < 8改成len(s) < 16。

3.3 脚本二：编码自动识别与递归解码器

这个脚本解决“看到一个字符串不知道是什么编码”的问题。我的思路是：把URL解码、Base64解码、Hex解码、ROT13解码这四种最常见的CTF编码轮番试一遍，如果有解码结果，就对解码结果继续递归尝试，直到不能再解为止。

import base64 import re import urllib.parse def decode_once(text): results = [] text = text.strip() try: decoded = urllib.parse.unquote(text) if decoded != text: results.append(("URL", decoded)) except Exception: pass try: padded = text + "=" * (-len(text) % 4) decoded = base64.b64decode(padded).decode("utf-8", errors="ignore") if decoded and len(decoded) > 2: results.append(("Base64", decoded)) except Exception: pass try: decoded = bytes.fromhex(text).decode("utf-8", errors="ignore") if decoded and len(decoded) > 2: results.append(("Hex", decoded)) except Exception: pass decoded = text.translate(str.maketrans( "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ", "nopqrstuvwxyzabcdefghijklmNOPQRSTUVWXYZABCDEFGHIJKLM" )) if decoded != text: results.append(("ROT13", decoded)) return results def recursive_decode(text, depth=0): if depth > 5: return results = decode_once(text) if not results: return for name, decoded in results: print(" " * depth + f"发现[{name}]: {decoded}") recursive_decode(decoded, depth + 1) if __name__ == "__main__": raw = input("请输入待解码字符串: ").strip() recursive_decode(raw)

这里有一个细节值得说：Base64解码前，我先把字符串用=补齐到4的倍数。因为有些出题人会去掉Base64末尾的等号，直接解码就会报错。这一行补齐逻辑，在实战里救过我很多次。Hex解码失败时会被except捕获，所以不用担心中途报错中断。

运行效果大概是这样的：

请输入待解码字符串: NjE2NjM3 发现[Base64]: 616637 发现[Hex]: aaf7

一轮接一轮，解码链完整呈现。如果解出来还是乱码，你就该考虑别的方向，比如可能是两次Base64，或者夹杂了反向字符串、凯撒移位等变体。

3.4 脚本三：Burp导出记录的二次分析

第三个脚本解决“Burp历史记录太多、翻不过来”的问题。Logger++可以把请求导出成文件，我们把导出的文件交给脚本，脚本自动过滤静态资源、扫描包含关键词的URL和响应内容，把可疑请求列出来。

import json import re import sys def analyze_export(filepath): with open(filepath, "r", encoding="utf-8") as f: data = json.load(f) items = data if isinstance(data, list) else data.get("items", []) print(f"[+] 共{len(items)}条记录") keyword = re.compile(r"(flag|hint|secret|debug|admin|token|api)", re.I) exclude = re.compile(r"\.(css|png|jpg|svg|woff2?)(\?|$)", re.I) for item in items: url = item.get("url", "") method = item.get("method", "GET") status = item.get("status", 0) response = item.get("response", "") if exclude.search(url): continue if keyword.search(url) or keyword.search(response): print(f"[发现] {method} {status} {url}") for m in keyword.finditer(response): start = max(0, m.start() - 40) end = min(len(response), m.end() + 40) print(f" ...{response[start:end]}...".replace("\n", " "))

这个脚本假设你导出的格式是JSON数组，每个元素有url、method、status、response字段。不同版本Burp的导出格式可能有差异，但核心思路是一样的：正则过滤、关键词命中、上下文打印。你只需要把字段名改成你实际导出的字段即可。

用上这三个脚本之后，你大概会有一个感觉：以前需要盯着屏幕反复试的操作，现在几秒钟就能出结果，而且不会漏。

4. 实战拆解：从抓包到锁定flag的完整链路

4.1 一道路线清晰的模拟Web题

光讲工具和脚本还不够，最好跟着一条完整的题走一遍。我在这里虚构一个“模拟项目X”：某个靶场环境提供了一道“在线笔记系统”的Web题，页面上可以注册、登录、创建笔记并查看。目标是读取系统管理员的隐藏笔记。

出题人的意图很典型：正常功能都不藏flag，线索分散在响应头、源码注释和JS文件里，需要你把它们串起来。为了方便说明，我直接给出这条链路的设计，你在实际做题时也可以按这个模式倒推：

1. 首页源码注释暴露了配置接口/api/cfg
2. /api/cfg返回的自定义响应头X-Hint里有一段Base64，解码后是debug=1
3. 访问带?debug=1的页面，JSON里多出一个字段js_path，指向static/js/api.js
4. api.js里藏着两个关键信息：一个Hex编码字符串和一个硬编码的X-Auth头值
5. Hex解码后得到一个接口路径/api/note/read?id=admin，加上X-Auth头后返回flag

下面按三个阶段来走完这个过程。

4.2 第一阶段：Burp先把流量“录”下来

打开Burp，配置好浏览器代理，先进入靶场环境正常注册一个账号、登录、创建一条笔记。这些操作产生的所有流量都会进入Logger++。

注意，这一阶段我建议你先不要管Burp自带的HTTP History，而是直接看Logger++面板。你先在Logger++的高亮规则里加上X-Hint|api|debug|js_path这几个关键词，然后再把所有红色条目浏览一遍。

浏览首页时，你会看到第一个红色条目。点开响应体，发现HTML源码的注释里写着：

<!-- 配置接口: /api/cfg -->

这就是最典型的注释型线索。正常功能页面根本没必要写这种注释，出题人放这里是故意的。你跟着这个线索，在Repeater里访问/api/cfg，响应如下：

{"status": "ok", "debug": false}

响应体看起来平平无奇。但如果你此刻扫一眼响应头，就能看到：

X-Hint: ZGVidWc9MQ==

ZGVidWc9MQ==这串字符末尾带等号，典型Base64特征。你可以手动复制到终端里跑脚本二，也可以先不急着解，继续把后面的步骤走完再一并处理。我建议遇到编码串立即解码，因为后面线索可能依赖这个结果。

脚本二输出：

输入: ZGVidWc9MQ== 发现[Base64]: debug=1

得到debug=1。这就是一个参数开关。回到浏览器，访问/api/cfg?debug=1，响应多出字段：

{"status": "ok", "debug": true, "js_path": "static/js/api.js"}

注意这个js_path字段。正常接口不会暴露脚本路径，这个就是下一站线索。

4.3 第二阶段：Python脚本批量提取与解码

现在把目标指向static/js/api.js。你可以直接在Burp里访问这个文件，或者用脚本一扫描它。这里我强烈建议直接用脚本一：

请输入URL: http://target/static/js/api.js

脚本输出一堆JS字符串，其中有两行明显异常：

[JS字符串] 68696464656e5f6e6f74655f617069 [JS字符串] x-auth: 8f14e45fceea167a5a36dedd4bea2543

第一行是一串十六进制字符，第二行是一个请求头名和一个MD5值。把第一行扔进脚本二：

输入: 68696464656e5f6e6f74655f617069 发现[Hex]: hidden_note_api

这串Hex解码出来是hidden_note_api。结合上下文，你大概能猜到接口是/api/note/hidden或者类似的东西。但你不知道具体参数名，也不知道那个x-auth值跟哪个接口配套。

这里就要用到Turbo Intruder或者脚本三的批量测试思路了。先把可能接口路径整理成字典：

/api/note/hidden /api/hidden/note /api/note/read /api/note/read?id=admin

用Turbo Intruder逐个请求，同时观察响应。当请求/api/note/read?id=admin时，响应返回了{"message": "需要X-Auth头"}。这说明接口找到了，参数id=admin也对，只差认证头。

4.4 第三阶段：组合Burp与脚本完成关键提交

现在你已经有了接口和参数，还差那个X-Auth头。回到脚本一扫描JS时输出的第二行：

x-auth: 8f14e45fceea167a5a36dedd4bea2543

注意这里有个细节：这段字符串是以x-auth:开头，后面跟着一个MD5值。出题人把请求头名和值放在同一个字符串里，而且用了小写。你在Burp Repeater里构造请求时，要把它写成标准的请求头格式：

GET /api/note/read?id=admin HTTP/1.1 Host: target X-Auth: 8f14e45fceea167a5a36dedd4bea2543

提交以后，响应返回：

{"flag": "flag{fake_flag_for_demo_2024}"}

至此，通过“响应头线索—注释线索—JS扫描—多级解码—请求头构造”这条链路，拿到了flag。

整个过程看起来步骤多，但每一步的判定都非常明确：遇到编码串就解码，遇到异常字段就顺着访问，遇到JS文件就用脚本扫描关键词。如果你全程手动操作，光是把那串Hex解码出来、再人工比对各种可能的路径参数，可能就要花掉大半个小时。

4.5 效率对照：传统手翻 vs 这套组合拳

我把同一条题用两种方式走了一遍，简单做了个对照：

这个对照其实是给日常工作流定了个标准：所有能交给脚本的环节，绝不用手重复；所有能自动记录的信息，绝不在脑子里临时记。这套思路同样适用于CTF之外的安全测试和漏洞挖掘场景，一旦形成习惯，你的效率会明显不一样。

5. 常见问题与排查技巧实录

5.1 为什么Burp抓不到本机浏览器的HTTPS流量

这是新手最常见的问题。Burp需要配置系统代理，还需要安装Burp的CA证书到系统信任列表。证书没装对的情况下，HTTPS站点要么直接报证书错误，要么流量里全是加密数据，Burp面板上什么都看不到。要记得在设置里找到Certificates相关页面，导出CA证书，再安装到系统或浏览器信任区域。装完之后重新打开浏览器，HTTPS流量就能正常被截获和解密。

5.2 Logger++有记录但看不到请求内容

如果你看到Logger++面板有条目，但点开之后请求和响应内容都是空的，多半是过滤器把内容过滤掉了。Logger++的Filter里如果勾选了“Only store metadata”之类的选项，就不会保存完整的内容，只保留URL、状态码这些元信息。CTF场景建议关闭这个选项，让每个请求保留完整请求/响应体，否则后面脚本三无法分析。

5.3 Python脚本报错与证书问题

我在脚本里默认加了verify=False并关闭了SSL告警，但你自己写脚本时如果不加，访问HTTPS靶场大概率会抛SSL: CERTIFICATE_VERIFY_FAILED。解决方法是请求时带上verify=False参数，同时开头调用urllib3.disable_warnings()把告警关掉，不然控制台会刷一堆黄字，看着烦。

另外，如果靶场环境需要登录Cookie，脚本里要带上Cookie头或者用requests.Session()保存会话。这个细节很容易漏，但漏了的话脚本扫描到的是一个未登录页面，什么都提不出来。

5.4 大量历史记录中如何快速定位可疑请求

很多人翻Burp History是从上往下一条条看，这是效率最低的方式。正确做法是先过滤，再导出，再跑脚本。具体来说：先在Logger++里用正则过滤掉静态资源，再按关键词高亮，把所有红色条目导出成文件，最后用脚本三做关键词上下文打印。整个过程五分钟以内能完成，而且不会因为翻漏而遗漏关键线索。

5.5 自定义Burp扩展调试时的几个坑

自己写扩展时最容易踩坑的是Jython版本问题。Jython对Python 3的语法支持不完整，字符串处理和CPython也有差异。我的建议是：扩展只做轻量逻辑，比如关键词检测、打印提示，复杂的数据处理全部交给外部Python脚本。扩展负责“发现”，脚本负责“深挖”，这样两边都省心。

调试扩展时，在代码里加print输出，然后看Burp的Extender消息面板，输出都会显示在那里。如果你改了代码，需要重新加载扩展文件，Burp不会自动热更，这点要留意。

我个人在实际操作中最深刻的体会是：真正让你在CTF Web题里脱颖而出的，不是多高深的技巧，而是你愿不愿意把“找线索”这件事标准化。Burp插件帮你把流量变成可检索的数据，Python脚本帮你把数据变成可操作的结论，而你只需要负责串起这条链路。下次拿到一道新题，别急着盲目抓包，先在脑子里过一遍这套流程：哪些流量要录、哪些编码要解、哪些文件要扫、哪些参数要爆。按着步骤来，你会发现自己离flag越来越近。

最后分享一个小习惯：每次解题过程中只要发现新的线索形态，我就往自己的脚本里加一条正则或者解码规则。积累几个月之后，这些脚本就变成了我的CTF武器库，碰到类似的题几乎都是几分钟出答案。希望这篇文章能给用自己的武器库开个头。