渗透测试流程与授权边界：一份可执行的 RoE¶
技术再强，没有授权就是攻击；报告再厚，没有复现步骤就无法修复。这篇给出可直接改用的规则文件（RoE）与交付标准。
1. 授权书必须写清的 8 项¶
| 项 | 内容 | 不写会怎样 |
|---|---|---|
| 委托方与测试方 | 公司全称、盖章 | 出事后无法证明关系 |
| 目标范围 | 域名、IP 段、App 包名、API 前缀 | 测到第三方系统 |
| 排除范围 | 第三方支付、云平台控制台、员工邮箱 | 越界 |
| 时间窗口 | 具体日期与时段 | 撞上大促或变更 |
| 允许手法 | 是否允许口令爆破、DoS、社工 | 争议 |
| 速率限制 | 每秒请求数、并发上限 | 打挂业务 |
| 数据处理 | 证据保存位置、加密、销毁时间 | 数据泄露责任 |
| 应急联系人 | 双方 7×24 电话、停止信号 | 出事找不到人 |
2. RoE 模板（可直接改）¶
一、目标
In scope:
- *.example.com（不含第三方托管页面）
- 203.0.113.0/24 中由甲方持有的主机
- iOS / Android 正式版 App（包名 com.example.*）
Out of scope:
- 支付网关、短信服务商、CDN 控制台
- 员工个人设备、邮箱、办公网
- 任何拒绝服务测试
- 社会工程学
二、时间
2026-09-01 至 2026-09-10，每日 22:00-06:00
业务高峰期（每月 1 日 00:00-02:00）禁止主动扫描
三、手法与限制
允许：端口扫描、目录枚举、漏洞验证、受限口令猜测
禁止：批量拖库、写入后门、修改业务数据、持久化控制
速率：≤ 20 req/s，单 IP 并发 ≤ 10
四、账号
提供测试账号：user_a / user_b / admin_test
禁止使用真实用户账号
五、数据处理
证据存放于加密盘，仅保留必要片段
测试结束后 7 日内销毁，出具销毁确认
六、应急
甲方联系人：张三 138xxxx / 李四 139xxxx
发现严重漏洞：1 小时内电话同步，暂停利用
业务异常：立即停止全部主动测试
3. 执行流程与产出¶
| 阶段 | 关键动作 | 产出 |
|---|---|---|
| 前期 | 签授权、定 RoE、确认账号 | 授权书、RoE |
| 信息收集 | 子域、端口、指纹、JS 接口 | 资产清单 |
| 漏洞验证 | 扫描 + 手工复现 | 漏洞列表（含请求响应） |
| 影响验证 | 最小化证明，不扩大 | 证据链 |
| 报告 | 定级、修复建议 | 测试报告 |
| 复测 | 按原步骤验证 | 复测报告 |
4. 漏洞定级：用 CVSS 而不是拍脑袋¶
CVSS 3.1 基础向量示例：
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H → 9.8 Critical
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N → 6.5 Medium
AV:N/AC:H/PR:N/UI:R/S:C/C:L/I:L/A:N → 6.1 Medium
| 等级 | CVSS | 业务判断 | 修复时限 |
|---|---|---|---|
| 严重 | 9.0-10.0 | 可直接拿权限/资金/全量数据 | 24 小时 |
| 高危 | 7.0-8.9 | 越权核心数据、认证绕过 | 3 天 |
| 中危 | 4.0-6.9 | 有限信息泄露、需组合利用 | 2 周 |
| 低危 | 0.1-3.9 | 信息泄露、配置问题 | 下个版本 |
CVSS 只是基线。实际定级要叠加业务影响：同样是“读取他人订单”，含手机号地址的比只有金额的严重得多。
5. 证据链：让开发能一次复现¶
每个漏洞至少包含：
1. 位置：完整 URL / 接口 / 参数
2. 前置条件：账号、角色、需要的状态
3. 请求：原始 HTTP（含 Header 与 Body）
4. 响应：关键片段（隐去他人隐私）
5. 时间：精确到秒
6. 影响：能读到什么、能改什么、影响多少数据
7. 修复建议：具体到代码/配置
8. 复测方法：修复后如何验证
请求示例：
GET /api/orders/20002 HTTP/1.1
Host: api.example.com
Authorization: Bearer <userA-token>
X-Request-Id: 20260901-221033-001
HTTP/1.1 200 OK
Content-Type: application/json
{"code":0,"data":{"orderId":20002,"userId":1002,"phone":"138****1111"}}
只截取证明所需的最小数据，不要整段导出。
6. 报告结构¶
1. 摘要（给管理层）
- 总体风险等级
- 严重/高危数量
- 一句话结论与建议
2. 测试范围与方法
3. 风险统计（按等级、按系统）
4. 漏洞详情（按等级排序，模板见上）
5. 修复建议汇总（按优先级）
6. 附录：资产清单、工具版本、测试时间线
管理层看第 1 节，开发看第 4 节，运维看第 5 节。三节都要能独立读懂。
7. 执行纪律¶
- 使用独立测试账号，不碰真实用户
- 证明越权时只看 1-2 条记录，不批量遍历
- 不安装持久化后门，测试文件用完删除
- 生产环境不做写操作、不做压力测试
- 发现严重漏洞立即同步并暂停利用
- 全程记录源 IP、时间、请求，便于溯源
8. 复测标准¶
□ 原始 payload 全部失效
□ 变体 payload（大小写、编码、二次编码）同样失效
□ 修复未引入新的越权/注入
□ 同类接口（其他模块）是否一并修复
□ 历史脏数据是否清理（存储型 XSS、二次注入）
□ 给出复测请求与响应
只测原始 payload 就出“已修复”，是复测最常见的失职。
9. 合规与法律¶
- 未授权测试可能触犯《网络安全法》《数据安全法》《刑法》285/286 条
- 等保 2.0 要求定期开展渗透测试与风险评估，报告需留存
- 不泄露、不交易测试中获取的数据
- 跨境业务注意数据出境评估
- 第三方组件漏洞由谁负责，需在合同中写明
10. 常见失败原因¶
| 问题 | 后果 | 改进 |
|---|---|---|
| 范围只写“公司网站” | 测到第三方，产生纠纷 | 用域名/IP/包名精确列举 |
| 没有时间窗 | 撞上大促，业务受损 | 明确时段与禁测窗口 |
| 报告只有截图没有请求 | 开发无法复现 | 强制附原始 HTTP |
| 定级靠感觉 | 修复优先级错乱 | 用 CVSS + 业务影响 |
| 复测只跑原 payload | 修复不彻底 | 变体与同类接口一起测 |
| 证据未销毁 | 数据泄露风险 | 约定销毁时间并出具确认 |