前面二十一章，你学的都是"零件"。 这一章，我们把所有零件装成一台"能跑的车"—— 从接到授权，到交付报告，完整走一遍。 记住一句话：专业的渗透测试，90% 的价值在"过程规范"和"报告质量"，而不在"找到多少漏洞"。
22.0 开篇：一次"项目"和一次"随手测"的区别
**"随手测"**是这样的：
我打开一个网站，试了几个 payload，找到一个 XSS，截图发给朋友。
**"一次项目"**是这样的：
□ 有书面授权，写明范围、时间、限制
□ 有测试计划和风险控制
□ 有系统化的信息收集和攻击面梳理
□ 有完整的过程记录（每个测试、每个 payload、每个响应）
□ 有多轮回溯验证（确认漏洞真实可利用）
□ 有专业报告（清晰的复现步骤 + 危害说明 + 修复建议）
□ 有交付和复盘
为什么"过程规范"这么重要？
① 法律上：证明你"在授权范围内"工作
② 质量上：保证"测全了"（不遗漏）、"测准了"（不误报）
③ 协作上：让客户/同事能"看懂、复现、修复"
④ 职业上：这是"业余爱好者"和"安全工程师"的分水岭
🔥 本章的核心目标：让你从"会打靶场"，变成"能交付项目"。
22.1 阶段零：授权与准备（最重要，别跳过）
任何测试，都从"授权"开始。没有这一步，后面的所有工作都是"违法"的。
22.1.1 授权书要写清楚什么
一份合格的授权（SOW / 授权书 / 测试协议）必须包含：
① 【授权主体】
委托方（谁授权的）和测试方（谁测的），双方盖章/签字
② 【测试范围（Scope）】★ 最关键
✅ 允许测试的 IP / 域名 / 应用（白名单，越具体越好）
❌ 明确排除的资产（比如"生产数据库禁止测试"）
⚠️ 特别注意：CC 域名、CDN、第三方托管服务（可能不在你权限内）
③ 【测试时间】
起止时间、可测试的时段（有的要求"避开业务高峰"）
④ 【测试方式与限制】
允许哪些技术手段？（是否允许社工？是否允许 DoS？）
是否允许"自动化扫描"？并发限制？
是否允许"读写数据"？（通常只允许"最小化、无害的验证"）
⑤ 【数据与保密】
发现的敏感数据如何处理（不得外传、测试后销毁）
保密协议（NDA）
⑥ 【应急与联络】
出现问题时联系谁？如何"叫停"？
哪些操作"必须先申请"？
⑦ 【交付物】
报告格式、交付时间、复测安排
22.1.2 测试前的"自检清单"
□ 授权书签了吗？范围写清了吗？
□ 我清楚"哪些能测、哪些不能"吗？
□ 我准备好了"测试计划"吗？
□ 我准备好"记录工具"了吗？（Burp、笔记系统）
□ 我知道"出事了找谁"吗？
□ 我确认"不碰破坏性操作"了吗？
⚠️ 一个血泪教训：很多事故，不是"技术失误"，而是"范围搞错"——比如测试时"顺手"扫了一个不在授权内的域名。这属于"越权测试"，是法律问题。
22.1.3 环境准备
□ Burp Suite 配好（代理 + CA 证书）
□ 一个"干净的"浏览器（只用于这次测试）
□ 笔记系统（Obsidian、Notion、或最简单的 Markdown）
□ 一个"证据目录"（截图、请求响应都存好）
□ 目标信息（IP / 域名 / 账号）
□ 沟通渠道（与客户保持联系）
22.2 阶段一：信息收集（Recon）
"你测不了你不知道的东西。" 信息收集的质量，直接决定测试的深度。
22.2.1 被动信息收集（目标无感知）
优先做被动——不打草惊蛇，也不会触发告警。
【域名与资产】
□ crt.sh：证书透明度日志，拿子域名（第 19 章）
□ DNS 数据集：SecurityTrails、VirusTotal
□ 搜索引擎：site:、filetype: 等 Dork
□ Wayback Machine：历史页面、已删除的接口
【技术栈】
□ Wappalyzer / whatweb：指纹识别
□ 响应头：Server、X-Powered-By
□ JS 文件特征
【人（社工前置）】
□ 员工邮箱格式、组织架构
□ GitHub / 代码托管平台上的泄露
□ 招聘 JD、技术博客、会议资料
【泄露】
□ GitHub 搜索：公司域名 + password / key
□ Pastebin 等
□ 历史文件（.git、.env 被搜索引擎索引）
22.2.2 主动信息收集（目标可能有感知）
□ 子域爆破（ffuf / gobuster dns）
□ 端口扫描（nmap）
□ 目录 / 文件爆破（ffuf / dirsearch）
□ 模糊测试（发各种异常请求，看响应）
⚠️ 主动收集会留下日志、可能触发告警——确保在授权范围内。
22.2.3 信息收集的产出
汇总成一份"资产地图"：
| 资产 | IP | 端口 | 技术栈 | 状态 | 备注 |
|------|-----|------|--------|------|------|
| www.example.com | 1.2.3.4 | 443 | Nginx+Spring | 主站 | |
| api.example.com | 1.2.3.5 | 443,8080 | Java | API | |
| admin.example.com | 1.2.3.6 | 443 | ThinkPHP | 后台 | ★ 重点关注 |
💡 这就是你的"作战地图"。 后面每个阶段，都从它出发。
22.3 阶段二：攻击面梳理
找出"所有入口点"，才能保证"测全了"。
22.3.1 梳理清单
【功能入口】
□ 所有页面 / 路由
□ 所有 API 接口（从 JS / 抓包 / API 文档）
□ 所有表单
□ 所有"上传/导入"功能
□ 所有"输入框"和"参数"
【身份与状态】
□ 登录 / 注册 / 找回密码
□ 会话机制（Cookie / JWT）
□ 权限体系（有哪些角色）
【敏感功能】
□ 涉及钱的（支付、退款、优惠）
□ 涉及数据的（导出、搜索、列表）
□ 涉及权限的（管理后台、用户管理）
□ 涉及文件（上传、下载、编辑）
【接口来源】
□ 正常点击（Burp 记录）
□ JS 提取
□ 目录爆破
□ 历史 URL
22.3.2 建立"测试清单表"
把攻击面变成一张"可勾选"的表——每测一项，打个勾。这是"测全"的保证。
| 编号 | 功能点 | URL | 参数 | 已测漏洞类型 | 结果 |
|------|--------|-----|------|------------|------|
| 1 | 登录 | /api/login | user,pass | 注入/爆破/枚举 | |
| 2 | 订单查询 | /api/order?id= | id | 越权/注入 | |
| 3 | 上传头像 | /api/upload | file | 上传绕过 | |
22.3.3 优先级排序
不是所有攻击面都同等重要。 按"价值 × 可能性"排序：
【高优先级】
□ 涉及钱和敏感数据的功能
□ 需要登录才能访问的功能（更可能出越权）
□ 历史遗留 / 第三方接入的模块
□ 上传 / 导入 / 导出功能
□ 管理后台
【中优先级】
□ 公开的查询 / 搜索功能
□ 用户资料修改
【低优先级】
□ 纯静态页面
□ 明显只读、无参数的功能
💡 先打高价值目标——把有限的时间用在"最可能出问题、出了问题危害最大"的地方。
22.4 阶段三：漏洞发现（测试执行）
这是"真正开始打"的阶段。用一套有章法的方式，而不是"东一榔头西一棒锤"。
22.4.1 测试的三个"层次"
【第一层：广度扫描】
对"所有入口"快速过一遍常规漏洞
目的：不漏掉"明显的、常见的"漏洞
工具：nuclei + 手工快速验证
【第二层：深度测试】
对"高价值功能"逐项深挖
目的：找到"需要理解业务才能发现"的漏洞
方法：按 OWASP 清单，逐个测
【第三层：组合利用】
把多个"小的"问题组合成"大的"
目的：把"低危"变成"高危"
例：信息泄露 → 拿到凭证 → 越权 → 拿下后台
22.4.2 按漏洞类型的测试清单
对照本书漏洞篇，逐项检查每个入口：
□ 注入（SQLi / 命令 / SSTI / NoSQL） → 第 7 章
□ XSS（反射 / 存储 / DOM） → 第 8 章
□ CSRF / 点击劫持 → 第 9 章
□ SSRF → 第 10 章
□ 文件上传 / 路径穿越 / 文件包含 → 第 11 章
□ 认证与会话（弱口令 / JWT / 重置密码） → 第 12 章
□ 访问控制（水平 / 垂直越权） → 第 13 章
□ 反序列化 → 第 14 章
□ XXE → 第 15 章
□ 业务逻辑（价格 / 流程 / 并发） → 第 16 章
□ 组件与配置（信息泄露 / 默认配置） → 第 17 章
22.4.3 测试记录的规范
每测一个点，记录四件事：
① 【请求】完整的 HTTP 请求（方法和参数）
② 【响应】关键响应（状态码、长度、关键内容）
③ 【结论】判断（有漏洞 / 无漏洞 / 待确认）
④ 【证据】截图 / 保存的请求文件
💡 为什么要这么细？ 因为做报告时要"复现"——如果当时没记清，报告里就写不清楚，客户也复现不了。
22.4.4 遇到"疑似漏洞"怎么办
① 不要急着下结论——先确认"能不能稳定复现"
② 用"最小化的 payload"再验证一遍
③ 评估"真的危害有多大"（能不能读数据？能不能越权？）
④ 如果"不确定是不是"，记录下来，标注"待确认"
⑤ 避免"只凭一次异常就上报"（容易被判为误报）
🔥 一个原则：
"能稳定复现 + 能证明危害" 才叫漏洞。 "看起来像"但复现不了，或者没有实际危害的，不能写进报告。
22.5 阶段四：验证与危害评估
发现"可疑"和"确认漏洞"之间，隔着一个"严谨的验证"。
22.5.1 验证的四个标准
① 【可复现】换一个环境 / 重来一次，还是能打出来
② 【可证明】有明确的证据（响应内容、数据）
③ 【有影响】能证明"真实危害"（读了什么数据、越权做了什么）
④ 【最小化】用最小化的操作证明，不做多余的事
22.5.2 危害评估（CVSS 思路）
评估一个漏洞的"严重程度"，看四个维度：
【攻击向量】远程 / 本地 / 需要物理接触
【攻击复杂度】简单 / 需要复杂条件
【所需权限】无需权限 / 需要普通账号 / 需要管理员
【影响】机密性 / 完整性 / 可用性
一个简化的危害分级：
| 等级 | 典型情况 |
|---|---|
| 严重 | 直接 RCE、批量拖库、无需认证的后台接管 |
| 高 | 单个用户越权、存储型 XSS、认证绕过 |
| 中 | 需特定条件的越权、反射型 XSS、信息泄露 |
| 低 | 需复杂条件、影响有限的配置问题 |
💡 记住：漏洞的价值 = 危害 × 可利用性 × 影响范围。 一个"需要管理员权限才能触发"的 RCE，远不如一个"无需登录就能打"的信息泄露值钱。
22.5.3 危害验证的"红线"
⚠️ 验证时绝不越界：
❌ 读取真实用户数据（只能读"证明漏洞存在"的最小样本）
❌ 修改 / 删除生产数据
❌ 下载整个数据库
❌ 拿真实凭证做"进一步的访问"
❌ 在客户不知情的情况下"深入利用"
✅ 证明"存在"即可，不要"真的去伤害"
✅ 涉及敏感数据时，先报告给客户，由客户决定怎么处理
🔥 一个真实的教训：
有些测试者"为了证明漏洞"，把整个数据库拖了下来——结果从"安全测试"变成了"数据泄露事故"。 证明漏洞的方式有很多种，永远选"危害最小"的那种。
22.6 阶段五：报告撰写（决定你的价值）
报告是"渗透测试的最终产品"。 一次测试的"专业度"，90% 体现在报告上。
22.6.1 报告的完整结构
① 【封面】
项目名称 / 客户 / 测试方 / 日期 / 密级
② 【文档信息】
版本历史（谁改了什么）/ 分发范围
③ 【执行摘要（Executive Summary）】★ 给管理层看
一段话说明：测了什么、发现了什么风险、整体安全状况
不要出现技术细节（领导不看这个）
④ 【测试概述】
测试范围（in-scope / out-of-scope）
测试时间
测试方法（黑盒 / 灰盒 / 白盒，用了哪些工具）
测试限制（哪些没测到、为什么）
⑤ 【风险统计】
一张"漏洞分布表"：严重 X 个、高 Y 个、中 Z 个、低 W 个
一张"趋势图"（如果有历史数据）
⑥ 【漏洞详情】★ 核心部分
每个漏洞按统一结构写（见 22.6.2）
⑦ 【修复建议汇总】
按优先级列出"先修什么"
⑧ 【附录】
原始证据、工具清单、术语表
22.6.2 单个漏洞的标准写法（最重要）
每个漏洞，都按这个"六段式"写：
漏洞 N：[漏洞名称]
风险等级：严重 / 高 / 中 / 低 CVE / CWE：（如果有）
1. 漏洞描述 一句话说清"这是什么漏洞、在哪、为什么存在" （假设读者不完全懂技术，用"业务语言"也说一遍）
2. 影响范围 受影响的 URL / 参数 / 系统 影响多少用户 / 多少数据
3. 复现步骤★ 要能被"照着做"复现 ① 用普通账号登录 ② 访问 xxx ③ 抓包，把 id 改成 xxx ④ 观察响应 （配合原始请求/响应报文、截图）
4. 危害说明 攻击者能做什么？ 会造成什么业务影响（数据泄露 / 资损 / 声誉）？ （这一条要"具体"，不要泛泛而谈）
5. 修复建议★ 要"可落地" 给出具体的、代码级的方案 （不要只说"请修复"，要说"改成 findByIdAndUserId"）
6. 参考资料 OWASP / CWE 链接
22.6.3 报告写作的"五个不要"
① 不要"只列漏洞不解释危害"——领导看不懂，就没人修
② 不要"只有一句话的修复建议"——开发不知道怎么做
③ 不要"没有复现步骤"——客户无法验证你报的是真的
④ 不要"夸大规模"——把"需要管理员权限"说成"严重漏洞"，会失去信任
⑤ 不要"全是专业术语"——要对不同读者（管理层 / 开发）分别可读
22.6.4 一份"漏洞详情"的真实示例
漏洞 1：订单接口存在水平越权（IDOR）
风险等级：高 CWE：CWE-639（Authorization Bypass Through User-Controlled Key）
1. 漏洞描述 订单查询接口 /api/order/detail 仅校验用户是否登录， 未校验请求的订单是否属于当前用户。 普通用户通过修改 orderId 参数，可查看其他用户的订单详情。
2. 影响范围 接口：GET /api/order/detail 参数：orderId 影响：全体注册用户（约 X 万）的订单数据（含收货地址、电话）
3. 复现步骤 ① 用账号 A（user_a / pass）登录，查看自己的订单，orderId=1001 ② 用 Burp 抓取请求：GET /api/order/detail?orderId=1001 ③ 将 orderId 修改为 1002 ④ 发送请求，成功返回"账号 B 的订单详情"（见附录截图）
4. 危害说明 攻击者可遍历 orderId，批量获取全体用户的订单信息 （姓名、电话、收货地址、购买记录），构成重大隐私泄露。
5. 修复建议 在查询时加入"当前用户"的约束条件： Order order = orderRepository.findByIdAndUserId(id, currentUserId); 或查询后校验 order.getUserId().equals(currentUserId)，不满足则返回 403。
6. 参考 OWASP：Insecure Direct Object References
💡 这份示例体现了"六段式"的每个要点——专业、清晰、可复现、可落地。
22.7 阶段六：交付与复盘
22.7.1 交付
□ 按约定格式 / 时间交付报告
□ 与客户"当面/线上"讲解（尤其是高危漏洞）
□ 答疑：客户问"这个漏洞怎么复现""怎么修"
□ 约定"复测"时间（修完后再验一遍）
22.7.2 复测
□ 客户修复后，重新验证每个漏洞
□ 确认"确实修好了"（而不是"修了一半"）
□ 确认"没有引入新问题"
□ 更新报告（标记"已修复/未修复"）
22.7.3 复盘（自我提升的关键）
□ 这次 "漏了什么"？（哪些攻击面没测到）
□ 这次 "花了多长时间在'无价值'的地方"？
□ 哪个漏洞"找了很久"，为什么？（下次能不能更快）
□ 报告里"客户看不懂/没修"的部分是什么？（下次怎么改进）
□ 有没有"可以沉淀成工具/模板"的经验？（→ 第 19 章）
💡 复盘是"从经验中学习"的唯一方式。 做十个项目不复盘，不如做一个项目认真复盘。
22.7.4 一个项目的"时间分配"参考
信息收集 + 攻击面梳理：30%
漏洞发现：40%
验证与评估：15%
报告撰写：15%
💡 很多人把 90% 的时间花在"漏洞发现"，然后在"报告"上草草了事——这是本末倒置。报告才是你的产品。
22.8 动手任务
任务 1：给靶场写一份"完整的项目报告"
① 拿 DVWA 或 Juice Shop，当作一个"客户系统"
② 按 22.2–22.5 完整走一遍（即使是靶场，也要"当真的做"）
③ 按 22.6 的结构，写一份完整报告
④ 每个漏洞都用"六段式"
⑤ 自己检查：如果一个不懂技术的人看执行摘要，能看懂吗？
开发能照着复现和修复吗？
💡 这是本章最有价值的练习。 写一份 10 页的报告，胜过看 100 篇教程。
任务 2：写一份"授权书模板"
根据 22.1.1 的要素，写一份你自己能用的"渗透测试授权书模板"。
以后接项目时，稍作修改就能用。
任务 3：建立你的"项目工作流"
把一个项目的"每个阶段"列成 SOP（标准流程），包括：
□ 每个阶段"输入什么、输出什么"
□ 每个阶段"用哪些工具"
□ 每个阶段"记录哪些内容"
□ 每个阶段的"检查清单"
任务 4：做一次"复盘"
挑一个你之前做过的练习（靶场通关、CTF 题），复盘：
□ 我用了什么方法？
□ 哪一步最耗时？为什么？
□ 有没有"更快的路"？
□ 有没有"可以沉淀成工具/模板"的经验？
任务 5：找一个真实的公开报告来学习
读几份公开的、高质量的渗透测试报告 / 赏金报告：
□ HackerOne 的公开报告（Hacktivity）
□ 各厂商披露的安全报告
观察：
□ 他们怎么写"危害说明"？
□ 他们的"修复建议"有多具体？
□ 他们的报告结构有什么可借鉴的？
22.9 本章小结
核心结论
- 专业测试 = 过程规范 + 报告质量。 这是"业余爱好者"和"安全工程师"的分水岭。
- 授权是起点。 SOW 必须写清：范围（in/out-of-scope）、时间、限制、数据保密、应急联络。
- 范围搞错是最大事故来源。 "顺手"测了范围外的资产 = 越权测试 = 法律问题。
- 六个阶段：授权准备 → 信息收集 → 攻击面梳理 → 漏洞发现 → 验证评估 → 报告交付。
- 信息收集的质量决定测试的天花板。 优先被动收集（crt.sh 等）。
- 攻击面梳理要"做成可勾选的清单"，这是"测全"的保证；按"价值 × 可能性"排优先级。
- 测试有层次：广度扫描 → 深度测试 → 组合利用。
- 只有"能稳定复现 + 能证明危害"才是漏洞，否则不能写进报告。
- 报告的核心是"六段式"：描述 / 影响范围 / 复现步骤 / 危害说明 / 修复建议 / 参考。
- 验证有红线：绝不读真实数据、绝不改生产数据、永远选危害最小的验证方式。
- 报告是你唯一的产品。 执行摘要给管理层，漏洞详情给开发——要分别可读。
- 复盘是提升的唯一方式。 把经验沉淀成工具、模板、SOP。
随身口诀
授权先写好，范围要卡死；信息收集打地基，攻击面梳理做清单；能稳定复现才叫漏洞，能证明危害才上报；六段式写报告，报告的"可复现 + 可落地"就是你的专业度。
22.10 预告：下一章我们去哪
现在你知道了"一次完整项目长什么样"。
但问题是——"新手"怎么找到自己的"第一个真实的漏洞"？ 怎么从"靶场通关"过渡到"真实产出"？
下一章讲的是"从零到第一个漏洞"的路径：
- 选对"合法目标"（赏金平台的正确用法）
- 什么样的目标适合新手
- "第一个漏洞"通常长什么样（往往不复杂）
- 心态建设：被拒、重复、无产出怎么办
第 23 章：找到你的第一个漏洞。
📌 本章金句 "客户花钱买的，从来不是'你找到了几个漏洞'，而是'你能让他理解风险、并且知道怎么修'。一个找到了十个漏洞却说不清楚的测试者，价值远低于一个只找到三个漏洞却交付了一份优秀报告的人。渗透测试的终点不是'漏洞'，是'安全'。"
