企业官网建设流程全解析

BurpSuite 是 Web 应用安全测试中使用频率最高的抓包与请求分析工具。很多第一次接触漏洞挖掘的同学，最先遇到的不是漏洞本身，而是“抓包工具装好了，但浏览器请求根本走不到 Burp 里”或“HTTPS 页面全变成证书错误”。这些问题与工具好不好用无关，而与代理链、证书信任、客户端版本限制这三层机制有关。下面的内容会从 BurpSuite 的下载安装、代理抓包、HTTPS 证书导入、Repeater 改包、Intruder 参数枚举，再到授权漏洞挖掘的完整路径，逐步讲清楚每一步背后的原理和常见报错，帮你在最短时间内建立一套可复现的抓包与测试流程。

1. 先理解 BurpSuite 的工作原理，再决定怎么抓包

1.1 BurpSuite 本质是一个 HTTP 代理

通俗地说，BurpSuite 站在浏览器和目标服务器之间，替两边传递数据。浏览器不直接访问目标服务器，而是把请求先交给 BurpSuite，由 BurpSuite 转发出去；目标服务器返回响应时，也先回到 BurpSuite，再交给浏览器。

技术上的定义更明确：BurpSuite 是一个带图形界面的 HTTP 中间人代理。它启动后默认监听本机127.0.0.1:8080，当你把浏览器或手机 App 的代理地址指向这个地址时，HTTP 和 HTTPS 流量就会经过它。因为请求和响应都要经过这个中间节点，BurpSuite 才能看到请求头、请求体、响应内容，也才能在请求发出之前修改参数。

这里有个常见误解：有人以为 BurpSuite 像 Wireshark 一样，把网卡上的数据包直接“抓”下来。实际上 BurpSuite 不会主动截获网卡流量，它只处理客户端主动代理给它的流量。如果浏览器没有配置代理，BurpSuite 什么都看不到。理解这一点，后面排查“为什么抓不到包”就会容易很多。

1.2 工具选型：BurpSuite 与 Fiddler、Charles、Yakit 的定位差异

经常有初学者问：Fiddler、Charles、BurpSuite、Yakit 到底选哪个。这几种工具的底层思路很像，都是代理抓包，但定位不同。

实际项目里，没必要死守一个工具。抓包调试可能用 Charles 顺手，漏洞挖掘和请求改包通常围绕 BurpSuite 展开。如果你要做 Web 漏洞挖掘、SRC 测试、学习 OWASP 漏洞原理，优先把 BurpSuite 掌握扎实，其他工具按场景补充。

2. 安装与启动：版本选择、Java 环境和官方下载

2.1 社区版、专业版与企业版怎么选

BurpSuite 官网提供三个版本：社区版、专业版、企业版。它们定位不同，能力差异也很大。

需要注意，社区版的功能足够覆盖入门到进阶的大部分学习场景，但它有一些限制，比如 Intruder 只能使用较慢的算法，部分扫描器功能无法使用。对初学者来说，先用社区版把抓包、改包、重放、枚举的流程跑通，比一开始就追求付费版本更有效。正式从事安全测试工作后，再根据团队预算和业务需要评估专业版。

还有一个原则要明确：安全测试工具建议从官网下载正版，不要使用来历不明的“破解版”或“汉化注入版”。这类版本可能被加入后门、窃取测试数据，甚至导致本机环境被破坏。社区版本来就不需要付费，没必要绕远路。

2.2 Java 环境检查和启动方式

BurpSuite 是基于 Java 的应用程序，启动前需要本机已经安装合适的 Java 运行环境。不同版本的 BurpSuite 对 Java 版本要求不同，常见要求是 Java 17 或更高，具体以你下载版本对应页面的说明为准。

安装 Java 后，先在命令行检查版本：

java -version

如果看到类似java version "17.0.x"的输出，说明 Java 环境正常。如果提示command not found或java 不是内部或外部命令，说明 Java 没安装或没配置环境变量，需要先补齐 Java 环境。

从官网下载得到社区版安装包后，在 Windows 上通常是.exe安装程序，双击安装即可；在 Linux 或 macOS 上可能是.jar文件，可以用命令行启动：

java -jar burpsuite_community_v2025.x.x.jar

启动后的界面会显示 Dashboard、Target、Proxy、Intruder、Repeater 等模块。不同版本界面略有差异，但核心模块布局基本稳定。

2.3 首次启动后的代理监听地址

进入 BurpSuite 后，先确认代理监听是否开启。操作路径是：

Proxy -> Proxy Settings -> Proxy Listeners

默认情况下，BurpSuite 会有一个监听条目，地址是127.0.0.1，端口通常是8080。这个监听地址的含义是：BurpSuite 只在当前电脑本机监听 8080 端口。

如果你只是要让本机浏览器走 BurpSuite，这个默认监听地址就够用。但如果要让手机或模拟器连到电脑抓包，默认地址不够，需要在 Proxy Listeners 里新增一条监听，把绑定地址改成0.0.0.0，端口可以继续用 8080。这样局域网内的设备才能通过电脑 IP 访问到 BurpSuite 的代理。

检查点：配置好监听后，后面再用浏览器访问http://burp，如果能正常打开 BurpSuite 的欢迎页，说明代理链路已经打通。

3. 浏览器抓包：代理设置、HTTPS 证书与内嵌浏览器

3.1 手动配置浏览器代理

要让浏览器流量进入 BurpSuite，必须把浏览器代理地址指向 BurpSuite 的监听地址。

以 Firefox 为例：

1. 打开 Firefox 设置。
2. 搜索“代理”。
3. 选择“手动代理配置”。
4. HTTP 代理填127.0.0.1，端口填8080。
5. 勾选“也使用此代理服务器处理 HTTPS”，确认保存。

配置完成后，访问任意 HTTP 网站，流量应该会出现在 BurpSuite 的 Proxy -> HTTP History 里。

Chrome 默认使用系统代理，也可以选择手动指定代理，但不同操作系统下配置入口略有差异。如果只在学习环境中使用，推荐直接用 Firefox，因为 Firefox 的证书库和代理设置相对独立，不会影响系统全局网络。

这里有一个很常见的坑：设置了代理但访问网站提示不能上网，或者页面长时间转圈。通常原因是 BurpSuite 没有启动，或者代理端口写错。可以先关闭代理确认网络正常，再重新配置。

3.2 安装 CA 证书，解决 HTTPS 流量不可见

抓 HTTP 流量不需要证书，但现代网站几乎都是 HTTPS，默认情况下 BurpSuite 无法直接解密 HTTPS 流量。你会在浏览器上看到“您的连接不安全”或“没有匹配的证书”之类的警告。

背后的原理是：BurpSuite 收到浏览器的 HTTPS 请求后，会临时充当目标服务器的“替身”，用自己的 CA 根证书给这个中间连接签发一个证书。浏览器如果不信任 BurpSuite 的 CA 根证书，就会拒绝继续访问。

安装证书的步骤：

1. 在代理已配置的情况下，浏览器访问http://burp。
2. 页面右上角找到 CA Certificate 下载链接，下载cacert.der证书文件。
3. 在 Firefox 设置中进入“隐私与安全 -> 证书 -> 查看证书”。
4. 切换到“证书颁发机构”标签页，点击“导入”，选择刚下载的cacert.der。
5. 导入时勾选“信任由此证书颁发机构标识的网站”，完成导入。

导入后重新访问 HTTPS 页面，应该不再出现证书警告。此时 BurpSuite 的 HTTP History 里可以看到请求的 URL、Cookie、请求头和响应体。

需要特别提醒：证书信任是有边界的。这个 CA 证书只应该用在你的学习环境中。测试结束后建议在浏览器证书管理里删除 BurpSuite 的根证书，避免以后误把流量交给不信任的代理。

3.3 使用内嵌浏览器快速跑通学习场景

社区版和专业版都提供了内嵌浏览器，入口通常在 Proxy -> Intercept 页面右侧的“Open Browser”按钮。它是一套预配置好的 Chromium 浏览器，启动后会自动使用 BurpSuite 的代理和证书，省去手动配置的步骤。

学习阶段用内嵌浏览器很合适，因为不用担心系统代理和证书库被污染，打开就能抓包。配合 DVWA、WebGoat、pikachu 等本地靶场，可以快速练习登录、越权、注入等场景。

不过要注意，内嵌浏览器不能完全替代普通浏览器的真实网络环境，部分页面可能存在兼容问题。如果遇到页面打不开或内嵌浏览器下载失败，可以退回手动配置 Firefox 的方式。

4. 手机 App 抓包：模拟器、真机与证书信任限制

4.1 先确认手机与电脑在同一网络

手机 App 抓包比浏览器麻烦很多，因为涉及局域网连通、代理设置、证书安装和 App 自身限制四层问题。第一步是确认手机和电脑在同一个局域网。

在电脑上查看局域网 IP：

ipconfig

Windows 下输出中会有 IPv4 地址，通常是192.168.x.x或10.x.x.x。记录这个地址。

然后回到 BurpSuite 的 Proxy Listeners，新增一个监听条目，绑定地址选0.0.0.0，端口用 8080。如果不改监听地址，手机请求到了电脑也会被拒绝。

手机连接同一个 WiFi 后，手动设置 HTTP 代理为电脑IP:8080。不同手机设置路径不同，但核心是：代理服务器填电脑 IP，代理端口填 8080。

此时，手机浏览器访问 HTTP 网站，如果 BurpSuite 能看到请求，说明网络链路已经打通。如果不行，多半是电脑防火墙挡住了 8080 端口，需要临时放行。

4.2 证书导入与 Android 版本的信任限制

手机浏览器访问http://burp，可以下载 BurpSuite 的cacert.der证书。Android 上通常还会提示需要安装此证书，进入系统的“安全 -> 加密与凭据 -> 安装证书”完成安装。

但这里有一个关键限制：Android 7.0 及以上版本，App 默认不信任用户安装的证书。也就是说，即使用户手动安装了 BurpSuite 证书，大多数 App 的 HTTPS 请求仍然会报 SSL 握手失败或直接忽略代理。

要解决这个问题，在学习环境中通常有两种做法：

第一种是在可 Root 的模拟器或设备上，把证书装进系统证书目录。操作方法大致是：

# 将 der 格式证书转成 pem openssl x509 -inform DER -in cacert.der -out cacert.pem # 计算证书的 subject_hash_old openssl x509 -inform PEM -in cacert.pem -subject_hash_old -noout

命令输出一串数字，比如9a5b5756。然后把cacert.pem重命名为9a5b5756.0，放入系统证书目录：

adb root adb remount adb push 9a5b5756.0 /system/etc/security/cacerts/

这个方案涉及系统目录修改，不同 Android 版本的目录位置和权限策略不一样，只建议在模拟器或专门用于测试的旧设备上做，不要在主力手机上尝试。

第二种做法是使用支持代理配置的模拟器，例如夜神、雷电等。模拟器本身也是一个 Android 系统，但它的网络配置和真机不完全一样。常用的做法是让模拟器走宿主机的代理，并把证书导入模拟器系统。

另外，Android 9.0 以上对明文 HTTP 流量默认关闭，这个限制不影响 HTTPS，但会影响部分 WebView 页面。如果 App 请求的是 HTTP 地址，可能需要配置网络安全策略，这属于 Android 开发侧的适配。

4.3 App 抓包失败的三个常见原因

还有一种情况是 App 做了 SSL Pinning，也叫证书固定。应用内置了服务器证书或公钥的指纹，遇到 BurpSuite 签发的中间证书时直接拒绝连接。绕过 SSL Pinning 通常需要逆向分析和 Hook 技术，已经超出基础抓包教程的范围。初学者遇到这种 App，先跳过，不要在环境配置上消耗太多时间。

5. 抓包之后怎么用：目标管理、请求修改与 Repeater

5.1 认识 Proxy 面板和 HTTP 历史

抓包只是手段，改包才是漏洞挖掘的关键环节。BurpSuite 的 Proxy 模块包含两个核心面板：Intercept 和 HTTP History。

Intercept 面板用于实时拦截请求，你可以在这里按流量，甚至暂停、修改、放行。默认情况下 Intercept 是关闭的，建议学习时先保持关闭。否则浏览器每发一个请求，BurpSuite 都会停下来等你处理，网络体验会非常卡。

HTTP History 面板记录所有经过 BurpSuite 的 HTTP 请求和响应。每条记录包含请求方法、URL、状态码、响应长度、MIME 类型和请求时间。双击记录可以查看完整的请求头和响应体。这个面板是后续分析的基础，很多漏洞线索来自对历史流量的观察。

刚开始练习时，不要急着改包。先访问目标网站，完成登录、浏览列表、查看详情、退出等常见操作，然后回到 HTTP History 里观察每个请求的参数、Cookie、Token 和响应状态。只有先建立“正常请求”的基线，后面修改参数时才能对比出异常。

5.2 把抓到的请求送到 Repeater 修改重放

在 HTTP History 里任意选择一条请求，右键选择 Send to Repeater，或者快捷键 Ctrl+R，就能把这条请求完整复制到 Repeater 模块。

Repeater 的意义在于：它让你脱离浏览器，独立地修改和重放一条请求。浏览器里发请求可能受页面逻辑限制，比如必须先点按钮、必须经过某个流程，但 Repeater 里你拥有完全的控制权，可以改请求方法、URL、请求头、Cookie、请求体，然后点击 Send 直接发送。

举个例子。假设浏览器的请求是：

GET /api/order/100 HTTP/1.1 Host: shop.example.com Cookie: sessionid=abc123

你想验证是否存在越权问题，可以把路径从/api/order/100改成/api/order/101，然后发送。如果接口没有做好权限校验，响应可能返回另一条订单数据，这就是越权漏洞的雏形。

在 Repeater 里修改请求后，右侧响应区会显示目标服务器返回的内容。你可以反复修改参数、对比响应差异。这个“基线请求 -> 修改单点参数 -> 观察响应”的循环，是手工漏洞挖掘最基本的工作方式。

5.3 修改请求参数的验证思路

改包测试不是乱改。推荐的流程是：

1. 先记录一条正常请求，作为基线。
2. 每次只修改一个参数，不要一次性改多个地方。
3. 观察响应状态码、响应体长度、是否包含特定关键词。
4. 如果发现异常，立即停止自动化操作，手动复查。

比如验证购物车接口是否存在越权，可以把 user_id 从当前登录账号改成另一个测试账号的 ID。如果响应返回了另一个账号的购物车内容，说明接口缺少资源所有者校验。接着应该用两个测试账号做交叉验证，避免因为缓存、代理或偶然因素误判。

这里要特别强调边界：这些操作只能在授权目标、授权账号范围内进行。不要拿真实用户 ID 或无权限的接口做测试，更不要在没有授权的系统上尝试枚举。

6. 用 Intruder 做参数测试：字典加载与授权验证

6.1 Intruder 在授权测试里的典型用途

Intruder 是 BurpSuite 的自动化参数枚举工具。它解决的核心问题是：当你想对某个参数批量测试不同取值时，不需要手动一条条复制请求，而是把参数位置标记出来，由 Intruder 自动替换并发送。

在授权范围内，Intruder 常见用途包括：

• 枚举用户 ID、订单号、文件编号。
• 对验证码、状态值等固定枚举类型做批量请求。
• 使用字典对登录接口做口令测试。
• 枚举目录或文件名参数。

需要注意，Intruder 本质是批量发送请求，会直接访问目标服务器。学习环境里可以随意使用，但针对真实系统一定要评估请求量，避免对目标造成压力。

6.2 Payload 类型和自定义字典

使用 Intruder 前，先明白两个基础概念：攻击位置和 Payload。

攻击位置是指你希望替换的参数位置。在 Intruder 面板中，用鼠标选中参数值，点击 Add §，参数就会被§符号包裹起来，例如：

GET /api/order/§100§ HTTP/1.1 Host: shop.example.com

这里100就是攻击位置，Intruder 会不断替换它。

Payload 是替换用的数据来源。常用的几个类型：

BurpSuite 允许从文件加载字典，格式是一行一个值。你也可以用简单脚本生成字典。下面是一个用 Python 生成 ID 列表的示例：

# 生成 100 到 105 的订单号 for uid in range(100, 106): print(uid)

运行并输出到文件：

python generate_ids.py > ids.txt

然后在 Intruder 的 Payload options 里选择 Load，加载这个ids.txt即可。

6.3 社区版与专业版在测试效率上的差异

社区版 Intruder 有一个明显限制：攻击模式很少，只有 Sniper 可用，而且运行速度非常慢。这种设计是为了引导用户购买专业版，但对学习来说反而提供了一个好处——你会在慢速请求里学会控制测试节奏，而不是一上来就并发扫。

专业版支持更多攻击模式，比如 Battering ram、Pitchfork、Cluster bomb，并且可以配置线程数和资源池。生产环境测试时，通常会用专业版，但并发量也要根据目标系统的承受能力调整，不要一上来就拉满。

不管是社区版还是专业版，批量测试后都要回到 HTTP History 或 Intruder 的结果面板里检查响应长度和状态码，注意筛选出与基线明显不同的响应。响应长度异常、状态码 200 但内容为空、响应中出现“管理员”“内部错误”等关键词，都值得重点复查。

7. 漏洞挖掘实战路径：从信息收集到漏洞报告

7.1 明确授权边界和测试范围

漏洞挖掘不是一个随意的扫描行为。无论是参加 SRC 项目，还是在企业内部做安全测试，第一步都是确认授权边界。

需要确认的信息包括：

• 目标域名或 IP 是否在授权范围内。
• 测试时间窗口是什么。
• 是否允许目录扫描、接口枚举。
• 是否允许使用自动化工具。
• 测试账号是否需要申请。
• 是否禁止读取敏感数据。

这些信息通常写在 SRC 项目说明或企业测试授权书里。开始测试前先截图保存这份授权范围，后续写报告时也要引用。没有明确授权的系统，即使只是发一个请求，也可能构成违规行为。

7.2 信息收集与请求观察

拿到授权后，先不要急着扫描。打开 BurpSuite，用浏览器登录目标系统，按正常用户身份完成核心功能操作，比如登录、查询、新增、修改、删除。这样 BurpSuite 的 HTTP History 里会积累大量真实请求。

观察这些请求时，重点关注几类信息：

• 接口路径，特别是/api/、/admin/、/user/等敏感路径。
• Cookie 和 Token 的生成逻辑。
• 请求参数中是否包含 ID、uid、role、price、status 等可控制字段。
• 响应中是否泄露服务端信息，例如报错堆栈、版本号、路径。

这个阶段的目标是建立“功能地图”。每一条请求都对应一个功能点，每个功能点都可能有权限校验、参数校验或业务逻辑问题。不要看到一条请求就直接改包，先通读 20 到 30 条历史请求，理解系统的业务模型。

7.3 越权、注入、逻辑缺陷的验证流程

漏洞挖掘的入口很多，但对新手来说，最容易理解和验证的三类问题是越权、注入和业务逻辑缺陷。

越权测试的思路是：登录两个不同权限的账号 A 和 B，用 A 的 Cookie 请求 B 的资源。典型操作是把订单号、用户 ID、文件 ID 等参数从 A 的值改成 B 的值，再观察响应是否返回了 B 的数据。如果返回了，说明接口缺少资源归属校验。

注入测试的基础做法是：在参数后追加单引号或者其他语法字符，观察响应是否出现数据库报错、页面异常或行为变化。例如：

GET /api/order?order_no=100' HTTP/1.1 Host: shop.example.com

如果响应中出现 SQL 语法错误信息，说明参数可能被拼接进了 SQL 语句。这只是测试的起点，真正的漏洞确认需要更系统的注入测试。

业务逻辑缺陷通常出现在支付、优惠券、抽奖、订单状态变更等场景。可以尝试修改金额、数量、折扣、订单状态等字段，看服务端是否信任前端传值。例如把商品数量改成负数，看总金额是否变成负数，或者把订单状态从“未支付”改成“已支付”，看接口是否校验状态流转。

每一类测试都要用 Repeater 手工执行，保留请求包和响应包。发现可疑现象后，先在第三个独立环境或测试账号中复现一次，排除误报。

7.4 漏洞报告要记录什么

一份合格的漏洞报告，至少要包含以下内容：

请求包直接复制 BurpSuite Repeater 或 HTTP History 里的原始数据。响应包能放就放，因为它是漏洞存在的直接证据。报告中不要出现测试账号的敏感信息，尽可能使用模拟数据和脱敏处理。

8. 常见问题排查：按链路顺序找根因

8.1 浏览器能上网但 Burp 看不到请求

这是出现频率最高的问题。浏览器明明可以打开网站，但 BurpSuite 的 HTTP History 里一条请求都没有。

排查顺序如下：

1. 先检查 BurpSuite 的 Proxy Listeners 是否处于 Running 状态。
2. 检查浏览器代理设置是否真的生效。
3. 检查代理端口是否写成了 8080，有没有被其他程序占用。
4. 查看 Intercept 开关，如果拦截开启且一直没有放行，请求会被卡住，但这种情况历史里通常会有记录。
5. 检查浏览器是否使用了插件代理或者其他代理工具。如果 Fiddler、Charles 也在运行并占用 8080，BurpSuite 可能收不到流量。

8.2 HTTPS 证书不信任或无法导入

配置完代理后，访问 HTTPS 网站提示证书错误，这是正常现象。原因是没有导入 BurpSuite 的 CA 证书。

需要区分浏览器级证书库和系统级证书库。Firefox 自己维护一套证书库，即使 Windows 系统里装了证书，Firefox 也可能不认。所以使用 Firefox 时，要在 Firefox 的证书管理里单独导入。

检查方式：

• 访问http://burp，确认能打开下载页面。
• 下载cacert.der后，检查文件大小是否为 0 或几 KB。
• 在 Firefox 证书管理里搜索 Burp 相关条目，确认是否已存在。
• 导入时确认勾选了“信任由此证书颁发机构标识的网站”。

如果反复导入仍然报错，可以先清除浏览器缓存和 SSL 状态，再重启浏览器。Chrome 中还可以在地址栏输入chrome://net-internals/#ssl清理 SSL 缓存。

8.3 App 请求超时、连接失败或客户端检测代理

手机 App 抓包失败时，先判断是网络层问题还是证书层问题。

第一步，用手机浏览器访问http://burp。如果浏览器能打开，说明手机到电脑的网络链路通。如果打不开，检查电脑 IP、代理端口、防火墙。

第二步，用浏览器访问一个 HTTPS 网站，确认证书信任已完成。

第三步，再打开 App 测试。如果浏览器正常但 App 失败，问题大概率在 App 本身，可能是不走系统代理、不信任用户证书或做了代理检测。此时不要继续耗在环境配置上，换一个不带这些限制的学习目标，或者找公开的漏洞靶场 App 练习。

在模拟器中测试时，还要注意模拟器网络模式。NAT 模式下模拟器访问宿主机的127.0.0.1通常不是宿主机本身，需要配置成宿主机局域网 IP，或者使用模拟器提供的特殊主机地址。

8.4 环境切换后的清理操作

测试完成后，最容易遗漏的是清理环境。

需要执行的项目包括：

• 恢复浏览器代理设置，避免 BurpSuite 退出后浏览器无法上网。
• 删除浏览器里导入的 BurpSuite 证书。
• 删除手机上安装的临时证书。
• 关闭 BurpSuite 新增的0.0.0.0:8080监听。
• 清理临时生成的字典和日志文件。

证书是安全敏感资源。如果 BurpSuite 的 CA 证书留在浏览器里，相当于信任了一个中间人代理，这是很大的安全隐患。测试完成第一时间清理，应该是每个安全测试者的基本习惯。

9. 生产环境、学习环境与合规边界

9.1 学习环境的建议

学习 BurpSuite 最好的方式，是在本地搭建靶场，而不是直接对线上网站测试。

常见的本地靶场包括：

• DVWA：一套 PHP + MySQL 的 Web 漏洞靶场，包含 SQL 注入、XSS、文件上传等练习。
• WebGoat：Java 编写的 Web 安全训练项目，难度梯度清晰。
• pikachu：国内开发者维护的中文漏洞靶场，适合新手。

在本地靶场里，可以大胆测试各种参数，不必担心影响别人。抓包、改包、注入、越权、上传等操作都可以在可控环境内反复练习。建议把“本地靶场跑通 -> BurpSuite 全部模块过一遍 -> 写一份完整测试报告”作为入门目标。

9.2 生产测试和授权流程

真实生产环境的测试，必须走正式流程。常见流程是：

1. 提交测试申请，写明目标范围、测试时间、测试人员。
2. 获得授权后，先在预发环境或测试环境验证工具链。
3. 在生产环境测试时，控制并发和频率，避免影响业务。
4. 每完成一个测试动作，记录时间、目标、请求包、响应包。
5. 发现敏感数据立即停止读取，按流程报告。

这里要强调，不经过授权的任何扫描、枚举、改包都可能触碰法律边界。即使只是“看一眼”未授权的接口，也可能被认定为非正常访问。安全测试的核心永远是授权两个字。

9.3 可复用检查清单

每个抓包或漏洞挖掘任务开始前，建议按下面的清单检查，避免遗漏关键步骤：

复制这份清单，写在自己常用的笔记工具里，每次测试前逐项确认。环境配置类问题浪费的时间，绝大多数都可以通过清单前置检查来避免。

9.4 下一步学习路径

跑通 BurpSuite 的抓包和改包之后，下一步可以按以下方向深入：

1. 补 HTTP 基础知识：请求方法、状态码、Cookie、Session、跨域策略。
2. 学习 OWASP Top 10：系统了解注入、失效访问控制、XSS、不安全设计等漏洞类型。
3. 深入 BurpSuite 的扩展能力：学习写简单的 Burp 扩展插件，自动化重复性工作。
4. 对比使用 Yakit、Wireshark 等其他工具，理解应用层代理和网络层抓包的区别。
5. 在授权 SRC 平台或企业靶场上参与真实漏洞挖掘，积累不同业务场景的经验。

从下载安装到第一个可复现抓包，再到授权漏洞挖掘，整个过程依赖的并不是某个高级功能，而是对代理链、证书链和请求响应模型的理解。建议先在一台不承担重要业务的电脑上把学习环境搭出来，反复练习修改请求和重放，熟悉每个模块后，再接触真实项目。